Leadership

Most organizations treat email authentication as a checkbox exercise. Deploy SPF, publish DMARC in reporting mode, call it done. But the real story isn’t about maturity tiers—it’s about what you unlock at each phase of implementation. And frankly, the gap between where organizations are and where they need to be is brutal.

This post outlines an enablement journey: each phase builds on the previous one and creates new capabilities that weren’t possible before.

The Landscape Reality

Before we dive in, context. Across the Majestic Million (the top 1M resolvable domains):

  • SPF published: 85.3% (mail-enabled domains)
  • DMARC published: 57.1% (mail-enabled)
  • DMARC enforced (p=reject or quarantine): ~26%
  • MTA-STS: 1.1%
  • DNSSEC signed: 6.75%
  • DANE: 0.73% overall (10.9% of DNSSEC-signed domains)

The cliff is real. Phase 1.5 is where 74% of organizations stop. Phases 2 and beyond are nearly empty.

Phase 0: No Controls

Where you are: Email spoofing is trivial. Anyone can send mail claiming to be from your domain. Spammers, phishers, and fraudsters do this at scale against your brand.

What happens:

  • Your domain appears in phishing emails daily
  • Customers receive counterfeit invoices
  • Support gets flooded with “did you send this?” tickets
  • You have zero authentication framework

You need this because: It’s the starting point. If you’re here, stop reading and go deploy Phase 1 immediately. This isn’t optional.

Phase 1: SPF + DMARC (Any Mode)

What you deploy:

  • SPF (Sender Policy Framework): Publish an v=spf1 record listing which servers can legitimately send mail from your domain
  • DMARC (Domain-based Message Authentication, Reporting and Conformance): Publish a _dmarc record with p=none (reporting-only mode)

Effort required: 2–4 hours (total)

  • SPF: Identify all legitimate mail senders (direct servers, ESP, third-party services); write the SPF record; test
  • DMARC: Set up a reporting inbox or service; publish the policy in reporting mode

What this enables:

  1. Visibility into who’s sending mail claiming to be from your domain (DMARC reports)
  2. Basic sender authentication checks at receiving mail servers
  3. A foundation for future enforcement
  4. Detection of obvious spoofing attempts

What it doesn’t do:

  • Actually stop fraudulent mail (p=none is passive only)
  • Protect message content
  • Enforce TLS encryption
  • Protect against DNS spoofing

Real-world behavior: 74% of organizations with DMARC stop here. Most never read the DMARC reports. They publish the record, the RRDmarc/EasyDMARC/Dmarcian service sits dormant, and the domain remains vulnerable.

The problem: p=none (reporting mode) tells receiving mail servers “I don’t care if this fails authentication, accept it anyway.” It’s security theater.

Why people stop here:

  • “We have DMARC deployed” ✓ (checkbox mentality)
  • Moving to enforcement (p=reject) requires operational confidence that SPF is correct
  • Organizations with complex mail flows (third-party services, legacy systems) fear breaking legitimate mail

Phase 1.5: SPF + DMARC Enforced (p=reject)

What changes:

  • Set DMARC policy to p=reject (or p=quarantine as intermediate step)
  • Maintain robust DMARC reporting infrastructure
  • Establish incident response for “legitimate mail bouncing”

Effort required: 4–8 weeks

  • Complete DMARC report analysis (identify all senders)
  • Adjust SPF to include missing services
  • Test with p=quarantine for 1–2 weeks
  • Monitor bounce rates
  • Flip to p=reject
  • Ongoing triage of report anomalies

What this enables:

  1. Actual rejection of spoofed mail claiming to be from your domain
  2. Blocking of fraudulent invoices, credential harvesting, brand abuse
  3. Reduction in reputational damage
  4. Significant drop in phishing attacks targeting your organization

Impact: Studies suggest p=reject reduces phishing success rates by 70–85% against your domain specifically. This is not marginal.

What it doesn’t do:

  • Protect message confidentiality or integrity (beyond DKIM signature on body)
  • Enforce encryption of SMTP connections
  • Prevent spoofing of subdomains
  • Address CA compromise or fraudulent TLS certificates

Why most organizations plateau here:

  • Fear of breaking legitimate mail (valid concern if SPF config is incomplete)
  • Operational overhead of monitoring DMARC reports
  • No clear business case for further investment (“we stopped the easy attacks”)
  • DMARC enforcement is sufficient for regulatory compliance (PCI-DSS, baseline ISO 27001)

Critical gap: Only ~26% of mail-enabled domains enforce DMARC. This is the biggest failure point in email authentication adoption.

Phase 2: Phase 1.5 + MTA-STS

