How to read the Authentication-Results header

The Authentication-Results header is the receiving mail server’s verdict on your message, written in one compact line. It records whether SPF, DKIM and DMARC passed, which domains they checked, and — through ARC and compauth — how the message was handled across hops. Once you can read spf=, dkim=, dmarc= and the domains beside them, most ‘why did this go to spam?’ questions answer themselves.

Written & reviewed by the VerifyAnyEmail team · Last reviewed July 2026

When you want to know why a message landed in spam or got rejected, the Authentication-Results header is where the receiver shows its work. It is added by the receiving server (never the sender), so it reflects what the inbox provider actually decided — not what your ESP hoped. This guide decodes each field, shows you how to view the raw header in Gmail and Outlook, and walks through a full worked example so you can diagnose failures at a glance.

First, get the raw header

The header is stripped from the normal reading view, so you have to open the raw source:

  • Gmail: open the message, click the three-dot overflow menu (top right of the message), and choose Show original. Gmail shows a summary table with SPF/DKIM/DMARC results at the top and the full raw source below.
  • Outlook / Microsoft 365 (desktop): double-click the message to open it in its own window, then File → Properties, and read the Internet headers box.
  • Outlook.com (web): open the message, click the overflow menu, choose View → View message source.
  • Apple Mail: select the message, then View → Message → Raw Source (or press ⌥⌘U).

Copy the whole thing and paste it into the Email Header Analyzer to have every field parsed and the delivery hops laid out. The rest of this guide explains what those fields mean.

A full worked example

Here is a healthy header where everything aligns and passes. We’ll take it apart field by field:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@acme.com header.s=esp1 header.b=Xk9pQ2v;
  spf=pass (google.com: domain of bounce@acme.com designates
    198.51.100.24 as permitted sender) smtp.mailfrom=bounce@acme.com;
  dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=acme.com;
  arc=pass (i=1 spf=pass dkim=pass dmarc=pass);
  compauth=pass reason=100

The very first token — mx.google.com — is the authserv-id, the identity of the server that performed the checks. Trust results only from a server you recognise as your own receiver; a header claiming results from some other host tells you nothing. Everything after it is a semicolon-separated list of method results.

Decoding each method

spf=

The SPF result for the envelope sender shown in smtp.mailfrom. Possible values you’ll see: pass, fail (hardfail, -all), softfail (~all), neutral, none (no SPF record), permerror (broken record — often too many DNS lookups), and temperror (a transient DNS failure). In the example, spf=pass for smtp.mailfrom=bounce@acme.com. Remember: SPF here is about the envelope domain, not the visible From — which is why SPF can pass while DMARC fails.

dkim=

The result of verifying each DKIM signature. Watch the domains that ride along with it:

  • header.i= — the signing identity (the i=/d= domain). This is what DMARC checks for alignment.
  • header.s= — the selector used to fetch the public key.
  • header.b= — the first bytes of the signature value, a handle to identify which signature this line refers to (a message can carry several).

Here dkim=pass header.i=@acme.com — a valid signature signed by your own domain. If it read header.i=@some-esp.net, the signature could still be pass yet fail to align — see why DKIM passes but DMARC fails.

dmarc=

The overall DMARC verdict, evaluated against header.from — the visible From domain. This is the field that actually decides policy. Alongside it you’ll see the policy that applied: p= (domain policy), sp= (subdomain policy), and dis= (the disposition the receiver applied — NONE, QUARANTINE, or REJECT). Note that dmarc=pass means at least one of SPF or DKIM both passed and aligned with header.from=acme.com. In the example the policy is p=REJECT but dis=NONE because the message passed — the strict policy simply never had to bite.

arc=

ARC (Authenticated Received Chain, RFC 8617) preserves the original authentication results when a message is forwarded through an intermediary — a mailing list, a forwarding rule — that would otherwise break SPF and DKIM. arc=pass tells the final receiver “an earlier trusted hop already saw this pass authentication,” which lets it give the benefit of the doubt to legitimately forwarded mail that would fail a fresh SPF/DKIM check. You mostly see ARC on mail that has been relayed.

compauth=

A Microsoft-specific composite authentication result — it does not come from an RFC. Microsoft rolls SPF, DKIM, DMARC and its own heuristics into one compauth verdict (pass, fail, softpass, none) with a numeric reason= code explaining the decision. It appears on mail delivered into Microsoft 365 / Outlook.com and is Microsoft’s final say on whether the sender is authenticated.

Reading a failure

Now a header from a message that got quarantined. The skill is spotting which check broke and whether alignment is the real culprit:

Authentication-Results: mx.google.com;
  dkim=fail header.i=@acme.com (bad signature);
  spf=softfail smtp.mailfrom=news@marketing.acme.com;
  dmarc=fail (p=QUARANTINE dis=QUARANTINE) header.from=acme.com

Read it top to bottom: dkim=fail (bad signature) — the body or a signed header was altered in transit (or the key rotated without republishing). spf=softfail — the sending IP isn’t clearly authorised for marketing.acme.com. With DKIM failing and SPF only soft-failing, no aligned identifier passes, so dmarc=fail and the receiver applied dis=QUARANTINE per the p=QUARANTINE policy. The fix here is two separate jobs — repair the DKIM signature and tighten the SPF record — not one.

The header is standardised — use it with confidence

The format is defined by RFC 8601, so the same field names appear whether the receiver is Google, Microsoft, or a self-hosted server. That consistency is what makes this header the fastest first stop in any deliverability investigation. Paste any real message into the Email Header Analyzer to parse it automatically, then drill into the specific record with the SPF Checker, DKIM Checker, or DMARC Checker.

Where to go next

If the header shows a pass on SPF or DKIM but a DMARC fail, the cause is almost always alignment — start with why SPF passes but DMARC fails or why DKIM passes but DMARC fails. For the full picture of the three records, read the complete SPF, DKIM & DMARC guide, and when your headers are consistently clean, move to enforcement with how to move DMARC to p=reject safely. Google’s reference on viewing original messages and Microsoft’s message-headers documentation cover the provider-specific fields in more depth.

Check your domain in seconds

Run the free diagnostics referenced in this guide — no sign-up needed.

Email Health CheckAll tools

More guides

🧹 How to Clean an Email List Before a Campaign (2026 guide)
A step-by-step workflow to dedupe, validate and verify a list before you hit send — and keep bounces low.
🔬 How Email Verification Works (Without Sending an Email)
Syntax → MX → live SMTP probe → catch-all/role/disposable checks: the real pipeline, explained.
🚦 Deliverable, Risky, Catch-All & Unknown: How to Handle Every Verification Result
What each verification status means and the safe action to take — from sign-up forms to bulk sends.
🎯 Should You Send to Catch-All Emails? (2026)
Catch-all domains accept everything, so SMTP can’t confirm the mailbox. A practical decision framework.