TL;DR, The Stack at a Glance

• Layer 1, SPF: IP-based sender authorization. 56.5% of 12M domains publish SPF, but 2.9% are broken and 34.7% authorize 100K+ IPs. The 10-lookup limit (RFC 7208 Section 4.6.4) is the single most common failure point (TU Berlin, ACM IMC ’23).
• Layer 2, DKIM: Cryptographic message signing. Survives forwarding that breaks SPF. Minimum 1024-bit keys; 512-bit keys crack in 72 hours. Rotate at least twice per year (M3AAWG).
• Layer 3, DMARC: Policy enforcement tying SPF and DKIM to the visible From: domain. p=none → p=quarantine → p=reject is the deployment progression. Even if SPF and DKIM pass, DMARC fails without alignment (CERT-EU).
• Layer 4, ARC: Preserves authentication across intermediaries (mailing lists, forwarding). Fixes the ‘DMARC breaks forwarding’ problem. Adoption still limited (UIUC, WWW ’22).
• Layer 5, MTA-STS: Prevents transport-layer downgrade attacks (SSL stripping). Only 0.1% of domains have MTA-STS records; 29.6% of those are misconfigured (ACM IMC ’25).
• Layer 6, BIMI: Visual brand logo in supporting inboxes. Requires DMARC at enforcement + registered trademark + Verified Mark Certificate. The business incentive to complete the full stack (DigiCert VMC Guide).

1. Why the stack is six layers, not three

Most email security conversations stop at DMARC. ‘We have DMARC’ is the compliance checkbox most IT leaders aim for. But DMARC is Layer 3 of a six-layer architecture, and stopping at Layer 3 leaves three categories of attack and failure unaddressed: forwarding breaks authentication (Layer 4 fixes this), transport-layer interception allows mail-in-transit tampering (Layer 5 fixes this), and recipients have no visual way to distinguish authenticated mail from unauthenticated (Layer 6 fixes this).

Each layer exists because the previous one left a specific gap open. Understanding the stack as a progression, not a menu of independent options, is the difference between an authentication deployment that actually protects and one that provides a false sense of security.

Layer	Protocol	RFC / Spec	What it does	What it doesn’t do	Adoption (2024-25)
1	SPF	RFC 7208 (2014)	Authorizes sending IPs via DNS	Doesn’t survive forwarding; 10-lookup cap	56.5% of 12M domains
2	DKIM	RFC 6376 (2011)	Cryptographic message signing	Doesn’t specify policy action	~60-70% of major senders
3	DMARC	RFC 7489 (2015)	Policy + alignment + reporting	Breaks on forwarding; no transport security	53.8% (Fortra Q2 2025)
4	ARC	RFC 8617 (2019)	Preserves auth across intermediaries	Trust model depends on intermediaries	Growing (Google, Microsoft)
5	MTA-STS	RFC 8461 (2018)	Enforces TLS on transport	Each domain must act individually	~0.1% of domains
6	BIMI	AuthIndicators WG	Visual brand logo in inbox	Requires DMARC enforcement + VMC + trademark	Early adopters

What it means: If you are at Layer 3 (DMARC published), you have completed the hardest political work, getting organizational buy-in for email authentication. The remaining three layers are progressively easier to deploy and each addresses a specific residual risk. The roadmap from here is technical, not political.

2. Layer 1, SPF: the foundation that’s showing its age

RFC 7208 (April 2014) enables domain owners to publish, in a DNS TXT record, a list of IP addresses authorized to send email on their domain’s behalf. When a receiving server gets mail claiming to be from your-domain.com, it queries DNS for your SPF record and checks whether the connecting server’s IP is on the list. If it matches, SPF passes. If not, SPF fails.

SPF has two structural limitations that the rest of the stack is designed to compensate for. First, it checks the envelope sender (the RFC5321.MailFrom address used in the SMTP session), not the visible From: header the human recipient sees. An attacker can set any visible From: address while using a different envelope sender, and SPF will never notice the mismatch. This is the alignment gap that DMARC was designed to close.

Second, SPF breaks on forwarding. When a mailing list or forwarding service relays your message, the new sending server’s IP is not in your SPF record. SPF fails, legitimately, from the protocol’s perspective, but incorrectly from the user’s perspective. This is the gap ARC was designed to close.

