Email authentication in 2026: SPF, DKIM, DMARC, MTA-STS and BIMI, set up properly

The authentication landscape in 2026 is no longer controversial: you need SPF, DKIM and DMARC aligned, you should have MTA-STS and TLS-RPT published, and if your brand cares about how mail looks in Gmail and Apple Mail you probably want BIMI too. What changed in 2024-2025 is that the three largest mailbox providers — Google (February 2024), Yahoo (February 2024) and Microsoft (May 5, 2025) — moved authentication from “best practice” to mandatory enforcement at 5,000 messages/day. PCI DSS v4.0 made DMARC effectively mandatory for any entity in the cardholder data environment as of March 31, 2025. DORA (effective January 17, 2025) put email authentication into the ICT third-party risk register for every EU financial entity. The cost of getting this wrong is no longer “lower placement” — it is hard SMTP rejections (550 5.7.515 from Microsoft, 550-5.7.26 from Gmail) and audit findings.

This post is the consolidated operator setup guide: the minimum viable configuration for senders below the bulk thresholds, the recommended production baseline for senders above them, and the defensive posture for compliance-scoped senders. With explicit DNS examples, the alignment math that breaks DMARC for new operators, ARC behaviour at the major providers in 2026, the BIMI/VMC pricing reality, and the four authentication troubleshooting scenarios we diagnose most often during audits.

The 2026 authentication stack — what actually runs end-to-end

Before the per-protocol detail, the diagram below shows what each layer does and where it sits in the inbound delivery path. The point is to make explicit that SPF, DKIM and DMARC are not interchangeable controls — they protect different things, fail differently, and the one that “passes” determines what happens next.

The diagram makes explicit the most-misunderstood aspect of DMARC: it does not authenticate anything itself. DMARC is a policy layer that consumes the SPF and DKIM verdicts produced by the receiver, applies the alignment rule (the authenticated domain must match the visible From: header domain or its organisational parent), and decides what to do when alignment fails. SPF and DKIM are the actual authentication; DMARC is the policy engine that turns their verdicts into enforcement.

SPF — the first mile, with hard limits operators forget

SPF (Sender Policy Framework, RFC 7208) authorises which IPs can send for your domain. A receiving MTA fetches your TXT record at the domain name and checks whether the IP that just connected is included.

A minimum SPF record looks like this. Replace _spf.yourprovider.com with your provider’s published include:

yourdomain.com.   TXT   "v=spf1 include:_spf.yourprovider.com -all"

The -all at the end is a hard fail directive: any IP not listed should be rejected. Use ~all (soft fail) only during early SPF rollout when you are uncertain about completeness; promote to -all within four weeks once aggregate DMARC reports confirm zero unauthorised legitimate sources.

The hard limit operators forget: SPF must resolve in 10 DNS lookups or fewer per RFC 7208 Section 4.6.4. Each include:, a, mx, exists, and redirect mechanism costs a lookup; ip4: and ip6: cost zero. Modern senders running Google Workspace + Microsoft 365 + Mailchimp + SalesForce + transactional ESP routinely break this limit because each provider publishes its own nested includes that internally chain to 3-7 lookups. When the limit is exceeded, RFC 7208 says the receiver MUST treat the SPF result as permerror — and most receivers in 2026 (Gmail, Microsoft, Apple, ProtonMail, Fastmail) translate that to “no SPF pass available” for DMARC alignment purposes, breaking your authentication entirely.

The fix is SPF flattening (resolving the nested includes at build time and publishing only the resulting IP ranges), available either as a one-off DNS exercise or as a managed service from PowerDMARC, EasyDMARC, Scoutdns or self-hosted with spf-tools. We cover the operator-grade flattening approach in detail in our SPF 10-lookup limit fix guide. The short version: most senders need flattening once they cross 4-6 sending services.

