SPF, DKIM, and DMARC: The Mechanics of Email Authentication

Email was originally designed without built-in verification mechanisms. Under the basic SMTP specification, any sending host can populate the From: header with any domain name, creating a massive vulnerability for domain spoofing and phishing attacks.

To establish identity verification across open networks, three core protocols were developed over two decades: Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC). Understanding how these three specifications interact is essential for securing domain routing and maintaining deliverability.

1. Sender Policy Framework (SPF) — RFC 7208

SPF allows a domain owner to publish a list of IP addresses or subnets authorized to send email on behalf of their domain. This list is published as a public TXT record in DNS at the root of the domain.

Envelope From vs Header From

A common point of confusion is which address SPF actually validates. SPF checks the Envelope From address (also referred to as the MAIL FROM, Return-Path, or bounce address), not the visible From: header displayed in the recipient’s email client.

When an MX server receives an incoming TCP connection:

1. It reads the Envelope From domain transmitted during the MAIL FROM phase of the SMTP transaction.
2. It queries DNS for the TXT record of that Envelope From domain.
3. It checks whether the connecting client’s IP address matches any IP, CIDR block, or included record listed in the SPF policy.

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all

The 10 DNS Lookup Limit

RFC 7208 mandates a strict security limit: resolving an SPF record must require no more than 10 nested DNS lookups (such as include, a, mx, ptr, and exists mechanisms). Direct IP mechanisms (ip4 and ip6) do not count against this limit. If evaluating an SPF policy requires an 11th DNS query, the receiving server aborts the check and returns a status of PermError.

The Forwarding Flaw

SPF has an inherent architectural limitation: it breaks when an email is forwarded. If [email protected] sends mail to an intermediary address that forwards the message to a final mailbox at Gmail, Gmail sees the connection originating from the forwarding server’s IP address — which is not in example.com’s SPF record. Consequently, SPF evaluation fails on forwarded messages.

2. DomainKeys Identified Mail (DKIM) — RFC 6376

DKIM addresses the forwarding flaw of SPF by attaching an asymmetric cryptographic signature to the email headers and body payload.

How DKIM Signatures Work

1. Key Pair Generation: The domain owner generates a public/private cryptographic key pair. The private key remains secured on the sending MTA, while the public key is published in DNS under a sub-domain selector: selector._domainkey.example.com.
2. Canonicalization: Headers and body text undergo normalization (c=relaxed/relaxed) to ensure minor whitespace transformations during transfer do not break the hash.
3. Hashing and Signing: The sending MTA hashes specified headers (such as From, To, Subject, Date) and the body payload, encrypts the hash using the private key, and injects a DKIM-Signature header into the message.
4. Verification: The receiving server retrieves the public key from DNS using the selector specified in the d= tag of the DKIM header, decrypts the signature, recalculates the hash, and verifies integrity.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=example.com; s=s2026;
 h=from:to:subject:date:message-id;
 bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
 b=dK8...x9Q==

Because the cryptographic signature is contained entirely within the MIME headers of the message payload, DKIM authentication survives intermediate email forwarding hops intact.

3. DMARC — RFC 7489

While SPF and DKIM independently verify IP authorization and payload integrity, neither protocol binds those checks to the visible From: header shown to end users. A malicious actor could pass SPF using their own Envelope From domain while displaying [email protected] in the visible header.

DMARC solves this by introducing two critical concepts: Identifier Alignment and Policy Enforcement.

Identifier Alignment

DMARC requires that the domain in the visible From: header matches (aligns with) the domains validated by SPF or DKIM:

• SPF Alignment: The Envelope From domain must match the domain in the visible From: header.
• DKIM Alignment: The domain in the d= tag of a valid DKIM signature must match the domain in the visible From: header.

DMARC allows alignment to be relaxed (organizational domain match, e.g., mail.example.com aligns with example.com) or strict (exact hostname match required). To pass DMARC, a message must achieve alignment for at least one of the two underlying protocols (SPF or DKIM).

+-------------------------------------------------------------------------+
|                         DMARC Evaluation Matrix                         |
+-------------------------------------------------------------------------+
| Protocol | Domain Validated       | Visible Header Domain | Alignment   |
+----------+------------------------+-----------------------+-------------+
| SPF      | return.marketing.com   | brand.com             | Pass (Relax)|
| DKIM     | d=brand.com            | brand.com             | Pass (Exact)|
+----------+------------------------+-----------------------+-------------+
| RESULT   | DMARC PASSED (DKIM aligned with visible From header)         |
+-------------------------------------------------------------------------+

DMARC Policy Enforcement

A domain owner publishes a DMARC policy in DNS at _dmarc.example.com specifying how receiving MX servers should handle unaligned messages:

• p=none: Telemetry-only mode. Receiving servers accept unaligned mail normally but generate aggregate RUA reports.
• p=quarantine: Receiving servers divert unaligned mail to the recipient’s spam/junk folder or place it in sandbox isolation.
• p=reject: Receiving servers outright reject unaligned mail at the SMTP handshake level (554 5.7.1).

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100; adkim=r; aspf=r;

Why Authentication Is Not a Deliverability Guarantee

A frequent misconception among infrastructure teams is that achieving p=reject with 100% SPF and DKIM alignment guarantees high inbox placement.

Authentication protocols are identity verification mechanics, not trust metrics. SPF, DKIM, and DMARC prove to receiving servers who sent the message and that it was not altered in transit. However, once identity is verified, receiving networks hand the message over to their reputation filter engines.

If a domain with valid DMARC sends high volumes of unrequested mail or hits pristine spam traps, mailbox providers will reliably route authenticated messages directly to the spam folder. Authentication ensures your mail gets evaluated fairly; domain reputation determines where it lands. To inspect how mailbox providers evaluate sender history, read our analysis of Sender Reputation Dynamics.