PCES study materials
PCES study resources

PCES cheat sheet

PCES · Keep the key ideas within reach.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.