The second SPF subtlety: SPF authenticates the envelope sender (MAIL FROM / Return-Path), not the visible From: header. If your platform uses its own bounce-handling domain (e.g., bounces.mailchimp.com) for Return-Path, SPF will pass against that bounce domain, but DMARC alignment will fail because the bounce domain does not match your visible From:. This is the root cause of “SPF passes but DMARC fails” — the platform must offer a custom Return-Path option that aligns with your domain, or you fall back to DKIM alignment for DMARC. Most modern ESPs (Mailgun, SendGrid, Postmark, Amazon SES, Mailchimp Premium, Brevo) support custom Return-Path on paid tiers; cheap SaaS bulk senders often do not.

DKIM — the cryptographic signature, where 1024-bit keys still survive in 2026

DKIM (DomainKeys Identified Mail, RFC 6376) signs each message with a private key whose public component is published in DNS at selector._domainkey.yourdomain.com. The receiver fetches the public key, verifies the signature, and reports DKIM as pass or fail.

Generate the key on your sending MTA. For OpenDKIM:

opendkim-genkey -b 2048 -d yourdomain.com -s m1 -v

The output is a public key suitable for DNS publishing. Use 2048-bit keys, not 1024-bit. RFC 8301 deprecated SHA-1 and recommended 2048-bit RSA in 2018; in 2026, all major receivers verify 2048-bit by default and Gmail’s DKIM documentation recommends 2048-bit as the production minimum since 2023. Yet our audits in 2026 still find 30-40% of legacy installations running 1024-bit DKIM keys (visible in the DNS as k=rsa; p= followed by a short base64-encoded key). These pass at most receivers but Microsoft has begun flagging 1024-bit keys with reduced trust scores in their reputation system since Q3 2025, and in practice we see 1024-bit signers underperform 2048-bit signers by 3-7 percentage points of placement at the consumer mailboxes.

DKIM key rotation matters. Operators sign with a fixed selector indefinitely, never rotating, and that’s a security and operational risk. The recommended pattern is at least annual rotation with a two-selector overlap window (publish new selector, sign with new selector, leave old selector published for 30 days to verify forwarded mail signed with old selector still passes, then retire old selector). Our DKIM rotation guide covers the operational details for PowerMTA and OpenDKIM.

The DKIM selector is just a label that lets you publish multiple keys simultaneously (for rotation, or for separate sending services). Use descriptive names: m1, m2 for monthly rotation; marketing, transactional, support for service-specific keys. Avoid the default default or mail selectors that DKIM-aware spam filters specifically recognize as low-effort defaults.

DMARC — the policy layer, with three policies and one trap

DMARC (Domain-based Message Authentication, Reporting & Conformance, RFC 7489) sits on top of SPF and DKIM. It does not authenticate; it tells the receiver what to do when SPF and DKIM both fail to align with the visible From: header.

The three policies are none, quarantine, and reject. The minimum DMARC record:

_dmarc.yourdomain.com.   TXT   "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=r; aspf=r"

What each tag does:

• p=none: receivers report on alignment failures but take no action. This is the starting policy. It is not a deployment endpoint — it exists to give you visibility into what your sending estate actually looks like before you turn on enforcement.
• p=quarantine: receivers may route alignment failures to spam. Most receivers honour this from day one.
• p=reject: receivers MUST reject alignment failures with a 5xx SMTP error.
• rua=mailto:: aggregate report destination. These XML reports arrive daily and document who is sending mail claiming to be from your domain.
• ruf=mailto:: forensic (per-message) report destination. Mostly Microsoft and a few smaller providers send these; Gmail does not.
• fo=1: request forensic reports for any failure. Default fo=0 only reports failures of both SPF and DKIM.
• adkim=r / aspf=r: relaxed alignment (organisational domain match). adkim=s / aspf=s is strict (exact domain match).

The trap: p=reject deployed without 30+ days of p=none aggregate reporting will catastrophically reject legitimate mail from sources you didn’t know existed. Every operator we audit has at least one legitimate sender they forgot — calendar invites from a SaaS, transactional mail from a payment processor, a marketing automation that someone in another department signed up for. The rua reports surface these in 7-14 days. Move from p=none → p=quarantine pct=10 → pct=25 → pct=50 → pct=100 → p=reject over 60-90 days, never faster.

