SPF, DKIM and DMARC: Why Two of Them Do Nothing Without the Third

The short answer

SPF and DKIM each authenticate something the recipient never sees. DMARC is the record that ties them to the address the recipient *does* see — the From: line in their inbox.

That is the whole point, and it is the part most setup guides skip. A domain can publish a flawless SPF record and sign every message with DKIM, and a stranger can still send mail that displays as billing@yourdomain.com, because neither SPF nor DKIM looks at the From: header at all.

If you publish only one of the three, publish DMARC last and publish it deliberately. If you publish only two, you have built a lock with no door in it.

What each record actually checks

SPF (RFC 7208) is a TXT record listing the servers allowed to send for your domain. The receiving server compares the sending IP against that list.

The catch: SPF checks the envelope sender — the Return-Path, the address used in the SMTP conversation. That address is invisible in a normal mail client. A spoofer can set the envelope sender to a domain they control, pass SPF against *that* domain, and put whatever they like in the visible From:.

DKIM (RFC 6376) is a cryptographic signature. Your sending platform signs each message with a private key and adds a DKIM-Signature header; you publish the matching public key in DNS at selector._domainkey.yourdomain.com.

The catch: the signature covers a domain named in the signature's own d= tag. Again, nothing forces that to match the visible From:.

DMARC (RFC 7489) is the record that adds the missing rule, called alignment. It says: the domain in the visible From: must match the domain that passed SPF, or the domain that signed with DKIM. Pass one of those *in alignment* and the message is DMARC-authenticated. Pass neither and the receiver applies your published policy.

The three records, written out

SPF — one record, at the apex, and never more than one. Two SPF records on a domain is a permanent error, not a merge:

v=spf1 include:_spf.google.com include:sendgrid.net -all

-all is a hard fail. ~all is a soft fail, which most receivers treat as "note it and deliver anyway". Start on ~all if you are unsure what sends for you; move to -all once your reports are clean.

SPF has a hard limit of 10 DNS lookups per evaluation. Every include: costs one, and each of those can chain further. Exceed ten and the result is permerror, which most receivers score as a failure — so a record that grew one vendor at a time can break without anyone touching it.

DKIM — your provider generates the key pair and gives you the public half to publish:

selector1._domainkey TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Use 2048-bit keys where the provider offers a choice. Rotate the selector rather than the record when you change providers, so old signed mail still verifies.

DMARC — one TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r

p= is the policy the receiver applies when alignment fails: none, quarantine or reject. rua= is where aggregate reports are sent.

Start at p=none and mean it

p=none asks receivers to change nothing and send you reports. It is not a weak setting — it is the measurement phase, and skipping it is how organisations discover their invoicing system was never DKIM-signed by watching invoices stop arriving.

The sequence that works:

• Publish p=none with a rua= address and leave it for two to four weeks.
• Read the aggregate reports. They are XML; a report parser makes them legible.
• For every source that fails alignment, decide: is it us, and does it need fixing, or is it not us?
• Move to p=quarantine, then to p=reject, only once the legitimate senders all pass.

Aggregate reports arrive from the receivers, so you find out about your own forgotten sending systems — the CRM, the ticketing tool, the ten-year-old server that mails a nightly report — before you break them.

Forwarding is the reason DKIM matters more than SPF

When a message is forwarded, the forwarding server becomes the sender. Its IP is not in your SPF record, so SPF breaks on almost every forward. DKIM survives, because the signature travels with the message as long as the body and signed headers are unmodified.

This is why a DMARC setup resting on SPF alone starts rejecting legitimate mail the moment a recipient forwards to another address, and why mailing lists were the loudest casualty of early p=reject rollouts. Sign with DKIM, align on DKIM, and forwarding stops being a problem.

The 2024 rule change that made this compulsory

Until recently, email authentication was strongly advisable. Then the two largest consumer mailbox providers made it a condition of delivery.

From February 2024, Google and Yahoo required bulk senders — those sending roughly 5,000 or more messages a day to their users — to publish SPF, DKIM and DMARC, to offer one-click unsubscribe on marketing mail, and to keep reported spam complaints below a stated threshold. Microsoft moved in the same direction for Outlook.com the following year.

The practical effect for a small sender is simple: you are not the target of those rules, but you share the infrastructure of everyone who is. Filters tuned to expect all three records treat a domain missing them as less trustworthy than it was in 2023.

Check the current text of each provider's sender guidelines before you rely on a threshold. Those pages change, and this one is dated 23 August 2026.

Where your records live

All three are DNS records, so they live wherever your nameservers point — which is not necessarily your registrar. If you moved DNS to a host or a CDN, that is where these go. See what DNS actually is and how it works if that distinction is not yet solid.

If your mail is on a provider tied to your domain registration, the records are usually pre-filled. Spaceship's email product publishes SPF and DKIM into the zone for you when the domain and mailbox sit in the same account, which removes the most common failure — a DKIM key generated and never published.

For the full picture of getting mail working on a domain you own, including provider choice, see business email on your own domain.

What none of this does

Authentication is not reputation. A perfectly aligned domain that sends unwanted mail still lands in spam, because the filters that matter score complaint rates, engagement and list hygiene as well as authentication.

DMARC also does nothing about lookalike domains. It protects the exact domain that publishes it. A message from yourdornain.com — with an *rn* where the *m* should be — passes its own DMARC perfectly, because it is a different domain that its owner controls. Registering the obvious confusables is a separate defence, and protecting a domain from hijacking covers the rest of that ground.

The honest summary

Three records. SPF lists your servers, DKIM signs your messages, DMARC forces both to agree with what the reader sees and tells you when they do not.

Publish all three. Start at p=none, read the reports for a month, then tighten. The setup takes an afternoon; the reporting phase is what makes it safe, and it is the step people skip.