PracticeVideosBlogFlashcardsEspañol

Free exam prep

EC-Council ECIH Certified Incident Handler

Practice QuestionsStudy Guide

6.3 Email Authentication Protocols (SPF, DKIM, DMARC) and Incident Containment

Key Takeaways

  • Sender Policy Framework (SPF) checks an SMTP identity—normally MAIL FROM, or HELO when the reverse path is null—against authorized senders and limits evaluation to 10 DNS-querying terms under RFC 7208.

  • DomainKeys Identified Mail (DKIM) lets a signing domain take responsibility for selected headers and a canonicalized body hash; a valid signature does not prove the human author's identity or protect unsigned fields.

  • DMARC bridges SPF and DKIM by mandating domain alignment with the visible RFC 5322 From header and enforcing policy actions (p=none, p=quarantine, p=reject).

  • Enterprise email containment requires immediate cross-tenant message purging using compliance searches or automated response playbooks to prevent widespread employee exposure.

  • Remediating AitM account compromise requires disabling or resetting affected credentials, invoking the identity provider's session and refresh-token revocation controls, reviewing app consent and mailbox rules, and accounting for access-token lifetime and propagation.

Last updated: October 2026

Email Authentication Protocols (SPF, DKIM, DMARC) and Incident Containment

Securing email infrastructure against identity deception and unauthorized domain abuse requires implementing a layered cryptographic validation framework consisting of Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC). When preventative controls fail and phishing campaigns land in corporate inboxes, incident handlers must execute swift containment playbooks—purging malicious messages enterprise-wide, invalidating hijacked session tokens, and updating gateway filtering rules to halt intrusion progression.

Email Authentication Fundamentals: The Triple Defense

The core weakness of raw SMTP is that any host can claim any identity during message transmission. Together, SPF, DKIM, and DMARC provide authenticated-domain signals, integrity for DKIM-signed content, alignment, reporting, and receiver disposition guidance; they do not prove a human sender's identity.

Sender Policy Framework (SPF, RFC 7208)

SPF enables domain owners to publish authorized sending mail server IP addresses and network blocks in a DNS TXT record (v=spf1 ...).

  • Record Syntax and Mechanisms:
    • v=spf1: Declares the protocol version.
    • ip4 / ip6: Authorizes specific IPv4/IPv6 addresses or CIDR ranges (e.g., ip4:198.51.100.0/24).
    • a: Authorizes IP addresses resolved by the domain's DNS A record.
    • mx: Authorizes IP addresses resolved by the domain's DNS MX records.
    • include: Authorizes third-party senders by referencing their SPF records (e.g., include:_spf.salesforce.com).
    • all: The fallback mechanism applied to all other IP addresses.
  • Qualifiers:
    • + (Pass): Authorizes the sender (default mechanism qualifier).
    • - (Fail / HardFail): Rejects unauthorized senders (e.g., -all).
    • ~ (SoftFail): Marks unauthorized senders as suspicious; MTAs accept but flag or route to spam (e.g., ~all).
    • ? (Neutral): Declares no policy preference.
  • Architectural Limitations of SPF:
    • The 10 DNS Lookup Limit: RFC 7208 restricts SPF evaluation to at most 10 DNS-querying mechanisms and modifiers (mechanisms: include, a, mx, ptr, exists). Exceeding this limit causes receiving MTAs to abort evaluation and return an SPF PermError (Permanent Error), causing legitimate delivery failures or allowing spoofing.
    • Envelope vs. Header Blindspot: SPF normally validates the RFC 5321 envelope MAIL FROM domain; when the reverse path is null, it evaluates the HELO identity. It does not evaluate the RFC 5322 header From: visible to the user. An attacker can pass SPF using their own envelope domain while spoofing the visible corporate From: header.
    • Forwarding Breakdown: Legitimate mail forwarding changes the connecting IP address to the intermediary relay, causing SPF checks to fail.

DomainKeys Identified Mail (DKIM, RFC 6376)

DKIM verifies that a domain signed selected headers and a canonicalized body hash and that the protected material verifies. It establishes domain responsibility, not the identity of the person who authored or sent the message.

  • Cryptographic Operation:
    1. The sending MTA hashes specified message headers (From, To, Subject, Date) and the message body using canonicalization algorithms (relaxed or simple) to prevent minor whitespace modifications from breaking signatures.
    2. The sending MTA creates a digital signature with the domain's private key over the canonicalized signed-header data and body hash, inserting the signature into the DKIM-Signature: header (v=1; a=rsa-sha256; d=victimcorp.com; s=selector1; bh=...; b=...).
    3. The receiving MTA extracts the domain (d=) and selector (s=), queries DNS for the public key at [selector]._domainkey.[domain] (TXT record), and validates the signature.
  • Forwarding Resilience: Because DKIM cryptographically binds the message contents rather than the sending IP, signatures survive legitimate forwarding as long as headers and body remain unaltered.

Domain-based Message Authentication, Reporting, and Conformance (DMARC, RFC 7489)

DMARC binds SPF and DKIM directly to the visible RFC 5322 From: header through domain alignment:

  • The Alignment Principle: The visible From: domain must align with an authenticated SPF or DKIM domain. Relaxed alignment permits the same organizational domain; strict alignment requires an exact domain match:
    • SPF Alignment: The envelope MAIL FROM domain must align with the header From: domain under the published strict or relaxed mode.
    • DKIM Alignment: The DKIM d= domain must align with the header From: domain under the published strict or relaxed mode.
    • Verdict: A message passes DMARC if it passes SPF with alignment OR passes DKIM with alignment.
  • DMARC Policy Enforcement Modes (p= tag):
    • p=none: Monitor mode. Receivers record telemetry and deliver messages normally.
    • p=quarantine: Receivers deliver failing messages to spam or quarantine folders.
    • p=reject: Receivers reject failing messages at the SMTP boundary (550 rejection code).
  • Reporting Tags:
    • rua=mailto:...: Designates addresses for daily aggregate XML reports detailing sending IPs and pass/fail statistics.
    • ruf=mailto:...: Designates addresses for real-time forensic reports on individual message failures.