The Microsoft May 5, 2025 enforcement made p=none mandatory for senders >5,000/day to Outlook.com, Hotmail.com and Live.com — which means roughly the same threshold as Gmail’s February 2024 enforcement. Both are baseline thresholds; p=quarantine or p=reject are not yet required by the major consumer receivers, but they are required by PCI DSS v4.0 (March 31, 2025) for any entity in the cardholder data environment, and they are increasingly required by cyber insurance underwriters as standard policy attestation.

ARC — the forwarding problem, and how the major providers handle it in 2026

The structural problem ARC (Authenticated Received Chain, RFC 8617) solves: DKIM signatures break when forwarders modify the message (added headers, footer disclaimers, body re-encoding); SPF breaks at every forwarder because the forwarder’s IP is not in the original sender’s SPF. Without ARC, a perfectly authenticated message from [email protected] forwarded through someone’s @employee.gov mailing list to their personal @gmail.com arrives with both SPF and DKIM failing, triggers DMARC p=reject if the bank has it, and is rejected — even though it is legitimate.

ARC adds an Authentication-Results header at each forwarding hop that records the SPF/DKIM verdict the forwarder saw upstream, plus an ARC-Seal signature so downstream receivers can trust the upstream verdict was not tampered with. Gmail rolled out ARC verification in 2019 and was the first major receiver to apply ARC verdicts to alignment decisions; Yahoo followed in 2020; Microsoft Exchange Online auto-enabled ARC sealing for forwarded mail in mid-2024.

The 2026 reality, by major provider:

Provider	ARC sealing on forwarded mail	ARC verification on inbound	Notes
Gmail / Workspace	Yes (since 2019)	Yes; full ARC chain validation	The reference implementation
Microsoft Exchange Online	Yes (auto-enabled mid-2024)	Yes	Was the laggard until 2024; now defaults on
Outlook.com / Hotmail	Yes (since 2024)	Yes	Same Microsoft codebase as Exchange
Apple iCloud Mail	Yes (since 2022)	Yes	Apple-specific behaviour: ARC trust threshold is conservative
Yahoo Mail	Yes (since 2019-2020)	Yes	Strict on ARC chain integrity
Zoho Mail	Yes (since 2023)	Yes	Late adopter, now compliant
ProtonMail	Yes (since 2023)	Yes	Privacy-focused, full RFC 8617
Fastmail	Yes (since 2021)	Yes	Reference for small EU receivers
AWS SES	Yes (Mail Manager, 2024)	Partial (inbound rules)	ARC is in SES Mail Manager, not legacy SES
Mailgun	Yes (since 2024)	Yes	Updated for Microsoft enforcement
Postmark	Yes (since 2023)	Yes	Documented in their authentication guide
Web.de / GMX (United Internet)	Yes	Yes	Stable behaviour, FBL available
Orange.fr / Wanadoo	Required since September 2024	Yes	ARC sealing mandatory on forwarded mail to Orange.fr per their 2024 postmaster site update
T-Online.de / Magenta	Yes	Yes	Increasingly enforces on aggregated chains
Free.fr	Yes	Yes	Applies stricter throttles to non-ARC-sealed traffic
Libero.it / Virgilio.it	Partial	Yes	Italian regional provider, compliance improving
Yandex Mail	Partial	Yes	Russian receiver, geographic filtering applies

The operator implication: if you operate any kind of forwarder (mailing list, alias service, MX-level forwarding) you must ARC-seal. The major MTA platforms support it: PowerMTA via configuration; Postfix via OpenARC; Mailgun, Postmark, Mailchimp and Amazon SES Mail Manager handle it transparently. We cover the OpenARC + Postfix implementation in detail in our ARC guide.

DMARC adoption at the major mailbox providers in 2026

The chart below shows the percentage of inbound mail that the four major providers report applying DMARC enforcement to, based on their published transparency data and Validity’s January 2025 industry analysis. The trend is unambiguous: enforcement is rising on the receiving side faster than publishing is rising on the sending side, which means the gap (senders without DMARC, receiving providers requiring it) is widening, not closing.