And third, the 10-DNS-lookup limit. The TU Berlin ‘Lazy Gatekeepers’ study (ACM IMC ’23), analyzing 12 million domains, found that 2.9% of SPF records are broken, most commonly from exceeding the 10-lookup ceiling, and that 34.7% of SPF-publishing domains authorize over 100,000 IP addresses, making authorization meaninglessly broad. USENIX Security ’24 pinpointed that 83.7% of lookup-limit violations trace to just two hosting providers (Hostgator, Bluehost), and 616,581 enterprise domains independently exceed the limit due to SaaS vendor ‘include sprawl.’

What to do: Audit your SPF record’s recursive lookup depth (not just visible mechanisms). If you’re at 8+, flatten immediately, replace nested include: mechanisms with resolved ip4: entries that don’t count against the limit. Automate the refresh cycle; vendor IP pools change weekly. Publish v=spf1 -all on every domain that doesn’t send email.

3. Layer 2, DKIM: the cryptographic backbone

RFC 6376 (September 2011) adds a cryptographic signature to outgoing email, computed over message headers and body using a private key, with the corresponding public key published in DNS. The receiving server retrieves the public key, verifies the signature, and confirms two things: the message was sent by the claimed signing domain, and the signed portions have not been modified in transit.

DKIM’s critical advantage over SPF: it survives forwarding. Because DKIM signs the message content, not the sending IP, a forwarded message retains its DKIM signature as long as the intermediary doesn’t modify the signed headers or body. This is why M3AAWG’s Email Authentication Best Practices recommend DKIM as ‘the primary authenticator for forwarded mail’, it is the protocol that maintains authentication across the exact scenarios where SPF fails.

The operational risk is key management. M3AAWG’s DKIM Key Rotation Best Common Practices mandate a minimum 1024-bit key length, rotation at least twice per year, and deprecation of SHA-1 hashing in favor of SHA-256. The document warns that ‘512-bit keys can be cracked within 72 hours using inexpensive compute’, and many organizations are still running keys generated when 512-bit was acceptable. If your DKIM keys have not been rotated in the past six months, assume they are a liability.

What to do: Enable DKIM signing on every sending source with YOUR domain in the d= parameter, not the vendor’s. Check key length (1024-bit minimum; 2048-bit recommended). Schedule rotation every 6 months. Use separate selectors for each vendor to isolate key compromise. Verify SHA-256 hashing, not SHA-1.

4. Layer 3, DMARC: the policy layer that ties everything together

RFC 7489 (March 2015) adds the element SPF and DKIM lack: a policy. DMARC enables domain owners to publish a DNS record instructing receiving servers what to do when mail fails both SPF-with-alignment AND DKIM-with-alignment. The three policy levels, p=none (monitoring), p=quarantine (spam-folder), p=reject (drop), form the deployment progression every organization follows.

The concept that trips most implementations is alignment. CERT-EU’s DMARC whitepaper explains it precisely: ‘Even if SPF and DKIM pass authentication, DMARC will still fail if the identifiers are not aligned.’ Alignment means the domain authenticated by SPF (the envelope MailFrom) or the domain in the DKIM signature (the d= tag) must match the domain in the visible From: header. In strict mode, the match must be exact. In relaxed mode, subdomains of the organizational domain are allowed.

This is the precise mechanism that prevents the ‘SPF passes but the visible From: is spoofed’ attack that SPF alone cannot detect. It is also the precise mechanism that causes most DMARC deployment failures: an organization configures SPF and DKIM correctly for authentication, but the MailFrom domain or DKIM d= domain doesn’t align with the visible From: domain, and DMARC fails despite SPF and DKIM both passing.

DMARC also provides the reporting infrastructure: aggregate reports (rua) deliver daily XML summaries of how receiving servers handled your mail, and failure reports (ruf) deliver per-message details for failed authentication. A legal analysis from the eco Association (Germany, April 2024) documents that DMARC aggregate reports are compatible with GDPR under Article 6(1)(f) ‘legitimate interest,’ but notes that failure reports contain more sensitive data requiring stronger justification, an important consideration for any EU-based deployment.

“Even if SPF and DKIM pass authentication, DMARC will still fail if the identifiers are not aligned. Identifier alignment forces the domains authenticated by SPF and DKIM to have a relationship to the header From: domain.”
, CERT-EU Security Whitepaper 17-001 (PDF)

