Email Authentication Explained: SPF, DKIM and DMARC for Defenders

Email remains the number-one delivery vehicle for phishing, business email compromise and malware, and almost all of it depends on one weakness: the From: address a recipient sees is trivial to forge unless you publish the right authentication records. This article is written for the blue team. It explains SPF, DKIM and DMARC from a purely defensive angle — what each control proves, how the three interlock, how to read the telemetry they produce, and how to move your domain to an enforcing policy without breaking legitimate mail.

Why email spoofing is so easy by default#

SMTP was designed in an era of mutual trust and has no built-in identity verification. There are two distinct sender identities in every message: the envelope sender (the MAIL FROM used during the SMTP transaction, also called the Return-Path) and the header From that mail clients actually display. An attacker can set both to whatever they like. Without authentication records, a receiving server has no cryptographic or policy basis to reject a message claiming to come from your domain. The three standards below add that basis, each covering a different gap.

SPF: authorising the sending infrastructure#

Sender Policy Framework (SPF) is a DNS TXT record that lists which IP addresses and hosts are allowed to send mail using your domain in the envelope sender. A receiver looks up v=spf1 ... for the envelope domain and checks whether the connecting IP is authorised. The record ends with an all mechanism: -all means hard fail (reject anything not listed), ~all means soft fail (accept but mark), and +all is dangerous and should never be used. SPF has two important limits: it validates the envelope sender, not the visible header From, and it breaks on forwarding because the forwarder becomes the new connecting IP. It also caps at ten DNS lookups, so sprawling include: chains can silently push a record to permerror.

DKIM: cryptographically signing the message#

DomainKeys Identified Mail (DKIM) attaches a digital signature to outbound messages. Your mail platform signs selected headers and the body with a private key; the matching public key is published in DNS at selector._domainkey.yourdomain. A receiver recomputes the hash and verifies the signature, proving the signed content was not altered in transit and that it was signed by a key your domain controls. Because the signature travels inside the message, DKIM survives most forwarding, unlike SPF. Rotate selectors periodically, use at least 2048-bit keys, and retire old selectors so a leaked historical key cannot be abused.

DMARC: alignment, policy and reporting#

DMARC ties SPF and DKIM to the header From that users actually see, through a concept called alignment. A message passes DMARC if it passes SPF and the SPF domain aligns with the From domain, or if it passes DKIM and the DKIM domain aligns — only one is required. The DMARC policy is a DNS TXT record at _dmarc.yourdomain with a policy of p=none (monitor only), p=quarantine (send to spam) or p=reject (refuse). Crucially, DMARC also requests reports: aggregate XML reports via rua= and, where offered, forensic samples via ruf=. These reports are your primary detection telemetry.

The attack surface these controls address#

Understanding what you are defending against helps you tune policy. Exact-domain spoofing forges your own domain in the From address and is precisely what DMARC at enforcement stops. Cousin or look-alike domains (registering a visually similar name) are not covered by your DMARC record and require brand monitoring and user awareness instead. Display-name impersonation keeps a legitimate address in the envelope but sets a misleading display name, which authentication cannot catch and which needs client-side warnings. Knowing these boundaries prevents a false sense of security once DMARC is at reject.

Detection: reading DMARC aggregate reports#

Aggregate (RUA) reports arrive daily as XML from each receiver, summarising message counts grouped by source IP, SPF result, DKIM result and DMARC disposition. Feed them into a parser or a hosted dashboard rather than reading raw XML. Watch for three signals: unknown sending IPs passing or failing for your domain (a marketing tool nobody told you about, or an attacker), legitimate sources failing alignment (a service that signs with the wrong domain), and volume spikes to reject which may indicate an active spoofing campaign. In your mail gateway and SIEM, index the Authentication-Results header so you can query dmarc=fail, dkim=fail and spf=softfail across inbound mail and alert on impersonation of your executives.

Detection: header and log signals#

Beyond DMARC reports, defenders should baseline normal authentication outcomes. In Microsoft 365, message trace and the compauth value expose composite authentication decisions; in Google Workspace, the BigQuery email logs and the Security Investigation Tool surface SPF/DKIM/DMARC verdicts. Create detections for inbound mail that fails DMARC yet claims to be from an internal or partner domain, for sudden appearance of a new selector in your own DNS you did not create, and for outbound mail from your domain reported as failing by external receivers — the last is often the first sign that a shadow-IT system or compromised account is sending on your behalf.