DMARC enforcement coverage on inbound side vs DMARC publishing coverage on sender side, Q1 2026

Categoría	% of inbound mail / domains
Gmail	97
Microsoft (Outlook.com)	94
Yahoo Mail	95
Apple iCloud	89
Sender domains with DMARC published	16

Inbound enforcement percentages are derived from each provider's published transparency data and from Sinch Mailgun + Red Sift industry analyses Q1 2026. The 16% sender-side publishing rate is from Validity's January 2025 DMARC adoption study (a staggering 84% of domains and subdomains used in email From addresses do not have a published DMARC record; of the small percentage that do, 7.64% have invalid records). The implication for senders: receiver enforcement is universal, sender adoption is ~1 in 6, and the gap is the operational opportunity. Microsoft's May 5, 2025 enforcement closed the last major receiver gap. The next major shift will be when major receivers raise the minimum policy from p=none to p=quarantine for bulk senders — Gmail has telegraphed this as 'late 2026 or 2027' in postmaster communications but no firm date is confirmed.

MTA-STS and TLS-RPT — the transport-security layer most senders skip

MTA-STS (RFC 8461) tells receiving MTAs that your domain only accepts mail over TLS, with which valid certificates, against which MX hosts. TLS-RPT (RFC 8460) is a complementary reporting mechanism that publishes daily reports of TLS negotiation attempts (successes, failures, certificate issues, downgrade attempts).

Together they prevent two attacks: STARTTLS-stripping (a network attacker downgrades the connection to plaintext by intercepting the EHLO response) and MX-record spoofing (an attacker injects a malicious MX record with a valid certificate for a different domain). MTA-STS makes both attacks fail closed: the receiving MTA sees the policy in DNS, fetches the policy file over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, and rejects mail that does not match.

Setup is two DNS records plus one HTTPS-served file:

_mta-sts.yourdomain.com.   TXT   "v=STSv1; id=20260408000000Z"
_smtp._tls.yourdomain.com. TXT   "v=TLSRPTv1; rua=mailto:[email protected]"

And the policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mail1.yourdomain.com
mx: mail2.yourdomain.com
max_age: 86400

Three modes: none (don’t apply), testing (collect TLS-RPT data without enforcement), enforce (reject non-TLS / cert-mismatched mail). Deploy in testing mode for 14-30 days first; review TLS-RPT reports; promote to enforce only after confirming zero unexpected failures. The most common bug: you publish mx: matching your current MX hostname but then your provider rotates the MX hostname during a maintenance window without telling you, breaking inbound mail until you update the policy. Add MX rotation events to your runbook before deploying enforce.

Our MTA-STS implementation guide covers the full setup including AWS S3, Cloudflare Workers and self-hosted policy server options.

BIMI, VMC and CMC — the actual cost breakdown in 2026

BIMI (Brand Indicators for Message Identification) displays your verified brand logo next to your messages in supporting clients (Gmail, Apple Mail, Yahoo Mail, Fastmail). The technical setup is one DNS record:

default._bimi.yourdomain.com.   TXT   "v=BIMI1; l=https://yourdomain.com/bimi/logo.svg; a=https://yourdomain.com/bimi/cert.pem"

The l= points to your SVG logo (Tiny SVG profile only — most subset of SVG); the a= points to your VMC (Verified Mark Certificate). BIMI is conditional on DMARC at p=quarantine or p=reject with full alignment for at least 14 days; you cannot deploy BIMI before you have DMARC enforcement.

Cost reality 2026 (verifiable from CA pricing pages and operator quotes during audits):