What to do: If you are at p=none, you are monitoring but not protected. Plan the progression: p=none → p=quarantine with pct=10 → ramp pct to 100 → p=reject. Each step should run 2-3 weeks with no legitimate-mail failures. Wire aggregate reports (rua=) to a parser you actually read. Check alignment on every sending source, SPF alignment (MailFrom domain matches From:) or DKIM alignment (d= domain matches From:).

5. Layer 4, ARC: fixing the forwarding problem

DMARC’s most-cited operational objection is that it breaks mailing lists. When a mailing list receives your message and redistributes it, two things happen: the sending IP changes (breaking SPF), and the list software often modifies headers or body (breaking DKIM). DMARC then fails on both checks, and your message is quarantined or rejected at the final destination.

RFC 8617 (July 2019) defines ARC, the Authenticated Received Chain, to solve this. ARC allows each intermediary in the delivery path to sign and preserve the authentication state at the point it received the message. The final receiving server can then evaluate the chain of custody: ‘did the message authenticate when it arrived at the first intermediary? And did each subsequent handler maintain that chain?’ If the chain is intact and the intermediaries are trusted, the receiver can accept the message despite DMARC failure.

University of Illinois researchers (Wang et al., WWW ’22) analyzed ARC’s security model and found that email forwarding creates specific vulnerabilities that ARC mitigates, but that the trust model depends entirely on intermediaries correctly implementing the protocol. ARC does not prevent an untrusted intermediary from fabricating an authentication chain; it provides the mechanism for chain verification, not the trust.

Google, Microsoft, and several major providers already support ARC on both the signing and validation sides, which means the protocol is operationally available for most enterprise environments. But ARC adoption beyond the major providers remains limited.

What to do: If your organization operates mailing lists or forwards email to external destinations, ARC signing on your outbound mail servers prevents your messages from failing DMARC at the final hop. If you receive forwarded mail, validate ARC chains from trusted sources. Most modern email platforms (Exchange Online, Google Workspace) support ARC natively, check that it’s enabled, not just available.

6. Layer 5, MTA-STS: securing the transport layer

<img src=“https://media.mailhop.org/autospf/images/2026/05/spf-record-check-3790.jpg” alt=""MTA-STS Protocol: 0.1% Adoption 29.6% Misconfigured” width=“700” height=“382” loading=“lazy” />

Layers 1-4 verify who sent the email and whether it was modified. None of them verify that the email was encrypted in transit. An attacker who can intercept network traffic between two mail servers can read, copy, or modify email that uses opportunistic TLS (STARTTLS), because opportunistic TLS can be silently downgraded by stripping the STARTTLS capability advertisement. This is known as an SSL stripping attack.

RFC 8461 (September 2018) defines MTA-STS to close this gap. MTA-STS allows a domain owner to publish a policy (via HTTPS, not just DNS) declaring that their mail servers support TLS and that sending MTAs should refuse to deliver mail over unencrypted connections. By requiring the policy to be fetched over authenticated HTTPS, not DNS alone, MTA-STS adds a certificate-verification step that STARTTLS announcements cannot provide.

The academic measurement is sobering. Ashiq et al. (ACM IMC ’25), the definitive measurement study, found that only approximately 0.1% of domains have MTA-STS records configured. Among the 68,030 domains that do have MTA-STS records, 29.6% (20,144 domains) are incorrectly configured, with expired certificates and empty policy files as common errors. The study also found that MTA-STS adoption is inherently slower than the competing DANE standard because ‘a single operator adding TLSA records enables DANE for all domains using that MX, while MTA-STS requires each individual domain owner to take action.’

Despite the low adoption, 19.6% of domains that send to MTA-STS-enabled domains DO perform MTA-STS validation, showing that the validation side is ahead of the publication side. If you publish MTA-STS, roughly one in five senders will enforce it.

What to do: MTA-STS deployment requires three things: a DNS TXT record at _mta-sts.yourdomain.com with a version ID, an HTTPS-accessible policy file at mta-sts.yourdomain.com/.well-known/mta-sts.txt listing your MX servers, and a valid TLS certificate for mta-sts.yourdomain.com. The most common errors (per the IMC ’25 study) are expired certificates and empty policy files, set calendar reminders for certificate renewal and monitor the policy endpoint.

7. Layer 6, BIMI: the business incentive to complete the stack

BIMI, Brand Indicators for Message Identification, is the visual layer. When deployed correctly, BIMI displays your organization’s verified brand logo next to authenticated emails in supporting email clients. Gmail, Apple Mail, and Yahoo Mail all support BIMI rendering for properly configured senders. The logo appears only when authentication passes, making it a visible trust signal that recipients can see without examining headers.

