PCES cheat sheet
PCES · Keep the key ideas within reach.
Email Authentication and Domain Protection (SPF, DKIM, DMARC)
SPF (Sender Policy Framework) publishes a DNS TXT record listing authorized sending IPs; receivers check the envelope MAIL FROM domain, not the visible From header.
SPF lookup limit: maximum 10 DNS-querying mechanisms (include, a, mx, ptr, exists, redirect) per check; exceeding returns permerror.
SPF qualifiers: + (pass), - (fail), ~ (softfail), ? (neutral); default is + when omitted.
DKIM (DomainKeys Identified Mail) signs selected headers and the body hash with a private key; the public key is published at selector._domainkey.domain TXT record.
DKIM canonicalization (simple or relaxed) must match between signing and verification; relaxed/relaxed is most common.
DMARC policy record at _dmarc.domain TXT specifies p=none|quarantine|reject, rua (aggregate report URI), ruf (forensic URI), pct, adkim, aspf, fo.
DMARC alignment: relaxed alignment allows organizational domain match (e.g., mail.example.com vs example.com); strict requires exact domain match.
DMARC requires at least one of SPF or DKIM to pass AND be aligned with the From domain; otherwise the policy applies.
DMARC p=none is monitoring only; p=quarantine instructs receivers to treat failing mail as suspicious; p=reject instructs rejection.
Cloud Email Platform Architecture and Configuration
MX records direct inbound SMTP to the cloud email gateway; priority values determine preference (lower number = higher priority).
SPF for cloud platforms must include the provider's sending IP ranges (e.g., include:spf.protection.outlook.com for Microsoft 365).
DKIM signing in cloud platforms requires enabling the feature and publishing CNAME records (selector1/selector2._domainkey) pointing to provider keys.
DMARC record must be published in DNS at _dmarc.; cloud platforms often provide a default policy but custom policy is recommended.
Connectors in Microsoft 365 route mail between on-premises and cloud; they can enforce TLS and certificate-based authentication.
Transport rules (mail flow rules) can modify, redirect, or block messages based on conditions; they are evaluated in priority order.
Accepted domains in cloud tenants can be authoritative, internal relay, or external relay; authoritative domains host mailboxes in the cloud.
Hybrid coexistence requires careful MX and Autodiscover configuration; mail flow between on-prem and cloud uses connectors and TLS.
Cloud email archiving and retention policies are configured per-mailbox or organization-wide; litigation hold preserves deleted items.
Threat Detection, Filtering, and Anti-Phishing Controls
Phishing detection combines signature-based, heuristic, and machine-learning models; DMARC failing messages are often quarantined or rejected.
Impersonation protection (e.g., Microsoft 365 anti-phishing policies) detects look-alike domains and display name spoofing.
Safe Links rewrites URLs and checks them at click time; Safe Attachments detonates attachments in a sandbox.
Quarantine policies define what recipients can do with quarantined messages (view, release, request release).
Tenant Allow/Block Lists (TABL) override filtering verdicts for specific senders or domains; use sparingly and document.
Spam confidence level (SCL) and bulk complaint level (BCL) values determine filtering actions; SCL -1 to 9, BCL 0 to 9.
Advanced Threat Protection (ATP) safe attachment policies can block, replace, or dynamically deliver attachments.
URL detonation and time-of-click protection are critical because attackers often weaponize links after delivery.
Anti-phishing policies can enable mailbox intelligence, spoof intelligence, and first contact safety tips.
Incident Response and Investigation for Email-Borne Attacks
Preserve evidence: export original message with headers (Internet Message Headers) before deletion or remediation.
Use message trace to follow delivery path and identify affected recipients; filter by sender, recipient, subject, or message ID.
Investigate authentication results: Authentication-Results header shows SPF, DKIM, DMARC pass/fail and originating IP.
Containment: block sender/domain, purge malicious messages from mailboxes using search-and-purge (e.g., New-ComplianceSearch).
Identify compromised accounts by reviewing sign-in logs, mailbox audit logs, and unusual inbox rules or forwarding.
Eradicate persistence: remove malicious inbox rules, forwarding addresses, and OAuth app consents.
Recovery: reset credentials, revoke sessions, enable MFA, and notify affected users.
Post-incident: update filtering rules, user awareness, and DMARC policy to reject; document lessons learned.
Chain of custody: maintain hash values and timestamps for forensic evidence; use write-blockers when handling devices.
Data Protection, Encryption, and Compliance in Email
TLS encrypts SMTP in transit; opportunistic TLS (STARTTLS) may fall back to cleartext if not enforced; require TLS via connector settings.
S/MIME provides end-to-end encryption and digital signatures for email; requires certificate exchange.
Message encryption in cloud (e.g., Microsoft Purview Message Encryption) uses Azure Rights Management to encrypt content and enforce policies.
Data Loss Prevention (DLP) policies inspect email content for sensitive information types (credit cards, SSNs) and apply actions (block, encrypt, notify).
Retention policies and labels can retain or delete email based on age or classification; labels can apply encryption.
Compliance standards: GDPR, HIPAA, PCI DSS, SOX impose requirements on email retention, encryption, and access logging.
eDiscovery supports legal holds and content search; preserve data with litigation hold to prevent deletion.
Customer Lockbox and privileged access management control provider access to tenant data.
Audit logging must be enabled to record mailbox access, admin actions, and policy changes; logs retained per license.
Identity, Access, and Integration with Cloud Security Ecosystems
Modern authentication (OAuth 2.0) is required for cloud services; basic authentication is deprecated and often blocked.
Conditional Access policies evaluate signals (user, device, location, app) to grant or block access; can enforce MFA and compliant devices.
Multi-factor authentication (MFA) significantly reduces account compromise; number matching and phishing-resistant methods (FIDO2) are recommended.
Identity protection detects risky sign-ins and risky users; risk detections can trigger automatic remediation (password reset, block).
Privileged Identity Management (PIM) provides just-in-time role activation and approval workflows.
Integration with SIEM (e.g., Microsoft Sentinel) ingests audit and sign-in logs for correlation and alerting.
API-based integration with third-party security tools (CASB, email security) requires OAuth app consent and least privilege.
Hybrid identity: Azure AD Connect syncs on-prem AD to cloud; password hash sync, pass-through auth, or federation (AD FS).
Zero Trust model: verify explicitly, use least privilege access, and assume breach.