Mitigation and hardening: rolling out to enforcement#

Deploy in stages to avoid dropping real mail. First, inventory every legitimate sender — your mail platform, marketing tools, ticketing systems, CRM and payroll. Publish an accurate SPF record ending in -all, keeping under the ten-lookup limit by flattening or removing unused includes. Enable DKIM signing on every source with 2048-bit keys and unique selectors. Then publish p=none with rua= and collect reports for a few weeks until every legitimate stream shows passing alignment. Move to p=quarantine with a low pct and ramp toward 100, then finally to p=reject. Set sp=reject for subdomains and consider publishing a null MX and DMARC reject on non-sending domains so they cannot be abused.

Complementary controls: MTA-STS, TLS-RPT and BIMI#

Authentication answers who sent this; transport security answers was it delivered privately. MTA-STS lets your domain require TLS for inbound SMTP and resist downgrade attacks, and TLS-RPT reports delivery failures. BIMI lets you display a verified brand logo, but only once you are at DMARC enforcement, which makes it a useful incentive to finish the rollout. None of these replace DMARC; they harden the layers around it. Treat them as the second wave after your enforcement policy is stable.

Common pitfalls#

The most frequent failures are self-inflicted. Publishing two SPF records causes a permerror and invalidates SPF entirely — you may only have one. Exceeding the ten DNS lookups silently breaks SPF for large ecosystems. Moving straight to p=reject without a monitoring period reliably blackholes legitimate mail from a forgotten sender. Forgetting subdomain policy leaves marketing.yourdomain spoofable even when the parent is locked down. And treating ~all as equivalent to enforcement is a mistake: soft fail plus p=none stops nothing. Finally, never rely on ruf forensic reports being available — many receivers no longer send them for privacy reasons, so build your detection on aggregate data.

Hardening checklist#

Use this as a quick audit. 1. Exactly one SPF record per domain, ending in -all, under ten lookups. 2. DKIM enabled on every sending source, 2048-bit keys, selectors rotated and old ones retired. 3. DMARC at p=reject with sp=reject and rua flowing to a monitored inbox or platform. 4. Parked and non-sending domains locked with SPF -all and DMARC reject. 5. Inbound gateway indexes Authentication-Results and alerts on executive impersonation and internal-domain DMARC failures. 6. MTA-STS enforce mode and TLS-RPT published. 7. Brand-similar domain monitoring and user training for display-name and look-alike attacks that authentication cannot stop.

FAQ: does DMARC at reject stop all phishing?#

No, and believing it does is dangerous. DMARC at reject stops attackers from forging your exact domain in the header From, which is a large and valuable win because it protects your brand and your own users from internal-looking spoofs. It does nothing about look-alike domains, display-name tricks, compromised legitimate accounts or phishing from unrelated domains. Pair enforcement with inbound filtering, link protection, user reporting and awareness so the residual attack techniques are still caught.

FAQ: will enforcement break forwarding and mailing lists?#

It can, which is why DKIM matters. SPF breaks on plain forwarding because the forwarder is a new source IP, but a valid DKIM signature usually survives, so an aligned DKIM pass keeps the message DMARC-compliant. Mailing lists that modify the subject or body can break DKIM; well-behaved lists mitigate this with ARC (Authenticated Received Chain), which lets a trusted intermediary vouch for the original authentication. Monitor your aggregate reports for forwarding-related failures during rollout so you can whitelist known-good intermediaries before you reach reject.

Conclusion#

SPF, DKIM and DMARC are not three competing options; they are three layers that only deliver protection when combined and pushed to enforcement. SPF authorises infrastructure, DKIM proves integrity, and DMARC binds both to the visible From and gives you the reporting that turns email authentication into a detection capability. The defensive playbook is straightforward: inventory your senders, publish accurate records, monitor aggregate reports until every legitimate stream aligns, then ramp to reject with subdomain coverage. Do that, layer MTA-STS and monitoring on top, and you close the single easiest door attackers use to impersonate your organisation.