What you deploy:

  • MTA-STS (Mail Transfer Agent Strict Transport Security): Publish an MTA-STS policy telling sending mail servers “all connections to my mail server must use TLS, no exceptions”

Implementation:

  1. Host a policy file at https://mta-sts.example.com/.well-known/mta-sts.txt (plain text, 1–2 KB)
  2. Publish a DNS TXT record at _mta-sts.example.com pointing to the policy
  3. Ensure your mail server supports TLS on port 25

Effort required: 4–8 hours

  • Write the policy file (boilerplate)
  • Host it on HTTPS (certificate you already have)
  • Publish one DNS record
  • Test with a tool like swaks to verify STARTTLS enforcement

What this enables:

  1. Mandatory encryption of SMTP connections (STARTTLS enforcement)
  2. Prevention of “advertised TLS then stripped” attacks
  3. Blocking of eavesdropping on incoming mail
  4. Pinning your MX servers (prevents trivial MITM via DNS spoofing)

Impact: Prevents opportunistic downgrade attacks. Sending mail servers must negotiate TLS; if it fails or is refused, they reject the mail (don’t fall back to plain text).

What it doesn’t do:

  • Validate that the TLS certificate is legitimate (attacker can still MITM with fraudulent cert from trusted CA)
  • Provide observability into TLS failures (that’s TLS-RPT)
  • Encrypt mail at rest or in transit beyond SMTP handoff

Why adoption is 1.1% (criminally low):

  • Requires outbound mail servers to implement RFC 8461 (many older/simpler systems don’t)
  • No immediate visible payoff (mail still flows; just more encrypted)
  • Operational assumption: “Our mail server is already TLS-capable” (true, but MTA-STS requires it)
  • Regulatory frameworks don’t mention it (DMARC enforcement is good enough for compliance)

This is a huge gap. Effort is trivial. Benefit is real. Adoption is 1%. This should be Phase 1.5a, not Phase 2.

Phase 2.5: Phase 2 + TLS-RPT + CAA

What you deploy:

  • TLS-RPT (SMTP TLS Reporting): Publish _smtp._tls DNS record with reporting endpoint
  • CAA (Certification Authority Authorization): Publish CAA records restricting which CAs can issue certs for your domain

TLS-RPT implementation (2–4 hours):

  1. Set up an HTTPS endpoint to receive JSON reports (webhook or email)
  2. Publish _smtp._tls.example.com TXT record with v=TLSRPTv1; rua=https://...
  3. Wait 1–7 days for reports to arrive

CAA implementation (1 hour):

  1. Publish CAA records: example.com CAA 0 issue "letsencrypt.org; accounturi=https://..."
  2. Do the same for any CAs you use (DigiCert, GlobalSign, etc.)
  3. Set issuewild if you use wildcard certs

What this enables:

  1. Observability into MTA-STS and DANE failures (TLS-RPT)
  2. Incident detection: Know immediately when your MTA-STS policy is breaking TLS connections
  3. Prevention of unauthorized certificate issuance (CAA)
  4. Operational data to iterate on TLS policies

Impact: TLS-RPT gives you visibility you didn’t have before. You can now see:

  • Which sending mail servers failed to negotiate TLS
  • Which servers tried and succeeded
  • If any unexpected errors occurred
  • Trends over time

CAA prevents attacks like Let’s Encrypt account compromise issuing unauthorized certs for your domain.

What it doesn’t do:

  • Actually validate that a TLS certificate is yours (that’s DANE)
  • Prevent MITM attacks from an attacker with a fraudulent but CA-signed cert
  • Block all unauthorized certificate issuance (only restricts which CAs can issue)

Why adoption is ~0.01%:

  • TLS-RPT requires infrastructure to receive reports (most orgs don’t have this)
  • CAA is simple but doesn’t solve an obvious problem (“I wasn’t attacked by unauthorized CA issuance”)
  • Regulatory frameworks don’t require either
  • False impression: “My mail server is secure without these”

The real reason to deploy: You’ve put effort into MTA-STS; you need to know if it’s working. That requires TLS-RPT.

Phase 3: Phase 2.5 + DNSSEC

What you deploy:

  • DNSSEC (DNS Security Extensions): Cryptographically sign all DNS records for your domain

Implementation (weeks to months):

  1. Generate DNSSEC keys (ZSK, KSK)
  2. Sign all DNS records with ZSK
  3. Publish DS records (child trust anchor) at your parent zone (your domain registrar)
  4. Establish key rotation procedures
  5. Monitor DNSSEC validation chain

Effort required: 2–8 weeks (ongoing)

  • Initial setup: 4–16 hours
  • Testing and rollout: 1–2 weeks
  • Operational overhead: 2–4 hours per year for key rotation
  • Troubleshooting broken chains: reactive, unpredictable

