Email Authentication: SPF, DKIM, DMARC

Email was designed with no way to verify the sender, so anyone can put ceo@meridian.example in the From field — the technical root of spoofing and much phishing. Three stacked standards fix this: SPF says which servers may send for a domain, DKIM cryptographically signs messages, and DMARC ties them together, tells receivers what to do with failures, and reports back.

This topic makes the trio concrete: how to configure them for meridian.example so attackers cannot spoof the company's own domain — and why the rollout order matters as much as the records themselves.

Why Email Spoofing Works

SMTP never authenticated the sender, so the visible From address is free text — anyone can claim to be anyone. SPF, DKIM, and DMARC are the retrofit that lets a receiving server decide whether a message really came from who it claims. Without them, an attacker spoofing your own domain to your own employees is trivial, which is exactly the setup for a convincing internal phish.

SPF — Authorized Senders

SPF is a DNS record listing the IPs and hosts allowed to send for the domain; the receiver checks the sending server against it. Its limits matter: SPF breaks on forwarding (the forwarder's server is not on your list), and it checks only the envelope sender, not the visible From address — so SPF alone does not stop From-address spoofing.

DKIM — Cryptographic Signing

DKIM has the sending server sign the message with a private key; the receiver verifies with the public key published in DNS, proving the message is unaltered and authorized. Because the signature travels with the message, DKIM survives forwarding where SPF does not — it is the cryptographic half of the trio, and it applies the signing from Chapter 2 to email.

DMARC — Alignment, Policy, and Reporting

DMARC sits on top and does three things: it requires that SPF or DKIM align with the visible From domain (closing the gap SPF alone leaves), it tells receivers what to do on failure (none, quarantine, or reject), and it sends aggregate reports. Moving the policy to p=reject is what actually stops spoofing of your domain — but you get there safely by starting at p=none with reporting, fixing every legitimate sender the reports reveal, then enforcing.

# SPF: which servers may send for meridian.example (TXT record)
meridian.example.  TXT  "v=spf1 include:_spf.google.com include:mail.provider.example -all"

# DKIM: the public key receivers use to verify signatures (TXT record)
selector1._domainkey.meridian.example.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0..."

# DMARC: start at p=none with reporting, then quarantine, then reject
_dmarc.meridian.example.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@meridian.example"
#   -> after fixing legitimate senders the reports reveal:  p=reject

SPF authorizes the sending servers, DKIM publishes the verification key, and DMARC begins at p=none with a reporting address so you can watch. The reports reveal every legitimate sender — marketing platforms, the ticketing system, CI — that you must authorize before tightening. Only once those are covered do you move to quarantine and then reject, the setting that finally makes your domain un-spoofable.