The prerequisites are deliberately strict. DigiCert’s VMC guide and the BIMI Working Group’s VMC Guidelines specify: DMARC must be at enforcement (p=quarantine or p=reject with pct=100); SPF and DKIM must be correctly configured for DMARC alignment; the brand logo must be a registered trademark at a recognized trademark office; the logo must be in SVG Tiny Portable/Secure format; and a Verified Mark Certificate (VMC) must be issued by an authorized CA (currently DigiCert or Entrust). VMCs must be renewed annually with re-validation every 398 days, comparable to Extended Validation TLS certificates.

BIMI is the layer that converts authentication from a security-team project into a marketing-team priority. The conversation shifts from ‘we need DMARC for security compliance’ to ‘we want our logo in Gmail inboxes for brand recognition.’ That shift is the single most effective internal accelerant for completing the full authentication stack.

“BIMI is the business incentive to complete the full authentication stack. The conversation shifts from ‘we need DMARC for compliance’ to ‘we want our logo in every inbox.’ That shift changes the budget conversation.”

What to do: BIMI deployment only makes sense after DMARC is at enforcement. If you’re not at p=quarantine or p=reject with pct=100, BIMI won’t render. Once you are: register your brand logo as a trademark (if not already), convert it to SVG Tiny PS format, purchase a VMC from DigiCert or Entrust, and publish the BIMI DNS record. The logo rendering in Gmail and Apple Mail will follow within days.

8. The multi-year roadmap: where you are and what comes next

Most organizations reading this article are somewhere between Layer 1 and Layer 3. The roadmap below maps your current state to your next actions.

If you have SPF but not DKIM or DMARC (Layer 1 only)

1. Enable DKIM signing on your primary email platform with your domain in d=, not the vendor’s. This typically takes 30-60 minutes per platform.
2. Publish DMARC at p=none with rua= reporting. This gives you visibility into who’s sending as your domain without affecting delivery. Monitor for 30 days.
3. Flatten SPF if needed. If your recursive lookup count is at or near 10, flatten nested includes into IP-based entries and automate the refresh.

If you have DMARC at p=none (Layer 3, monitoring)

4. Analyze your DMARC aggregate reports. Identify every legitimate sending source. Verify SPF and DKIM alignment for each. Fix alignment failures before progressing.
5. Progress to p=quarantine with pct=10, then ramp. 2-3 weeks per step: pct=10 → 25 → 50 → 75 → 100. Then move to p=reject.
6. Protect parked and legacy domains. M3AAWG mandates v=spf1 -all and DMARC p=reject on every non-sending domain.

If you have DMARC at enforcement (Layer 3, p=reject)

7. Deploy ARC signing on mailing lists and forwarding infrastructure to preserve authentication across intermediaries.
8. Publish MTA-STS to enforce transport encryption. Three components: DNS record, HTTPS policy file, valid TLS certificate. Monitor for the 29.6% misconfiguration rate the ACM IMC ’25 study documents.
9. Evaluate BIMI deployment. Trademark your logo, convert to SVG Tiny PS, purchase VMC, publish BIMI record. The logo rendering in Gmail is the visible reward for completing the stack.

Ongoing, regardless of current layer

10. Rotate DKIM keys every 6 months. 1024-bit minimum; 2048-bit recommended. Use separate selectors per vendor.
11. Monitor DMARC aggregate reports weekly. New vendors, SaaS additions, and configuration drift are continuous risks.
12. Audit quarterly. The NIST SP 800-177 reference architecture assumes continuous management, not set-and-forget deployment.

9. Bottom line: the stack is a progression, not a checklist

Six protocols. Six RFCs. Six layers of defense, each closing a gap the previous one left open. SPF authorizes IPs but breaks on forwarding. DKIM signs content but doesn’t specify policy. DMARC enforces policy but breaks on mailing lists. ARC preserves authentication across intermediaries but doesn’t protect the transport layer. MTA-STS enforces encrypted transport but doesn’t provide visual trust. BIMI provides the visual signal, but only after every other layer is in place.

The progression is not optional. Each layer is weaker without the ones below it. DMARC without DKIM is fragile (any forwarding breaks it). DKIM without DMARC has no enforcement (receivers can ignore it). BIMI without DMARC enforcement literally doesn’t render. The dependencies are architectural, not bureaucratic.

