Email Authentication Results in Headers & Spoofing Detection

What the Authentication-Results Header Actually Is

When a message arrives, the receiving mail server independently checks it against the sending domain's published SPF, DKIM, and DMARC policies, then records the outcome of all three checks in a single header it adds before delivering the message to your inbox. That header, Authentication-Results, saves you from having to re-run any of those checks yourself — the verification already happened server-side, and the result is sitting right there in the headers if you know how to read it.

Not every message will have this header, and its exact wording varies slightly between providers (Gmail, Outlook, and smaller mail servers all format it a bit differently), but the core structure — spf=result, dkim=result, dmarc=result — is consistent enough across virtually all major providers that once you recognize the pattern once, you can read it anywhere.

Parsing the Header's Structure Piece by Piece

A typical Authentication-Results header looks something like: mx.google.com; spf=pass smtp.mailfrom=bounce@sender.com; dkim=pass header.i=@sender.com; dmarc=pass header.from=sender.com. The first token, before the semicolon, identifies which server performed the check. Each subsequent segment gives a check name (spf, dkim, dmarc) followed by its result, and often additional detail after that — which specific address SPF validated against (smtp.mailfrom), which domain signed the DKIM signature (header.i), and which domain DMARC actually evaluated (header.from).

Multiple Authentication-Results headers can appear if a message passed through more than one server that performs these checks — a corporate gateway and the final destination mailbox provider, for instance. When that happens, treat the header closest to actual delivery (the one added last, typically appearing first when read from the top) as the most relevant, since it reflects the check performed nearest to where you actually received the message.

Reading SPF Results

SPF checks whether the server that actually sent the message was authorized by the domain in the smtp.mailfrom address (the Return-Path, not necessarily the visible From address). A result of pass means the sending IP matched an authorized entry in that domain's SPF record. fail or softfail means it didn't — the server that sent the message wasn't on the domain's approved list, which is either a configuration problem for a legitimate sender or a genuine sign that someone is sending mail claiming to be from a domain they don't control. neutral or none means the domain either has no SPF record or explicitly declined to make a strong claim either way.

SPF alone checks the Return-Path domain, not the visible From address you actually see in your inbox — an important gap that DMARC alignment (covered separately in our dedicated DMARC alignment guide) exists specifically to close, since SPF passing for the Return-Path domain says nothing about whether that domain matches what the message claims to be from.

Reading DKIM Results

DKIM checks a cryptographic signature attached to the message, verifying both that the content wasn't altered in transit and that whoever signed it controls the private key for the domain named in the signature (header.i or header.d). A pass confirms the signature is valid and the domain genuinely signed this exact message. A fail means either the message was modified after signing (sometimes an innocent side effect of a mailing list or forwarding service rewriting parts of the message) or the signature simply doesn't match, which is a stronger signal than an SPF failure since forging a valid DKIM signature requires the attacker to actually possess the domain's private signing key.

Pay attention to which domain actually appears in the DKIM result, not just whether it says pass. A message can show a valid DKIM pass for a completely unrelated domain — a bulk-mail platform's own signing domain, for example — while the visible From address claims to be someone else entirely. A technically valid DKIM pass for the wrong domain is not the same thing as proof the visible sender is legitimate.

Reading DMARC Results

DMARC ties SPF and DKIM together by checking whether at least one of them not only passed, but passed for a domain that actually aligns with the visible From address — the alignment check our dedicated DMARC alignment guide walks through in detail. A DMARC pass is the strongest single signal in this header: it means the visible sender domain itself was genuinely verified, not just some unrelated domain buried in the Return-Path or DKIM signature. A DMARC fail means neither SPF nor DKIM aligned with the visible From domain, which is exactly the pattern a spoofed sender produces.

The DMARC result also often includes the domain's actual policy in parentheses (p=reject, p=quarantine, or p=none), which tells you what the domain owner asked receiving servers to do with messages that fail — and, just as importantly, what actually happened to this specific message. A message that failed DMARC but still landed in your inbox despite the domain requesting rejection is worth extra scrutiny, since it suggests either an unusually permissive receiving server or a domain still in a monitor-only rollout phase.

The Specific Pattern That Indicates Spoofing

No single failed check proves spoofing on its own — legitimate mail breaks one authentication method reasonably often. What deserves real attention is a specific combination: a DMARC failure, paired with a visible mismatch between the From address and the Return-Path domain, especially when the claimed From domain is a well-known brand and the actual sending infrastructure has no obvious connection to it. That combination is precisely what an attacker produces when spoofing a trusted sender, and it's genuinely uncommon for a legitimate configuration issue to produce the exact same pattern.

