Two things happen to anyone who sends email from their own domain. The newsletter you send to customers lands in their spam folder. And someone you have never met receives a message from your domain, asking them to pay an invoice into a new bank account.
Both have the same cause. A message arrives, and the mail client shows From: CEO <ceo@yourbank.com>. The receiving server has to decide whether yourbank.com really sent it. If it cannot tell, it must either trust forgeries or distrust everyone, your newsletter included.
For the first twenty years of email, it could not tell. In 1982, Jon Postel published RFC 82111. J. Postel, “Simple Mail Transfer Protocol,” RFC 821, August 1982.rfc-editor.org, which defined SMTP. The network was ARPANET, a few hundred hosts at universities and government labs. One server said “I have mail from Alice for Bob”, and the other said “OK”. Nothing in the protocol checked the claim. Any server on the internet can still write any address in the From: line.
Three protocols were added later to close this gap: SPF, DKIM and DMARC. They are usually taught as a list. I find them easier to understand as three attempts at the same problem, where each attempt fixes what the one before it missed. For each one, ask two questions: which domain does it prove, and what breaks the proof?
One limit first. These protocols prove a domain, not a person. Whether alice@example.com was really written by Alice is a separate check: her mail provider makes her log in before it sends mail as her. This post covers the domain half.
Two Senders in Every Message
Before the first attempt, one fact about email explains most of what follows. Every message names its sender twice.
An SMTP session has two parts. First, the two servers talk about routing: who the mail is from, who it is for. This is the envelope, defined today in RFC 532122. J. Klensin, “Simple Mail Transfer Protocol,” RFC 5321, October 2008.datatracker.ietf.org. Then the sending server transmits the message itself, after the DATA command. The message has its own headers, including From:, defined in RFC 532233. P. Resnick, Ed., “Internet Message Format,” RFC 5322, October 2008.datatracker.ietf.org.
The envelope sender, MAIL FROM, is where bounces go. The reader never sees it. The header sender, From:, is what the mail client shows. The two do not have to match, and often they do not. A newsletter sent through a mailing service has MAIL FROM: bounces@mailer.example.net and From: news@example.com. That is normal and legitimate.
So a protocol that “authenticates the sender” has to say which sender. The reader trusts only one of them: the From: line.
First Attempt: Authorise the Server (SPF)
The first idea is the simplest one. The domain owner publishes a list of servers that are allowed to send its mail. The receiver compares the connecting IP address with that list. This is SPF, the Sender Policy Framework, RFC 720844. S. Kitterman, “Sender Policy Framework (SPF),” RFC 7208, April 2014.datatracker.ietf.org.
The list is a DNS TXT record:
example.com. IN TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com mx -all"
; ip4:203.0.113.0/24 These addresses may send for us.
; include:_spf.google So may Google's servers (for Google Workspace).
; mx So may our own mail servers.
; -all Everything else fails.Which domain does SPF prove? The domain in MAIL FROM, the envelope. Not the From: line. This is a design choice with a reason. The envelope sender arrives before the message. A receiver can check SPF at that point and refuse the connection without accepting a single byte of the message. The From: header only arrives later, inside DATA.
That choice leaves the main attack open. An attacker uses their own domain in the envelope, MAIL FROM: x@evil.com, from a server that evil.com’s SPF record allows. SPF passes. Then they write From: ceo@yourbank.com in the header. The reader sees yourbank.com, and SPF has nothing to say about it.
What breaks the proof? Forwarding. When Bob forwards Alice’s message to Carol, Carol’s server sees Bob’s server connect, with Alice’s domain in the envelope. Bob’s server is not in Alice’s SPF record, so SPF fails. Nothing is wrong with the message. SPF fails because it authenticates the path, and forwarding changes the path.
SPF has one more practical limit. Evaluating a record may take at most 10 DNS lookups, and every include:, a and mx costs one. An organisation that sends through many services reaches this limit faster than it expects.
Second Attempt: Sign the Message (DKIM)
If the path cannot be trusted to stay the same, authenticate the content instead. The sending server signs the message. The receiver verifies the signature. This is DKIM, DomainKeys Identified Mail, RFC 637655. D. Crocker et al., “DomainKeys Identified Mail (DKIM) Signatures,” RFC 6376, September 2011.datatracker.ietf.org.
DKIM uses ordinary public-key cryptography, with DNS as the place to publish keys. The domain owner keeps the private key on the sending server, and publishes the public key at a name built from a selector: selector._domainkey.example.com.
The signature travels with the message as a header:
DKIM-Signature: v=1; a=rsa-sha256;
d=example.com; the domain that signs
s=selector1; which key in DNS to use
h=from:to:subject:date; which headers are signed
bh=2jUSOH9NhtVGCQWN...; hash of the body
b=LiIvJeRyqMo0gnzq... the signatureThe selector lets one domain have many keys at once: one for its own servers, one for its newsletter service, one for its help desk. Each service signs with its own key, and a key can be replaced without breaking messages still in transit.
What breaks the proof? Changes to the signed content. Because the signature travels with the message, DKIM survives plain forwarding, which was SPF’s weak point. But a mailing list that adds [list] to the subject or a footer to the body changes the signed bytes, and the signature fails. That is DKIM working correctly: the message did change.
Which domain does DKIM prove? The domain in d=. And d= can be any domain whose key the signer holds. An attacker signs with d=evil.com, using a key they published for evil.com, and writes From: ceo@yourbank.com. The signature is valid. DKIM passes. The reader still sees yourbank.com.
What else does the signature prove? More than its designers needed. SPF can be checked only by the first receiving server, at the moment of delivery. A DKIM signature can be checked by anyone who holds the message, for as long as the public key stays in DNS. When WikiLeaks published the emails of John Podesta, Hillary Clinton’s campaign chairman, in 2016, it used their DKIM signatures88. WikiLeaks, “DKIM Verification.”wikileaks.org to show that they were genuine. A signature meant for spam filters became evidence. Matthew Green has proposed99. M. Green, “Ok Google: please publish your DKIM secret keys,” November 2020.blog.cryptographyengineering.com a fix: providers should rotate their keys and publish the old private keys, so that an old signature proves nothing. This, he writes, would remove “a strong incentive for criminals to steal and leak emails”.
So after two attempts, the receiver can prove two things: this server may send for some domain, and this content was signed by some domain. Neither proof says anything about the domain the reader sees.
Third Attempt: Tie It to the From Line (DMARC)
The missing piece is a link between the proofs and the visible sender. DMARC, Domain-based Message Authentication, Reporting and Conformance, RFC 748966. M. Kucherawy & E. Zwicky, “Domain-based Message Authentication, Reporting, and Conformance (DMARC),” RFC 7489, March 2015.datatracker.ietf.org, adds that link. It calls it alignment.
A message passes DMARC if at least one of these is true:
- SPF passes, and the
MAIL FROMdomain matches theFrom:domain. - DKIM passes, and the
d=domain matches theFrom:domain.
Run the attack again. SPF passes for evil.com. DKIM passes for evil.com. Neither domain matches yourbank.com in the From: line. DMARC fails. For the first time, the domain the reader sees is the domain that was proven.
Only one of the two needs to align, and this is what makes DMARC usable. Forwarding breaks SPF, but DKIM survives, so a forwarded message still passes. A newsletter service is usually not in your SPF record, but if it signs with your domain’s key, it passes through DKIM. By default the match is relaxed: mail.example.com aligns with example.com, because both belong to the same organisational domain.
Alignment is the first half of DMARC. The second half gives the domain owner a voice. The DMARC record says what a receiver should do with a message that fails, and where to send reports:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"| Policy | What the receiver does with a failing message |
|---|---|
p=none | Nothing. Deliver it, and report it. |
p=quarantine | Put it in spam. |
p=reject | Refuse it. |
The reports matter as much as the policy. With rua=, receivers send daily summaries of every message that claimed to come from your domain, with the sending IPs and the SPF and DKIM results. Before DMARC, a domain owner had no way to see who was sending as them. With it, they see both their forgotten services and the attackers.
This answers the spam folder from the first paragraph too. Receivers keep a reputation for every sender. Without authentication, they can only attach it to IP addresses, and those change when you change providers. With DMARC, they know which mail really comes from your domain, so the reputation can attach to the domain itself. Keeping others from sending as you is how your own mail reaches the inbox.
It is also why DMARC is no longer optional. Google’s sender guidelines1010. Google, “Email sender guidelines,” Google Workspace Admin Help.support.google.com require anyone who sends 5,000 or more messages a day to Gmail accounts to set up SPF, DKIM and DMARC, and to pass alignment.
What Is Still Broken
The three protocols together answer the question from the first paragraph. They do not make email safe, and it is worth being exact about where they stop.
Mailing lists. A list changes the subject and the body, and it sends from its own servers. SPF fails because the path changed. DKIM fails because the content changed. DMARC fails, for a message that is completely legitimate.
The Authenticated Received Chain, ARC, RFC 861777. K. Andersen et al., “Authenticated Received Chain (ARC),” RFC 8617, July 2019.datatracker.ietf.org, tried to fix this. Each intermediary records the results it saw and signs that record, so the final receiver can trust results from before the change. ARC needs every intermediary to take part, and too few did. In 2025, an IETF draft proposed ending the ARC experiment. In practice, most mailing lists now take the other way out: they rewrite From: to the list’s own address, so the list’s domain is the one that aligns.
Lookalike domains. DMARC protects one exact domain. It says nothing about yourbank-secure.com or yourbank.co. An attacker who registers such a domain can set up SPF, DKIM and DMARC for it, and every check passes.
Display names. Many mail clients show "Your Bank" <x@evil.com> as only “Your Bank”. The domain is proven, and the reader never looks at it.
These gaps share one cause. SPF, DKIM and DMARC prove which domain sent a message. They do not prove that the domain is the one the reader had in mind.
Deploying It
For a domain owner, the order of work follows from the reports:
- Publish SPF for the servers you know about.
- Turn on DKIM in every service that sends as you, each with its own selector.
- Publish DMARC with
p=noneand arua=address. Change nothing else yet. - Read the reports for a few weeks. You will find services that send as you that nobody remembered. Add them to SPF or set up DKIM for them.
- Move to
p=quarantine, then top=reject. Thepct=tag lets you apply the policy to a share of failing mail first, for example 25%. Go top=rejectonly after DKIM works for every service. Forwarded mail passes through DKIM alone, so without it,p=rejectrefuses your own forwarded messages.
Do the same for domains that send no mail at all: old brand names, typo domains you bought, parked domains. Nobody watches them, which makes them useful to attackers. Two records close them: v=spf1 -all at the domain, and v=DMARC1; p=reject at _dmarc.
The full set of records for a domain fits in a few lines:
; MX: where to deliver mail for this domain
example.com. IN MX 10 mail.example.com.
; SPF: which servers may send for this domain
example.com. IN TXT "v=spf1 mx ip4:203.0.113.0/24 include:_spf.google.com -all"
; DKIM: the public key for selector sel1
sel1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
; DMARC: the policy, and where to send reports
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"Looking Back
Read in order, the three protocols move step by step toward the reader. SPF proves the path, which the reader never sees. DKIM proves the content, signed by a domain the reader never sees. DMARC finally ties both to the From: line, the one name the reader does see.
Each step kept the one before it instead of replacing it. SMTP could not change, because every mail server in the world speaks it. So every fix had to be something a receiver could check on the side, published in DNS, the one shared system every domain already had. That is why email authentication looks bolted on. It is bolted on, and that was the only way to add it.
The remaining gap is the last step toward the reader: from the domain that sent the message to the person the reader thinks sent it. No DNS record can close that.
For a much longer treatment, with tools to check your own records, read Kaspar Etter’s Email explained from first principles1111. K. Etter, “Email explained from first principles.”explained-from-first-principles.com.
References
- J. Postel, “Simple Mail Transfer Protocol,” RFC 821, August 1982.
- J. Klensin, “Simple Mail Transfer Protocol,” RFC 5321, October 2008.
- P. Resnick, Ed., “Internet Message Format,” RFC 5322, October 2008.
- S. Kitterman, “Sender Policy Framework (SPF),” RFC 7208, April 2014.
- D. Crocker et al., “DomainKeys Identified Mail (DKIM) Signatures,” RFC 6376, September 2011.
- M. Kucherawy & E. Zwicky, “Domain-based Message Authentication, Reporting, and Conformance (DMARC),” RFC 7489, March 2015.
- K. Andersen et al., “Authenticated Received Chain (ARC),” RFC 8617, July 2019.
- WikiLeaks, “DKIM Verification.”
- M. Green, “Ok Google: please publish your DKIM secret keys,” November 2020.
- Google, “Email sender guidelines,” Google Workspace Admin Help.
- K. Etter, “Email explained from first principles.”