KoltrixReading Authentication-Results headers like a receiver
The Authentication-Results header records the SPF, DKIM and DMARC verdicts a receiver reached. Decode each field and use it to debug failures fast.
On this page(9 sections)
- Where it comes from
- Reading each method
- SPF
- DKIM
- DMARC
- ARC and others
- Reading alignment from the header
- Worked examples
- Healthy transactional mail
- Forwarded mail
- Vendor not configured
- Broken DNS
- Viewing the header
- When there are several Authentication-Results headers
- Results that are not failures
- A debugging routine
- Key takeaways
When a message fails authentication, the receiver usually tells you exactly why, in a header most people scroll past. The Authentication-Results header records the SPF, DKIM, DMARC and sometimes ARC verdicts the receiving server reached, along with the identities it checked.
Learning to read it turns most authentication debugging into a five-minute job.
Where it comes from
Authentication-Results is defined in RFC 8601. A receiving server that performs authentication checks adds the header to the message before delivering it. Each header begins with an authserv-id, the name of the server that did the checking, followed by a list of method results.
Authentication-Results: mx.receiver.example;
spf=pass smtp.mailfrom=bounce.example.com;
dkim=pass header.d=example.com header.s=k1 header.b=AbCdEf12;
dmarc=pass (p=reject sp=reject dis=none) header.from=example.comBecause any server could insert a header with this name, receivers are supposed to remove Authentication-Results headers claiming their own authserv-id that arrive from outside. When you read the header, trust only the one added by the server you care about, normally the topmost one from your recipient's own provider.
Reading each method
Each result follows the pattern method=result, then optional comments in parentheses, then properties that identify what was checked, written as ptype.property=value.
SPF
spf=pass smtp.mailfrom=bounce.example.comsmtp.mailfromis the envelope sender domain SPF was evaluated against. If the envelope sender was empty (as for bounces), receivers may showsmtp.heloinstead.- Results include
pass,fail,softfail,neutral,none,temperrorandpermerror.
A comment often explains the reason, for example (domain of bounce.example.com designates 192.0.2.10 as permitted sender) or (too many DNS lookups).
DKIM
dkim=pass header.d=example.com header.s=k1 header.b=AbCdEf12header.dis the signing domain from thed=tag.header.sis the selector.header.bcontains the first few characters of the signature value, which helps identify which signature a result refers to when a message has several.
You may see multiple dkim= entries, one per signature. Results include pass, fail, neutral, none, temperror, permerror and sometimes policy. A comment such as (body hash did not verify) tells you the body was modified after signing; (no key for signature) points at DNS.
DMARC
dmarc=pass (p=reject sp=reject dis=none) header.from=example.comheader.fromis the From domain DMARC evaluated.- Comments often show the published policy (
p=,sp=) and the disposition applied (dis=), which reveals whether a failing message was quarantined or rejected. - Results are
pass,fail,none(no DMARC record),temperrorandpermerror.
ARC and others
Some receivers add arc=pass or arc=fail when the message carries an ARC chain, plus comments about the chain. Others include bimi= results or provider-specific methods. Unknown methods can be ignored safely.
Reading alignment from the header
Authentication-Results does not usually say "aligned" explicitly. You infer alignment by comparing domains:
| Property | Compare with header.from |
|---|---|
smtp.mailfrom |
Same organizational domain means SPF can align (relaxed mode) |
header.d |
Same organizational domain means DKIM can align (relaxed mode) |
If spf=pass smtp.mailfrom=vendor-mail.example and header.from=example.com, SPF passed but does not help DMARC. If DKIM also passed only for header.d=vendor-mail.example, DMARC fails despite two green "pass" results. That pattern is the single most common source of confusion when a vendor's mail starts failing after DMARC enforcement.
Worked examples
Healthy transactional mail
spf=pass smtp.mailfrom=bounce.example.com;
dkim=pass header.d=example.com header.s=k1;
dmarc=pass header.from=example.comBoth mechanisms pass and align under relaxed alignment. Nothing to do.
Forwarded mail
spf=fail smtp.mailfrom=example.com;
dkim=pass header.d=example.com header.s=k1;
dmarc=pass header.from=example.comSPF failed because a forwarder's IP connected, but the DKIM signature survived and aligned. DMARC passes. This is expected.
Vendor not configured
spf=pass smtp.mailfrom=mail.vendor.example;
dkim=pass header.d=vendor.example header.s=v1;
dmarc=fail (p=quarantine dis=quarantine) header.from=example.comEverything "passed," but nothing aligned with example.com. Enable custom-domain DKIM for the vendor.
Broken DNS
spf=permerror (too many DNS lookups) smtp.mailfrom=example.com;
dkim=permerror (no key for signature) header.d=example.com header.s=k2;
dmarc=fail header.from=example.comTwo separate configuration problems: the SPF record exceeds the lookup limit, and the selector k2 has no published key.
Viewing the header
Most webmail and desktop clients have a "show original" or "view source" option. Look near the top of the headers; the receiver adds Authentication-Results as it accepts the message, so it usually appears among the most recent headers rather than buried near the bottom. Some providers also add their own variants, such as ARC-Authentication-Results, which record results seen by intermediaries.
To pull results quickly from a saved message:
grep -A4 -i '^Authentication-Results:' message.emlWhen there are several Authentication-Results headers
A message that passed through more than one system can carry several of these headers: one from a security gateway in front of the mailbox, one from the mailbox provider itself, and sometimes one from an internal relay. Each records the view of the server named in its authserv-id, at the moment that server received the message.
That is useful when they disagree. If a gateway recorded dkim=pass and the mailbox provider behind it recorded dkim=fail (body hash did not verify), the gateway modified the message after checking it, typically by rewriting links or adding a banner. If the gateway recorded spf=pass for your IP while the provider recorded spf=fail for the gateway's IP, the provider is evaluating the internal hop rather than the original connection, which usually means it was not configured to trust the gateway as an inbound relay.
In other words, read them as a timeline, top to bottom, newest first. The topmost header from the final mailbox provider decides delivery, but the older ones tell you where along the path something changed.
Results that are not failures
Two results deserve special mention because they are often misread. none means the receiver found nothing to evaluate, such as no SPF record or no DKIM signature; it is an absence, not a rejection. temperror means a DNS lookup timed out or failed transiently. Neither should send you rewriting records before you have confirmed the problem repeats on a second test message.
A debugging routine
- Find the Authentication-Results header added by the recipient's provider.
- Note the
header.fromdomain. - Check SPF: result, and whether
smtp.mailfromshares the From domain's organizational domain. - Check every DKIM entry: result,
header.dalignment, and any comment. - Check DMARC: result, policy and disposition comments.
- If anything is
temperror, retry later before changing DNS; it may have been a transient lookup failure. - Fix the specific failure the comments point to, then send another test.
Key takeaways
- Authentication-Results (RFC 8601) records the receiver's SPF, DKIM and DMARC verdicts and the identities it checked.
- Trust the header added by the recipient's own server, normally the topmost one.
smtp.mailfrom,header.dandheader.fromare the three domains to compare for alignment.- Comments in parentheses often name the exact cause, from too many DNS lookups to a body hash mismatch.
- Two passes can still produce a DMARC fail when neither identity aligns with the From domain.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