• Self-signed BIMI without VMC: works in Gmail and Yahoo (display the logo without certificate verification badge). Apple Mail and most enterprise email clients require VMC. Cost: zero, but limited reach.
• VMC from DigiCert or Entrust: $1,499-1,999/year for a single domain. Required for Apple Mail logo display and for the verification checkmark badge in Gmail/Yahoo. Trademark registration prerequisite (registered trademark, not pending application).
• CMC (Common Mark Certificate): ~$799/year, available since late 2024 from DigiCert. CMC works for organisations that do not have a registered trademark — it requires identity verification but accepts the SVG logo without trademark proof. CMC displays the logo in Gmail and Apple Mail but without the “verified mark” badge that VMC provides.
• Trademark registration cost (if you don’t already have one): EUIPO €850+ for an EU trademark covering one class; USPTO $250-$350 per class for US trademarks. Adding 12-18 months timeline if filing from scratch.

The honest operator math: BIMI/VMC justifies its cost only when your brand is consumer-facing and brand recognition in the inbox materially affects open rates. For B2B SaaS where your audience is sophisticated and your domain is the brand recognition cue, BIMI’s marginal benefit is small. For consumer financial services, e-commerce and anti-impersonation use cases, the $1,499/year VMC is reasonable insurance against domain spoofing on an authenticated brand. We cover the full BIMI/VMC/CMC decision matrix in our BIMI guide.

Choose your baseline — the decision tool

The minimum vs recommended vs defensive baseline question depends on your volume, provider mix, compliance scope and operational maturity. Use the tool below to get a calibrated recommendation; the math behind it reflects the actual deployment patterns we audit across 100+ operator engagements.

The tool’s logic, in summary:

• Tier 1 (minimum viable) is appropriate for senders below 5,000/day to consumer mailboxes with no PCI/DORA scope. SPF + DKIM + DMARC p=none, nothing else.
• Tier 2 (recommended production) is appropriate for senders above the bulk thresholds, European-heavy mixes (where ARC and Orange.fr behaviour matter), Apple-heavy mixes (where BIMI logo benefits exist), or any GDPR-scoped sender. Adds MTA-STS enforce, TLS-RPT, ARC sealing where applicable, BIMI with self-signed SVG.
• Tier 3 (defensive enterprise) is mandatory for PCI DSS v4.0 / DORA / multi-framework compliance scope, or for any consumer-facing brand with serious impersonation risk. Adds DMARC p=reject on parent + subdomains, full BIMI with VMC, ARC on every forwarder, CAA records.

Alignment vs technical pass — the distinction that breaks DMARC for new operators

This is the single most-misunderstood DMARC concept and the source of perhaps 60% of “DMARC fails despite SPF/DKIM passing” tickets we see during audits. The distinction matters because DMARC requires alignment, not technical pass.

Technical pass: SPF says “this connecting IP is authorised by the envelope sender’s SPF record”. DKIM says “this signature verifies against the public key at the signing domain”. Both are true, the receiver records both as pass.

Alignment: the authenticated domain (the SPF envelope sender domain or the DKIM signing domain) must match the visible From: header domain, either exactly (strict, s) or at the organisational domain level (relaxed, r).

The classic break: you send through Mailchimp from From: [email protected]. Mailchimp sets the envelope Return-Path: [email protected] and DKIM-signs with d=mailchimp.com (their default behaviour). SPF passes (Mailchimp’s IP is in bounces.mailchimp.com’s SPF), DKIM passes (Mailchimp’s signature verifies). DMARC fails: the envelope (bounces.mailchimp.com) does not align with yourdomain.com, and the DKIM signing domain (mailchimp.com) does not align with yourdomain.com. Two passes, one DMARC fail.

The fix is one of:

1. Custom Return-Path at the ESP (Mailchimp Premium, Mailgun paid, SendGrid, Amazon SES, Brevo all support this) so the envelope domain becomes a subdomain of yours like bounces.yourdomain.com, aligning SPF.
2. Custom DKIM signing where the ESP signs with d=yourdomain.com (or a subdomain you delegate). All major ESPs support this on paid tiers.
3. Both, which is the production-grade configuration.

The diagnostic: read your DMARC rua aggregate XML reports. The <auth_results> section shows you the SPF and DKIM verdicts AND the domains they authenticated. If dkim shows <domain>mailchimp.com</domain> but your visible From: is @yourdomain.com, that is alignment failure even though <result>pass</result>.