NIST SP 1800-6 documents the full reference architecture. M3AAWG’s authentication best practices provide the operational guidance. Five IETF RFCs define the protocols. Academic measurement shows where adoption actually stands. The knowledge base is complete. The question is no longer what to deploy, it is how far up the stack your organization is willing to go, and how quickly.

If you take one insight from this article: most organizations stop at Layer 3 and call it done. The organizations that progress to Layers 4, 5, and 6 have authentication that survives forwarding, prevents transport interception, and provides the visible trust signal that recipients actually see. The first three layers are the foundation. The last three are the difference between authentication that works on paper and authentication that works for people.

References

Every source is a downloadable PDF or formal document, IETF RFCs, peer-reviewed academic papers, NIST publications, M3AAWG best-practices PDFs, CERT-EU whitepaper, GDPR legal analysis, BIMI Working Group specification, and enterprise vendor documentation. No web articles or blog posts.

13. IETF RFC 7208: SPF (PDF) https://www.rfc-editor.org/rfc/pdfrfc/rfc7208.txt.pdf
14. IETF RFC 6376: DKIM Signatures (PDF) https://www.rfc-editor.org/rfc/pdfrfc/rfc6376.txt.pdf
15. IETF RFC 7489: DMARC (PDF) https://www.rfc-editor.org/rfc/pdfrfc/rfc7489.txt.pdf
16. IETF RFC 8617: ARC Protocol (PDF) https://www.rfc-editor.org/rfc/pdfrfc/rfc8617.txt.pdf
17. IETF RFC 8461: MTA-STS (PDF) https://www.rfc-editor.org/rfc/pdfrfc/rfc8461.txt.pdf
18. Czybik et al., ‘Lazy Gatekeepers’ (ACM IMC ’23, PDF) https://arxiv.org/pdf/2502.08240
19. Ashiq et al., ‘SPF Beyond the Standard’ (USENIX Security ’24, PDF) https://www.usenix.org/system/files/usenixsecurity24-ashiq.pdf
20. Ashiq et al., ‘MTA-STS Deployment’ (ACM IMC ’25, PDF) https://taejoong.github.io/files/publications/ashiq-2025-mtasts.pdf
21. Wang et al., ‘Email Forwarding Security under ARC’ (WWW ’22, UIUC, PDF) https://gangw.cs.illinois.edu/arc-www22.pdf
22. Ashiq et al., DMARC Reporting Security (PDF) https://taejoong.github.io/files/publications/ashiq-2023-dmarc.pdf
23. NIST SP 800-177 Rev. 1: Trustworthy Email (PDF) https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-177r1.pdf
24. NIST SP 1800-6: DNS-Based Email Security (PDF) https://www.nccoe.nist.gov/sites/default/files/legacy-files/dns-secure-email-nist-sp1800-6c.pdf
25. M3AAWG Email Authentication Best Practices (PDF) https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf
26. M3AAWG Managing SPF Records (PDF) https://www.m3aawg.org/sites/default/files/doc_files/m3aawg_managing-spf_records-2017-08.pdf
27. M3AAWG DKIM Key Rotation (PDF) https://www.m3aawg.org/sites/default/files/document/M3AAWG_DKIM_Key_Rotation_BP-2013-12.pdf
28. M3AAWG Protecting Parked Domains (PDF) https://www.m3aawg.org/sites/default/files/m3aawg_parked_domains_bp-2015-12.pdf
29. M3AAWG Sending Domains BCP https://www.m3aawg.org/SendingDomsBCP
30. CERT-EU DMARC Whitepaper (PDF) https://cert.europa.eu/publications/security-guidance/Updated-CERT-EU_Security_Whitepaper_DMARC_17-001_v1_2/pdf
31. eco Association, DMARC and GDPR Legal Analysis (PDF) https://international.eco.de/wp-content/uploads/dlm_uploads/2024/04/eco_kg_e-mail_compatibility_dmarc_gdpr_.pdf
32. DigiCert, VMC and BIMI Guide (PDF) https://www.digicert.com/content/dam/digicert/pdfs/datasheet/vmc-datasheet-en.pdf
33. BIMI Working Group, VMC Guidelines (PDF) https://bimigroup.org/resources/VMC_Guidelines_latest.pdf
34. Cisco ESA, SPF/DKIM/DMARC Best Practices (PDF) https://www.cisco.com/c/dam/en/us/products/collateral/security/esa-spf-dkim-dmarc.pdf