The Authentication-Results header: how to read SPF, DKIM and DMARC pass/fail

Authentication-Results is a header added by the receiving mail server, summarising the outcome of every authentication check it ran on the message - SPF, DKIM, DMARC, and sometimes others like ARC. Because it is written by the receiver, not the sender, it is the most reliable record of how a message actually authenticated at that specific provider, as opposed to how a DNS-record checker predicts it should.

Basic syntax

Authentication-Results: <receiving-server-identity>;
  <method>=<result> (<comment>) <key>=<value>;
  <method>=<result> ...

Each method (spf, dkim, dmarc, arc) reports its own result independently, and DMARC's result depends on the other two having passed *and* being aligned to the right domain - it is not simply "all three passed or failed together."

A passing example, annotated

Authentication-Results: mx-fe1.outlook.com;
       dkim=pass (signature was verified) header.d=notify.example.com
         header.s=o1 header.b=Rb3f...;
       spf=pass (sender IP is 198.51.100.44) smtp.mailfrom=mailer@notify.example.com;
       dmarc=pass action=none header.from=example.com

• dkim=pass header.d=notify.example.com header.s=o1: the DKIM signature validated against a subdomain (notify.example.com) commonly used by ESPs for subdomain-isolated sending, using selector o1. A message relayed through more than one signing platform will carry one dkim= block per signature.
• spf=pass ... smtp.mailfrom=mailer@notify.example.com: the envelope-from domain, which is the subdomain here, was authorised to send from the connecting IP - note this is the envelope domain, not necessarily the visible From: domain.
• dmarc=pass action=none header.from=example.com: DMARC passed because the DKIM d= domain (notify.example.com) is a subdomain of the organisational domain in the visible From header (example.com), which satisfies *relaxed* alignment - the default and more common alignment mode. Strict alignment would require an exact match instead.

A failing example, annotated

Authentication-Results: mx.google.com;
       dkim=fail (body hash did not verify) header.i=@example.com header.s=aug2026;
       spf=softfail (google.com: domain of transitioning
         campaign@example.com does not strongly designate 198.51.100.9 as
         permitted sender) smtp.mailfrom=campaign@example.com;
       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=example.com

Here DKIM failed because the message body was modified in transit after signing (common when a mailing-list server or security gateway rewrites content), SPF returned a softfail (the SPF record uses ~all, meaning "probably not authorised but don't hard-reject"), and because neither check passed with alignment, DMARC fails. The dis=QUARANTINE tells you what the receiver actually did with the message as a result - sent it to spam, in this case, rather than rejecting outright.

Why the comment text matters as much as the pass/fail word

The parenthetical comment after each result is not boilerplate - it is the specific reason. "Body hash did not verify" (DKIM) points at in-transit modification, not a DNS misconfiguration. "Domain ... does not strongly designate" (SPF softfail) points at a ~all policy rather than a hard SPF failure. Reading only the pass/fail/softfail word and skipping the comment is the most common way people misdiagnose which part of their setup actually needs fixing.

A field reference

What not to do

Do not read only the pass/fail keyword and skip the comment - it is where the actual cause lives. Do not confuse smtp.mailfrom (SPF's domain) with header.from (DMARC's domain) - they are frequently different domains by design (bounce-handling subdomains), and that is not itself a failure. And do not assume a DNS-record validator's "everything looks correct" means the same as a receiving server's actual Authentication-Results - only a real delivered message's header tells you what actually happened at that provider.

This distinction matters most right after a configuration change: a DNS validator confirms the record is syntactically correct and resolvable, but it cannot confirm how a specific receiving server interpreted it at delivery time - alignment mode, selector matching, and policy enforcement are all evaluated by the receiver, not predicted by the validator. Send a live test message to an account you control at each provider you care about and read its actual header after every authentication change, rather than trusting the validator's result alone. Keep a small set of test mailboxes at the providers that matter most to your audience specifically for this purpose, so a post-change check takes minutes rather than requiring you to set one up under time pressure.

Where MailPilot fits

MailPilot checks SPF, DKIM and DMARC on the sending domain continuously, catching the configuration issues that would otherwise only surface as a fail or softfail buried in a header you had to go looking for - the kind of problem this header reveals after the fact, that ongoing monitoring catches before it affects placement.