Reading DMARC aggregate reports — what the XML actually means in practice

The rua reports are XML files mailbox providers send daily summarising every message that claimed to be from your domain. The structure that matters:

<record>
  <row>
    <source_ip>192.0.2.10</source_ip>
    <count>15</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>yourdomain.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mailchimp.com</domain>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounces.mailchimp.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

What this record tells you: a message claiming to be from yourdomain.com was sent from IP 192.0.2.10 (Mailchimp), 15 instances over the reporting period. SPF passed technically (<result>pass</result> for bounces.mailchimp.com) but failed alignment (the envelope domain doesn’t match your From:). DKIM passed technically (mailchimp.com signature) but also failed alignment. The DMARC verdict (<dkim>fail</dkim><spf>pass</spf> in policy_evaluated) refers to alignment, not technical pass — so you read this as “SPF aligned, DKIM did not align”. Disposition was none because your policy is p=none.

The operational pattern: parse RUA XML, identify the source IPs, classify each source as legitimate-and-aligned, legitimate-but-not-aligned, or unknown. The legitimate-but-not-aligned bucket needs configuration changes; the unknown bucket is either spoofing or a forgotten sending integration. Tools that handle this automatically: Postmark DMARC Digest (free for 1 domain), Dmarcian (paid), EasyDMARC, PowerDMARC, Valimail, or the self-hosted parsedmarc + Elasticsearch + Kibana stack we recommend for senders with 5+ domains.

Authentication troubleshooting — the four scenarios we diagnose most

Scenario 1 — DMARC fails despite SPF and DKIM passing. Almost always the alignment-not-technical-pass distinction described above. Check the <auth_results> section of an aggregate report, identify which domain SPF/DKIM authenticated, compare to your From: header. Fix: custom Return-Path or custom DKIM signing at the ESP.

Scenario 2 — SPF returns permerror at major receivers. Almost always the 10-DNS-lookup limit. Use dig +short txt yourdomain.com to fetch your record, then count includes recursively. If you have more than 6 includes from common providers (Google Workspace, Microsoft 365, Mailchimp, Salesforce, Mailgun, etc.), you are likely over the limit. Fix: SPF flattening (manual DNS or service like PowerDMARC’s PowerSPF, EasyDMARC’s hosted SPF, or self-hosted with pyspf-tools).

Scenario 3 — DMARC reports show suspicious unknown sources. Sometimes spoofing (an attacker is sending from your domain), more often forgotten sending integrations — the marketing automation a colleague signed up for in 2022, the calendar invite forwarder, the help desk ticket notifier. Investigate every unknown source IP via WHOIS and DNS reverse lookup before assuming it’s malicious. Fix legitimate sources by adding their SPF includes or signing them under your DKIM. Block illegitimate sources by tightening to p=quarantine or p=reject after confirming the legitimate sources are aligned.

Scenario 4 — Forwarded mail fails DMARC at p=reject. The forwarding problem ARC was designed for. Either you are receiving forwarded mail at a domain with p=reject (which is the desired behaviour — alignment fails after forwarding, the message is rejected) or you are sending mail that is being forwarded and the forwarder is not ARC-sealing. For senders, this is mostly a Microsoft Exchange Online forwarding issue (now resolved post-mid-2024 with auto-ARC) or a small mailing-list software issue (Mailman 3 supports ARC sealing, older Mailman 2 does not). Fix: confirm your major forwarders ARC-seal, document mailing list members on p=reject domains, advise affected operators to publish p=quarantine or use ARC-aware forwarders.

The minimum vs the recommended vs the defensive configuration — explicit DNS examples

Tier 1 — Minimum viable (under 5,000/day, no compliance scope, single sending domain):

yourdomain.com.       TXT   "v=spf1 include:_spf.yourprovider.com -all"
selector1._domainkey  TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AM..." (2048-bit)
_dmarc.yourdomain.com TXT   "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1; adkim=r; aspf=r"

Tier 2 — Recommended production (above bulk thresholds, multi-source, GDPR-scoped):

Tier 1 records, plus:

_mta-sts.yourdomain.com.     TXT   "v=STSv1; id=20260408000000Z"
_smtp._tls.yourdomain.com.   TXT   "v=TLSRPTv1; rua=mailto:[email protected]"
default._bimi.yourdomain.com TXT   "v=BIMI1; l=https://yourdomain.com/bimi/logo.svg"
_dmarc.yourdomain.com        TXT   "v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=r; aspf=r"

Plus the MTA-STS policy file served at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt in enforce mode.

Tier 3 — Defensive enterprise (PCI DSS, DORA, multi-framework):

Tier 2 records, plus:

_dmarc.yourdomain.com        TXT   "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected],mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s"
default._bimi.yourdomain.com TXT   "v=BIMI1; l=https://yourdomain.com/bimi/logo.svg; a=https://yourdomain.com/bimi/vmc.pem"
yourdomain.com.              CAA   "0 issue \"digicert.com\""
yourdomain.com.              CAA   "0 issuewild \";\""

CAA records constrain which CAs can issue certificates for your domain — defensive against rogue cert issuance, required by PCI DSS v4.0 in practice for cardholder-data domains. Use strict alignment (adkim=s / aspf=s) only after confirming all sending integrations sign with exact-domain DKIM.

Common mistakes we see during audits

• Multiple SPF records published: RFC 7208 says only one SPF record per domain. Publishing two TXT records that both start with v=spf1 is invalid and most receivers treat it as permerror. Always merge into a single record.
• DKIM keys never rotated since deployment in 2017. Rotate annually minimum.
• MTA-STS in enforce mode pointing to a stale MX hostname that was replaced during a provider migration. Add MX rotation to runbooks.
• DMARC p=reject deployed without 30+ days of p=none aggregate reporting. Catastrophic mail loss for legitimate sources you forgot existed.
• rua reports going to a mailbox no one reads. Reports without parsing are decorative, not operational.
• BIMI deployed without VMC/CMC and the operator surprised that Apple Mail doesn’t show the logo. Apple requires VMC; Gmail and Yahoo accept self-signed but with limited verification badge.
• Subdomains without their own DMARC record inherit the parent policy via sp= tag, but the inheritance behaviour is subtle. Explicitly publishing per-subdomain DMARC removes ambiguity.
• Forgotten sending integrations appearing in aggregate reports after migration — the marketing tool from three years ago, the help desk that sends from a subdomain, the calendar invite gateway. Audit every source surfaced by rua reports during the first 30 days.

Tools that actually work in 2026

For each layer, the tooling we use during audits and recommend to clients:

• SPF lookup limit check: dig +short txt yourdomain.com plus the SPF flattening guide for resolution. MXToolbox SPF lookup tool for visualisation.
• DKIM verification: opendkim-testkey -d yourdomain.com -s selector1 -vvv from a server with the key locally installed. Mail-tester.com for end-to-end including DKIM.
• DMARC syntax validation: dmarcian.com/dmarc-inspector or easydmarc.com/tools/dmarc-record-checker.
• MTA-STS policy validation: the Hardenize.com MTA-STS analyser is the most thorough public tool. Self-test by curl https://mta-sts.yourdomain.com/.well-known/mta-sts.txt.
• TLS-RPT reports: most tooling vendors lag here; manual inspection of incoming reports is fine until volume justifies a parser.
• Aggregate report parsing: Postmark DMARC Digest (free for 1 domain), Dmarcian, EasyDMARC, PowerDMARC, Valimail, or self-hosted parsedmarc + Elasticsearch + Kibana.
• End-to-end placement test: GlockApps, Mail-tester, Litmus inbox preview — all give different perspectives. We use GlockApps for placement, Mail-tester for technical pass, Litmus for client rendering.

The honest operator stance: tooling matters less than discipline. A free Postmark DMARC Digest reviewed weekly produces better authentication outcomes than a $5,000/year platform that nobody opens. Pick the cheapest tool whose reports you will actually read; upgrade only when you outgrow its scope (multi-domain reporting, alerting, integration with SIEM, etc.).