SPF, DKIM, DMARC: who does what, and why you need all three

The question comes up in every first meeting: "we already have SPF, isn't that enough?" No — and not because SPF is badly done. Because the three mechanisms answer three different questions, only one of which the recipient of your mail actually cares about.

What each one checks

The important part is the third row. DMARC validates nothing. It consumes the results of SPF and DKIM, and adds the one check that matters from a user's point of view: is the domain shown in the From: field the one that was actually authenticated?

Why SPF alone leaves the door open

An email carries two sender addresses, and everything hinges on that.

The envelope (MAIL FROM) is used for transport. That is what SPF checks. It never appears in the mail client.

The header (From:) is what your correspondent sees. That is what an attacker wants to forge, and SPF never looks at it.

Nothing therefore stops a message from getting a perfectly valid SPF result on an attacker's domain while displaying accounting@your-company.com in the visible field. The recipient sees successful authentication and your name. That is exactly what DMARC fixes, by requiring the two domains to align.

Why DKIM is the sturdiest of the three

DKIM cryptographically signs part of the message with a private key, the public key being published in your DNS. The recipient verifies the signature.

Three properties make it the most robust mechanism in practice:

• It survives forwarding. A forwarded message keeps its signature; SPF fails mechanically, since the relaying server is not in your record.
• It consumes no DNS lookup against the SPF limit, which matters once you have fifteen providers.
• It does not depend on the provider's IP addresses, which change without anyone warning you.

Its weakness lies elsewhere: a signature says nothing about the sender's legitimacy. Anyone can sign their own messages. Again it is DMARC that settles the matter, by requiring the signing domain to align with the displayed one.

What DMARC really adds

Three things, in order of importance:

1. Alignment. The check described above, and the only one that protects the reader.
2. An instruction. none, quarantine or reject: what the recipient should do on failure. Without it, every operator decides on its own.
3. Reports. Every day, the major operators send you a summary of what they saw in your name. It is the only exhaustive source of information you will ever get on your own mail flows.

That third point is underrated. DMARC aggregate reports routinely surface legitimate senders nobody remembered existed — an old print server, a monitoring script, a platform abandoned by a team that left years ago.

What about BIMI, MTA-STS, all the rest?

They come after, never before.

BIMI shows your logo in the inbox; it requires p=quarantine or p=reject first. It is a reward, not a protection.

MTA-STS and DANE protect transport against interception, not identity against forgery. Real subject, different problem.

ARC preserves authentication results across legitimate relays; useful when you depend on mailing lists, but only once DMARC is in place.

Where to start, concretely

1. Publish a DMARC record at p=none with a reporting address, on every domain — including the ones that never send anything.
2. Read the reports for four to six weeks to build the real inventory of your senders.
3. Enable DKIM at every legitimate provider, using your own domain.
4. Only touch SPF at the end, and keep it short.
5. Move to p=reject in stages.