Incident Containment and Enterprise Remediation Playbook

When malicious campaigns reach employee mailboxes, incident handlers execute a phased containment playbook:

Step 1: Enterprise-Wide Message Purge

Because phishing campaigns target multiple employees simultaneously, handlers must purge messages across all mailboxes:

  • Exchange Online Compliance Search: Handlers execute a PowerShell Compliance Search targeting Message-ID, sender, or subject, followed by a hard delete: 
    New-ComplianceSearch -Name "PhishPurge_20261003" -ExchangeLocation All -ContentMatchQuery '(Subject:"Urgent Invoice") AND (Received:2026-10-03)'
Start-ComplianceSearch -Identity "PhishPurge_20261003"
New-ComplianceSearchAction -SearchName "PhishPurge_20261003" -Purge -PurgeType HardDelete
  • Automated Purging: Microsoft Defender Zero-Hour Auto Purge (ZAP) continuously evaluates post-delivery telemetry to retroactively quarantine malicious messages.

Step 2: Identity Remediation and Token Invalidation

When credentials or sessions are compromised via AitM phishing:

  • Session and Token Revocation: Password resets do not terminate active sessions established via stolen OAuth refresh tokens. Handlers should invoke the identity provider's current session-revocation control (for example, Microsoft Graph revokeSignInSessions), remove illicit authentication methods and app grants, and apply risk-based access policy. Revocation may take time to propagate, and some access tokens can remain usable until expiry unless continuous-access evaluation or another enforcement control applies.
  • Credential Reset: Enforce immediate password resets and re-bind phishing-resistant MFA credentials (FIDO2 / WebAuthn).
  • Audit Mailbox Rules: Adversaries often establish hidden Inbox Rules (forwarding messages externally or diverting billing threads to Deleted Items). Handlers audit all rules via Get-InboxRule -Mailbox [username].

Step 3: Gateway Blocklists and Perimeter Controls

  • Submit malicious sender IP addresses, sending domains, and sender envelope addresses to Secure Email Gateway (SEG) global blocklists.
  • Deploy border firewall and web proxy blocks for command-and-control (C2) URLs and intermediate redirection hops.
  • Ingest file hashes (SHA-256) into Endpoint Detection and Response (EDR) platforms to quarantine payloads host-wide.

Step 4: Transport Rules and Policy Hardening

  • Implement Exchange Mail Flow Rules to append external caution banners ([EXTERNAL]) to incoming messages originating outside the tenant.
  • Advance DMARC policies from p=none to p=quarantine and p=reject to protect corporate domains from outbound brand spoofing.
Loading diagram...
SPF, DKIM, and DMARC Verification Pipeline
Test Your Knowledge

A systems administrator configures an SPF TXT record for a large enterprise by nesting multiple third-party marketing, CRM, and cloud service providers using the include mechanism. During inbound testing, external mail servers begin rejecting legitimate corporate messages with an SPF PermError verdict. What is the root cause of this authentication failure?

A

The enterprise failed to publish an associated DKIM public key in their root DNS zone

B

The SPF record syntax used ~all instead of the mandatory -all enforcement flag

C

Evaluating the nested include mechanisms exceeded the RFC 7208 limit of 10 recursive DNS lookups

D

SPF records are cryptographically restricted to a maximum of three CIDR IPv4 blocks

Test Your Knowledge

A threat actor registers the external domain financial-reports-corp.com and configures valid SPF and DKIM records on their rogue mail server. They dispatch an email using attacker@financial-reports-corp.com as the SMTP envelope MAIL FROM, but craft the visible RFC 5322 header as From: cfo@targetcorp.com. If the receiving enterprise enforces a DMARC policy of p=reject on targetcorp.com, how will the receiving gateway handle the email?

A

The message will be delivered to the inbox because the attacker's server successfully passed both SPF and DKIM authentication

B

The message will be delivered with an external warning tag because DMARC only evaluates on-premises mailboxes

C

The message will be routed to the spam folder under DMARC monitor mode

D

The message will be rejected during SMTP handling because neither SPF nor DKIM aligns with the visible RFC 5322 From domain

Test Your Knowledge

Following an Adversary-in-the-Middle (AitM) phishing attack where an executive submitted their credentials and approved an MFA push notification on a proxy site, the incident handler resets the executive's Active Directory and cloud passwords. Despite this, the attacker continues reading emails and executing unauthorized financial correspondence from the compromised account. What critical containment step did the handler fail to perform?

A

Invoke the identity provider's session and refresh-token revocation controls, remove illicit access paths, and inspect the mailbox for hidden forwarding rules

B

Requesting a new S/MIME encryption certificate from the enterprise certificate authority

C

Rebuilding the victim's physical laptop from a standardized golden operating system image

D

Modifying the enterprise SPF record to remove third-party CRM include mechanisms

Sections you finish are checked off in the contents.

Up Next

7.1 Network Reconnaissance, Unauthorized Access, and Port Scanning

Chapter 7: Handling and Responding to Network Security Incidents