What this enables:

  1. Cryptographic authentication of all your DNS records
  2. Protection against DNS poisoning and cache poisoning attacks
  3. Validation that your SPF, DMARC, MTA-STS, and TLS-RPT records haven’t been tampered with
  4. Foundation for DANE (requires DNSSEC)

What it doesn’t do:

  • Encrypt DNS queries (DoH/DoT does that)
  • Prevent DNS query leakage (visibility of what you’re looking up)
  • Protect against zone compromise if attacker has zone keys
  • Protect against DNSSEC implementation bugs (common in validators)

Operational burden:

  • Key rotation schedules (annual or more frequent)
  • DNSSEC failures are silent and catastrophic (entire domain stops resolving if chain breaks)
  • Most organizations don’t have expertise in DNSSEC operations
  • Registrar support varies wildly

Why adoption is 6.75% (and why most of those 6.75% regret it):

  • High operational complexity relative to benefit
  • No immediate payoff (records were probably fine anyway)
  • Breaking changes when keys expire or rotation fails
  • Validator bugs and implementation issues create false failures
  • ISPs and recursive resolvers have incentive to not validate (adds latency)

When to deploy:

  • You have regulatory requirement (TISAX, some CMMC levels, certain defence/government standards)
  • You have dedicated DNS/infrastructure expertise
  • You’re willing to staff DNSSEC operations permanently

When NOT to deploy:

  • You don’t have in-house DNS expertise
  • Your registrar has poor DNSSEC support
  • You can’t justify weeks of engineering time
  • You don’t have a specific regulatory mandate

Phase 4: Phase 3 + DANE

What you deploy:

  • DANE (DNS-based Authentication of Named Entities): Publish TLSA records pinning your mail server’s TLS certificate

Implementation (assumes Phase 3 complete):

  1. Generate or obtain TLS certificate for your mail server
  2. Extract certificate fingerprint or public key
  3. Publish TLSA records in DNS: _25._tcp.mail.example.com TLSA ...
  4. Enable DANE validation on sending mail servers (they check TLSA instead of CA chain)
  5. Set up monitoring for certificate expiry and TLSA record freshness

Effort required: 4–8 hours (plus Phase 3 prerequisites)

  • Generate/extract certificate material: 1–2 hours
  • Publish TLSA records: 30 minutes
  • Test with DANE-validating mail servers: 1–2 hours
  • Monitor and maintain: 1 hour per cert renewal

What this enables:

  1. Certificate pinning via DNS: Your mail server’s TLS certificate is authenticated by DNSSEC, not by the CA trust chain
  2. Protection against CA compromise: Even if an attacker compromises a trusted CA and issues a fraudulent cert for your domain, DANE rejects it (the cert doesn’t match the pinned TLSA record)
  3. MITM protection: Attacker can’t forge a TLS connection to your mail server because the cert must match the pinned key/cert hash

Impact: Eliminates an entire class of SMTP MITM attacks (those using fraudulent-but-CA-valid certificates). Real-world: rare, but not theoretical.

What it doesn’t do:

  • Protect against zone compromise (if attacker controls your DNS, they control TLSA records)
  • Encrypt mail at rest
  • Protect against application-layer attacks
  • Protect against compromise of your actual mail server

Adoption reality: 0.73% overall, 10.9% of DNSSEC-signed domains

The telling stat: If you’ve already deployed DNSSEC (6.75%), 89% of you still don’t bother with DANE. Why?

  1. Low perceived threat: CA compromise is news; fraudulent certs used in SMTP MITM is rarer
  2. Operational risk: Misconfigured TLSA = mail stops flowing. Monitoring required
  3. Validator support: Not all sending mail servers validate DANE yet
  4. Complexity spiral: DNSSEC + DANE + key rotation + TLSA updates = staffing problem

When to deploy:

  • You have DNSSEC operational expertise
  • You have in-house ability to monitor TLSA records
  • You handle sensitive email (HNI clients, GCC-region customers, government)
  • You have regulatory requirement (rare, but exists)

When NOT to deploy:

  • You haven’t deployed DNSSEC (DANE requires it)
  • Your team lacks DNS/PKI expertise
  • You can’t staff ongoing TLSA monitoring
  • Your threat model doesn’t include “CA-compromise-based MITM”

The Real Story

Plotting this against actual adoption:

