SPF, DKIM and DMARC in plain English

By MercPrivacy · Published 2026-06-14 · Updated 2026-08-05

Email lets senders write their own name tag. SPF, DKIM and DMARC are the three checks that call the bluff — what each verifies, what pass and fail mean, and why a failed verdict is evidence.

Email has a design flaw old enough to collect a pension: the sender writes their own name tag. The protocol that moves mail between servers does not verify that a message claiming to come from your bank involved your bank in any way. Three retrofitted checks — SPF, DKIM and DMARC — exist to patch that flaw, and between them they decide what reaches inboxes, what rots in spam folders, and what a forged email looks like on paper.

You will never need to administer these systems. But if unwanted email is a problem you intend to do something about, you need to read their verdicts, because the verdict line is where a spammer's central lie — I am someone you trust — gets recorded in writing by a neutral machine.

Plain English, one at a time.

## SPF: the approved-sender list

SPF answers one question: did this message arrive from a server the sending domain has publicly authorized? Every domain can publish a list of the servers allowed to send its mail. When a message arrives, the receiving system looks up that list and checks whether the delivering server is on it.

- **Pass** — the server that handed over the message is on the domain's published list. - **Fail** — it is not. Either the domain's operator misconfigured something, or the message did not come from where it claims.

SPF has a blind spot worth knowing: it checks the behind-the-scenes envelope domain — the address bounces return to — not necessarily the From line displayed to you. A clever sender can pass SPF on a domain they own while showing you a different name entirely. That gap is why DMARC exists.

## DKIM: the wax seal

DKIM is a cryptographic signature. The sending system signs parts of the message — typically the body and key headers — with a private key, and publishes the matching public key where any receiver can fetch it. If the signature verifies, two things are true at once: the message really was signed by the domain named in the signature, and the signed parts were not altered in transit.

- **Pass** — the seal is intact. The signing domain vouches for this exact content. - **Fail** — the signature is broken or missing. The content changed en route, or the signature was never genuine.

Same blind spot, though: a spammer can validly DKIM-sign mail using their own throwaway domain. The seal is real; the name displayed to you is still a costume. Verification without alignment proves the wrong thing.

## DMARC: the rule that ties it together

DMARC is the piece that finally involves the From line you actually see. It requires that SPF or DKIM not merely pass, but pass for a domain that matches the visible From address — the industry calls this alignment. It also lets the domain owner publish standing instructions for what receivers should do when the check fails: deliver anyway, quarantine to spam, or reject outright.

That is why a message can technically pass SPF and DKIM and still fail DMARC. The checks passed for some domain — just not the one being shown to you. Failed alignment is the signature move of impersonation.

> Authentication does not tell you an email is honest. It tells you whose lie it would be.

## Where to see the verdicts

The receiving system writes its conclusions into a header line called Authentication-Results, in compact notation — spf=pass, dkim=fail, dmarc=fail — along with the domains each verdict applies to. Gmail goes further and prints a plain-language summary at the top of its Show original view. The click-by-click path to the raw headers in Gmail, Outlook and Apple Mail is in [our header guide](https://mercprivacy.com/knowledge/how-to-find-email-headers).

Reading the line takes ten seconds once you know the vocabulary:

1. **All three pass, aligned with the visible domain** — the sender is who they claim to be. The mail may still be unwanted, but it is honestly labeled, and its [unsubscribe link can be trusted](https://mercprivacy.com/knowledge/when-unsubscribe-is-safe) to do its legal job. 2. **DMARC fails on a message dressed as a brand you know** — impersonation, recorded in writing. Do not touch its links. 3. **No authentication at all** — increasingly rare from real senders, routine from junk infrastructure. Treat accordingly.

## Why a failed verdict is worth keeping

Here is the part that surprises people: fail is not just a reason to delete. It is evidence.

Federal law requires commercial email to use truthful headers, but ordinary recipients [cannot sue under the federal statute](https://mercprivacy.com/knowledge/why-you-cannot-sue-over-spam-email). What survives for individuals are state laws aimed at falsity — and falsified headers are exactly what those laws mean. California's, the strongest of them, attaches liquidated damages of $1,000 per email with falsified headers or a misleading subject line, capped at $1,000,000 per incident. An Authentication-Results line showing failure, preserved inside the original message file, is that falsity recorded at the moment of delivery by infrastructure with no stake in your dispute.

Delete the message and the record is gone. Preserve the original file and every forged mail becomes a page in a documented pattern. That is the entire difference between complaining and having something worth evaluating.

## What we do with verdict lines

Reading authentication results across a stack of preserved spam is routine work here — often the first thing we check. [Stephanie](https://mercprivacy.com/stephanie) answers instantly and free if you want to know whether the junk you are getting fails authentication and what that opens up, and [how it works](https://mercprivacy.com/how-it-works) covers the rest. We are not a law firm; when a matter requires legal representation, a licensed attorney is engaged.