A second strong pattern: a Reply-To address on a completely different domain than the visible From address, combined with any authentication failure. Legitimate senders occasionally use a different Reply-To for support routing, but that's usually a same-organization variation, not a jump to an unrelated domain — and paired with a failed DMARC check, it's a specific, low-effort technique that shows up disproportionately often in phishing attempts.

SPF, DKIM, and DMARC Results Compared

Real Scenarios for Reading Authentication Results

A finance team receives an invoice from what looks like a known vendor. The Authentication-Results header shows DMARC pass with the From domain correctly aligned — a strong signal the domain itself is genuine, though it's still worth confirming the invoice details separately, since a compromised legitimate account can pass every authentication check while still sending fraudulent content.

An IT security analyst triages a phishing report and finds DMARC fail alongside a Return-Path pointing to an unrelated freemail domain, despite the message claiming to be from the company's own CEO. That specific combination is close to conclusive on its own and justifies immediate escalation without needing to analyze the message body at all.

A marketing team's own campaign emails show SPF fail after switching to a new bulk-sending platform. Reading the header reveals the new platform's sending IP simply isn't yet added to the domain's SPF record — a configuration gap to fix, not evidence of anything malicious, and a good example of why a single failed check shouldn't trigger alarm on its own.

A recipient forwards a suspicious message to a colleague for a second opinion, and the forwarded copy shows a fresh DKIM failure that wasn't present in the original. This is a common, mostly harmless side effect of forwarding altering the message slightly after the original signature was applied — worth knowing so it doesn't get misread as new evidence of anything.

A Side-by-Side Look at a Clean Result and a Spoofed One

A genuine, well-configured message from a real vendor typically shows something like: spf=pass smtp.mailfrom=bounce@vendor.com; dkim=pass header.i=@vendor.com; dmarc=pass (p=reject) header.from=vendor.com — all three checks pass, and critically, the domains referenced throughout (mailfrom, DKIM signer, and the visible From) all point to the same organization. Nothing here requires guesswork; every domain mentioned is consistent with every other one.

A spoofed message impersonating that same vendor often shows something closer to: spf=softfail smtp.mailfrom=noreply@unrelated-freehost.net; dkim=none; dmarc=fail (p=reject) header.from=vendor.com — the visible From claims to be the vendor, but the actual Return-Path domain has no relationship to it, there's no valid DKIM signature at all, and DMARC explicitly fails despite the domain's own policy requesting outright rejection. The header itself is telling you, in plain terms, that this message failed the exact check designed to catch it.

Why Multiple Authentication-Results Headers Can Disagree

It's not unusual to see two different Authentication-Results headers on the same message showing different outcomes — one from a corporate security gateway the message passed through first, another from the final destination mailbox provider. This happens because each server performs its own independent check at the moment it receives the message, and network conditions, DNS caching, or even brief SPF record changes between those two points in time can genuinely produce different results a few seconds apart.

When you see this, prioritize the header added closest to actual delivery — typically the one appearing first when reading top to bottom, since headers are prepended with each new hop. It reflects the check performed nearest to where the message actually landed, which is generally the most relevant result for judging what you're looking at right now.

A Quick Checklist for Reading the Header Yourself

• Identify which server added the header — the first token before the semicolon — and prefer the one closest to actual delivery if there's more than one.
• Read all three results together — spf, dkim, and dmarc — rather than stopping at the first one you see.
• Check which domain each result actually references, not just whether it says pass, since a pass for the wrong domain proves little.
• Treat DMARC as the tie-breaker — it's the only one of the three that verifies the domain you actually see in your inbox.
• Look for the specific combination — DMARC failure plus a From/Return-Path mismatch — rather than reacting to any single failed check alone.

When Authentication Results Alone Aren't Enough

A message can pass SPF, DKIM, and DMARC perfectly while still being entirely fraudulent, because authentication only proves the message came from the domain it claims — not that the domain deserves your trust. An attacker who registers a convincing look-alike domain and properly configures SPF, DKIM, and DMARC for it will pass every check shown in this header while still being a scam, since the checks validate the header's claimed domain, not whether that domain has any legitimate relationship to the brand it's imitating. Pair authentication results with checking the actual originating server and delivery path — covered in our companion guide on reading email headers and tracing the source — and with basic scrutiny of whether the domain itself makes sense, rather than treating a clean Authentication-Results header as a final verdict.

FAQ