Phase 0:     ~15% of mail-enabled domains (no controls)
Phase 1:     ~43% (SPF + DMARC, mostly p=none)
Phase 1.5:   ~26% (SPF + DMARC enforced)  ← CLIFF. 74% never leave here.
Phase 2:     ~1.1% (+ MTA-STS)
Phase 2.5:   ~0.01% (+ TLS-RPT, + CAA)
Phase 3:     ~6.75% (+ DNSSEC)            ← Different population; often regulatory
Phase 4:     ~0.73% (+ DANE)              ← Bleeding edge

Organizations don’t progress linearly. Phase 3 orgs (DNSSEC) aren’t necessarily Phase 1.5 orgs. They’re often separate populations: regulated industries (government, defence, financial) who have DNSSEC as a hard requirement, vs. commercial organizations content with Phase 1.5.

The gap: The effort-to-impact ratio peaks at Phase 1.5 (enforced DMARC). Phases 2 and 2.5 offer real gains with minimal effort. Phase 3+ is regulatory/advanced threat model only.

Implementation Roadmap (For Most Organizations)

If you’re at Phase 0: Deploy Phase 1 immediately. This is not optional.

If you’re at Phase 1 (p=none):

  1. Analyze DMARC reports (1–2 weeks)
  2. Identify all legitimate mail senders
  3. Update SPF
  4. Move to p=quarantine for 1 week
  5. Flip to p=reject
  6. Expected effort: 4–8 weeks. Expected impact: 70–85% reduction in spoofing attacks.

If you’re at Phase 1.5 (and have the bandwidth):

  1. Deploy MTA-STS (4–8 hours) — this is easy and valuable
  2. Deploy TLS-RPT so you know if MTA-STS is working (2–4 hours)
  3. Deploy CAA for cert issuance control (1 hour)
  4. Expected effort: 8–16 hours spread over 2–3 weeks. Expected impact: Encryption of inbound SMTP, visibility into TLS failures.

If you’re at Phase 2.5:

  1. Evaluate DNSSEC need:
    • Regulatory requirement? Deploy it.
    • No requirement? Skip to DANE when/if you have DNS expertise.
  2. If deploying DNSSEC: Expect 2–8 weeks and permanent operational overhead.
  3. If skipping to DANE: You’ll need DNSSEC anyway, so this is a sequencing question.

If you have DNSSEC:

  1. Evaluate DANE threat model (CA compromise + MITM):
    • High-sensitivity email? Deploy DANE.
    • Standard commercial org? Probably not worth the operational burden.
  2. If deploying DANE: 4–8 hours setup + ongoing TLSA monitoring.

The Uncomfortable Truth

The biggest failure point in email security is Phase 1 to Phase 1.5. Organizations publish DMARC in reporting mode, assume they’re protected, and never move to enforcement. This is the low-hanging fruit that goes unpicked.

MTA-STS adoption at 1.1% is inexplicable given the effort-to-impact ratio.

DNSSEC adoption at 6.75% reflects reality: it’s operationally expensive and solves problems most organizations don’t face (though some absolutely do).

DANE at 0.73% is appropriate: it’s a tool for specific threat models, not a general requirement.

If you’re running an organization: Focus on Phase 1.5 enforcement. That’s where the biggest security gain lives.

If you’re running a managed service provider or security consultancy: Phase 1.5 enforcement and Phase 2/2.5 deployment are your highest-ROI services. DNSSEC/DANE are for specialist clients with specific needs.

If you’re a domain owner concerned about security: You probably don’t need to reach Phase 4. Phase 1.5 stops 70% of attacks. Phase 2.5 adds encryption and observability. That’s sufficient for nearly all commercial operations.

Next Steps

  1. Audit your current phase
  2. Identify blockers for progression
  3. Prioritize Phase 1.5 enforcement if you’re at Phase 1
  4. Add Phase 2 (MTA-STS) and Phase 2.5 (TLS-RPT, CAA) if you have bandwidth
  5. Defer Phase 3 and 4 unless regulatory requirement or specialized threat model

Email security is an enablement journey, not a checkbox exercise. Each phase unlocks new capabilities. But most organizations don’t need all of them.

Summary

Computers, networking, DNS, TLS, SMTP/Email etc. are all really complex topics. The security of all of this and how the world interconnects is even more so. There’s a real tendency for some types to think because something can be done it means it MUST be done. That’s not how this game works. In a time when organisations are still getting spoofed, where passwords are Winter2025!! and where open directories are a major problem, it’s probably sensible to focus on threats that you are actually facing and that you can manage before you run onto defending against something that may have never even been exploited before in the wild. (it’s complicated because the world is a vast place!). Hopefully my blog here (with a massive help from Claude because it’s Sunday and after all the prompting re-writing the same thing again entirely in my own words seems pointless) helps people think about this stuff a bit more.

Related articles

Copyright (c) Xservus Limited