Email was designed in 1982 for a world built on trust: anyone could connect to a server and say “hello, I am writing from your-bank.com“. Four decades later, that sentence is still free to utter. The only thing that has changed is that three DNS records and a handful of cryptographic signatures now try to prove it is a lie.
The root of the problem lies in the delivery model. SMTP (Simple Mail Transfer Protocol) separates two identities that users believe are a single one: the envelope (the address in the MAIL FROM command, which receives bounces) and the header (From:, what you actually see in your mail client). Nothing forces them to match. And by default, the receiving server decides whether to accept the message without checking anything at all.
SPF: the list of who may send on your behalf
SPF (Sender Policy Framework, RFC 7208) came first. The idea is a TXT record in the domain’s DNS listing which servers are authorised to send mail using that domain in the envelope:
v=spf1 include:_spf.google.com ip4:203.0.113.10 -all
The receiver takes the IP of the server talking to it, looks up the record for the envelope domain and evaluates the mechanisms in order: ip4, ip6, a, mx, include, exists, each with a result prefix (+ pass, - fail, ~ softfail, ? neutral). The trailing all is the catch-all: -all means “everything else is fraud”, ~all means “everything else is suspicious but I will let it through”.
SPF has two limits that hurt. The first is by design: it only authenticates the envelope, not the header. An attacker can send with a perfectly valid envelope and put a different From: on top. The second is performance: every include, a, mx, ptr or exists costs a DNS lookup, and the RFC caps this at 10 lookups plus 2 void lookups. Exceeding it does not raise an error: it returns permerror, and the message is evaluated as if no SPF existed. This is the classic failure of companies chaining marketing, CRM and ticketing providers.
DKIM: the signature that travels with the message
DKIM (DomainKeys Identified Mail, RFC 6376) solves what SPF cannot: it gives integrity and accountability for the message itself, not for the connection. On sending, the server hashes the body (bh=) and a selection of headers, then signs that set with its private key. The result is added as a header:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=sel2026; c=relaxed/relaxed; h=from:to:subject:date; bh=...; b=...
The receiver fetches the public key at sel2026._domainkey.example.com, uses it to verify the signature and, separately, recomputes the body hash to confirm nobody altered it in transit. Details matter: the c= parameter defines the canonicalisation (simple or relaxed) — how whitespace and line breaks are normalised before hashing; a mismatch here invalidates signatures that looked fine. The l= tag allows signing only the first N bytes of the body, a door attackers have used to append malicious text after the signature and one that many verifiers now treat with suspicion. And if a server forwards the message while modifying it, the signature breaks: DKIM is fragile in the face of mailing lists and forwarders, which is exactly why ARC was born.
DMARC: who decides whether the lie matters
DMARC (RFC 7489) is not an authentication mechanism but a policy. It is published at _dmarc.example.com and does three things. First, it demands alignment: it is not enough for SPF or DKIM to pass, they must pass for a domain matching the visible From:. Second, it states what to do on failure: p=none (observe only), quarantine (send to spam) or reject. Third, it defines where reports go: rua for aggregate reports (XML with per-IP counters and results) and ruf for forensic ones, which almost nobody enables because they expose message contents.
v=DMARC1; p=reject; adkim=s; aspf=r; pct=100; rua=mailto:dmarc@example.com
Alignment has two modes per protocol: relaxed (r) accepts subdomains of the same organisational domain, strict (s) requires an exact match. This is the detail that makes DMARC the real arbiter of deliverability: SPF may pass on the envelope domain and DKIM may sign with a third party, but if neither aligns with the From:, the policy still applies.
The forwarder problem
When a message passes through a legitimate forwarder — a mailing list, an alumni mailbox, a server that rewrites the Subject — the signed headers change and SPF no longer matches because the forwarder has a different IP. The message leaves the forwarder with broken signatures and DMARC sends it to quarantine. ARC (Authenticated Received Chain, RFC 8617) mitigates this by adding a seal at every hop: a forwarder that breaks the signatures leaves a record of its own verification, and the receiver can evaluate the whole chain instead of giving up at the first broken signature.
Why spam still gets through
Because adoption is voluntary and uneven. A domain without DMARC is still spoofable; a p=none policy blocks nothing; and real filters combine IP reputation, sender history and content analysis. DNS records are half the job; the other half is the receiver deciding to believe them.
For anyone running a domain, the sensible order is always the same: publish SPF with an explicit all, sign with DKIM and rotate selectors, start DMARC at p=none with rua to inventory who sends mail on the organisation’s behalf, fix the legitimate flows that fail, and only then move to quarantine and reject. Skipping the inventory is the fastest way to stop receiving invoices from your own providers.
