Did It Actually Come From Them?

SPF. DKIM. DMARC. Three acronyms you’ve probably seen and ignored. Here’s the secret: you don’t need to understand how they work under the hood. You need to know what each result means. This lesson teaches the reading, not the engineering.

One Question, Three Answers

All three systems are trying to answer the same question — “Did this message actually come from who it claims?” — but each one answers it a different way.

• SPF answers: Is this sending server allowed to send mail for this domain? The domain’s owner publishes a list of approved senders. The receiving server checks whether the message came from one of them.
• DKIM answers: Does this message have a valid cryptographic signature from this domain? The sending infrastructure signs the message. The receiving server verifies the signature is intact and really belongs to the claimed domain.
• DMARC answers: Does the domain’s published policy accept a message with these SPF/DKIM results? The domain’s owner publishes rules (“reject if both fail,” “quarantine if one fails,” etc.). DMARC is the combined verdict.

Three different ways of checking the same claim. More signals, more chances to catch a lie.

The Pass / Fail / Missing Table

When you read an Authentication-Results line, each check lands in one of three buckets. Here’s what each one means in plain English.

	Pass	Fail	Missing
SPF	Authorized sending server.	Not authorized. Very suspicious.	No SPF record — the domain hasn’t set it up.
DKIM	Content intact, legit signature.	Signature broken or invalid.	Message wasn’t signed.
DMARC	Policy accepts this result.	Policy rejects this.	No policy published.

“Missing” is the awkward one. It doesn’t automatically mean the message is bad — plenty of small senders, old systems, and personal accounts never set this up. But missing means you have less information, and less information means you have to lean harder on the other signals (like the From/Return-Path domain mismatch from Lesson 3.2).

The Reading Rule

Here is the shortcut that makes this whole topic tractable: look at DMARC first. DMARC is the combined verdict — it already takes SPF and DKIM into account under the hood, and it applies the domain owner’s own policy to the result.

• DMARC pass → the other two are fine. DMARC requires at least one of SPF or DKIM to pass and align with the From domain, so a DMARC pass is already a quality-controlled result.
• DMARC fail → the domain’s owner explicitly said “don’t trust messages like this from my domain.” That’s a signed confession from the legitimate owner that this message is probably fake.
• DMARC missing → the domain hasn’t told receivers what to do. Fall back to reading SPF and DKIM individually.

One line, one reading habit. Everything else is supporting evidence.

Common Patterns

Here are the three patterns you’ll actually encounter in the wild:

• Everything passes (green across the board). The message came from who it claims. It came from a server authorized to send for that domain, it carries an intact signature, and the domain owner’s policy accepts it. This is good evidence — but not proof that the message is safe. A compromised legitimate account will also produce this pattern. More on that in Lesson 3.4.
• DMARC fails, SPF and DKIM fail. A spoof, with near-certainty. The sender claims a domain they can’t prove any connection to, and the real domain owner’s policy is telling you to reject it. If you see this pattern, you’ve caught a fake.
• Everything missing. Unusual, but not automatically malicious. You’ll see this on mail from old personal accounts, obscure services, or hosting setups where the admin never configured authentication. Treat it as “I have no data” rather than “this is clean” or “this is fake” — and lean on other signals.

What We’re NOT Covering

We’re being honest here: this lesson deliberately skips a lot. We are not teaching how SPF records are configured in DNS. We are not teaching what a DKIM selector is or how the cryptographic signing works. We are not teaching how to publish a DMARC policy or how to read DMARC aggregate reports. Those are all important topics — for the person who administers a domain’s mail infrastructure.

You are not that person. You are a reader. You are looking at a receipt that somebody else’s infrastructure already wrote. Your job is to know what it says, not how the printer works.

Key Takeaways

1. SPF, DKIM, and DMARC all answer versions of the same question — “Did this actually come from who it claims?” — from three different angles.
2. For reading headers, you only need to interpret three outcomes per check: pass, fail, and missing. The table above is the full cheat sheet.
3. Read DMARC first. It’s the combined verdict and already incorporates SPF and DKIM alignment under the hood.
4. Authentication is admin-tier work to set up, but reader-tier work to interpret — you read the receipt, you don’t build the printer.