The spoofing problem
When Alice mails a paper letter to Bob, trust is built into the envelope: a return address, recognizable handwriting, and a postal service that knows which mailbox the letter came from. Email keeps none of these. As the previous chapter showed, the MAIL FROM and the visible “From” line are just text the sender fills in. Anyone can write From: [email protected] without being Alice. This is email spoofing, and it is the foundation of most phishing.
Authentication rebuilds the missing trust signals in a form machines can verify. Three protocols each recreate one physical signal:
| Physical world | Email equivalent | What it answers |
|---|---|---|
| Approved mailboxes | SPF | Did this come from a server Alice authorized? |
| A unique wax seal | DKIM | Was the message tampered with in transit? |
| Handling instructions | DMARC | What should Bob do if a check fails? |
SPF: which mailboxes may send for me
SPF (Sender Policy Framework) is Alice telling the post office to only accept letters that come from specific mailboxes. The domain owner publishes a list of authorized mail servers in DNS, and the receiver checks the connecting server against it.
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
v=spf1declares an SPF record.include:_spf.google.comauthorizes Google Workspace’s servers. Add moreincludemechanisms for more providers.~allis a soft fail for everything else. The stricter-allrejects outright.
SPF is easy to set up and stops mail sent through unauthorized servers. Its weaknesses: it checks only the connecting server, never the content, and it breaks on forwarding, because a forwarded message arrives from the forwarder’s server rather than an authorized one.
DKIM: a seal only Alice can make
DKIM (DomainKeys Identified Mail) is a wax seal only Alice can produce. Her server signs each message with a private key and publishes the matching public key in DNS. The receiver verifies the signature.
selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq...IDAQAB"
If the signature verifies, two things are proven: the message came from a holder of the private key, and the signed content was not altered. Because the signature travels inside the message, DKIM survives forwarding where SPF does not. What it does not do alone is decide what happens when a message is unsigned or fails. That needs a policy.
DMARC: instructions and reporting
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the note Alice hands Bob in advance. It tells receivers what to do when SPF or DKIM fails, and it sends reports back to the domain owner.
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
p=is the policy on failure:none(monitor),quarantine(send to spam), orreject(refuse).rua=is where aggregate reports go.
DMARC’s quietly crucial job is alignment: the domain that passes SPF or DKIM must match the domain shown in the visible “From” address. This closes the hole SPF alone leaves open, where an attacker passes SPF for their own infrastructure while still displaying your domain to the reader.
A safe rollout is to start at p=none, watch the reports until you are sure your real mail aligns and passes, then tighten to quarantine and finally reject.
Why all three
Each protocol covers a gap the others leave:
- SPF confirms an authorized server but ignores content and breaks on forwarding.
- DKIM confirms integrity and survives forwarding but does not dictate failure handling.
- DMARC ties the first two to the visible sender, decides the outcome, and reports back.
Deploy only SPF and an attacker can still forge a convincing message showing your domain in the “From” line. Used together, the three form a layered system far stronger than any one alone. As the next chapter shows, having them configured is also one of the inputs to your domain’s reputation.