The Authentication-Results header is where a receiving mail server records its SPF, DKIM and DMARC verdicts. To debug a message, open the full headers, find the topmost Authentication-Results line added by your own provider, and read each result and the domain beside it. Trust only headers added by servers you control.
Find the headers
In most mail clients there is a "show original" or "view source" option. Look for lines beginning Authentication-Results:. RFC 8601 defines the format. The first token after the colon is the authserv-id, the name of the server that did the checking.
A message passes through several servers, so you may see more than one such header. Each applies to a different hop.
Which one to trust
Anyone can write a header that looks like a result. RFC 8601 handles this by tying results to the authserv-id. The header you want is the one whose authserv-id is your own mail provider, and receiving systems are expected to remove or distrust such headers that claim to be from their own domain but arrived from outside. If you read a forwarded message with a result claiming a different checker, treat it as a hint only.
The result lines
A typical set looks like this, with placeholder domains:
Authentication-Results: mx.receiver.example;
spf=pass smtp.mailfrom=bounce.example.com;
dkim=pass header.d=example.com header.s=sel1;
dmarc=pass header.from=example.com
Read each part:
- spf=pass smtp.mailfrom=... is the SPF verdict and the envelope domain that was checked.
- dkim=pass header.d=... header.s=... is the DKIM verdict, the signing domain and the selector.
- dmarc=pass header.from=... is the DMARC verdict for the visible From domain.
Possible SPF results in RFC 7208 are none, neutral, pass, fail, softfail, temperror and permerror. DKIM results include pass, fail, and neutral, among others.
Debug by pattern
| What you see | Likely cause |
|---|---|
| spf=pass, dkim=pass, dmarc=fail | Neither domain aligns with From. Compare smtp.mailfrom and header.d to header.from |
| spf=permerror | More than one SPF record, bad syntax, or over 10 lookups |
| dkim=fail | Message changed after signing, or the selector key is wrong or missing |
| dkim=none, spf=fail | Sender missing from SPF and no signature. Fix the sender setup |
| spf=fail only on forwarded mail | Normal forwarding behaviour. Check whether DKIM passes |
A debugging routine
- Send a test from the affected system to a mailbox you can inspect.
- Open the full headers. Note the three results and the three domains.
- Compare header.d and smtp.mailfrom with header.from. Alignment is the most common failure.
- Check the DNS records for whichever check failed, from outside your network.
- After a fix, send another test, since DNS changes can take time to propagate.
Keep copies of headers from good messages. A known good baseline makes the next failure easier to read.
Quick check
Is a pass in this header proof the mail is legitimate?
No. It shows what the receiver's own checks concluded about domain authentication. A malicious sender can pass for their own domain.
Sources
- RFC 8601, Message Header Field for Indicating Message Authentication Status
- RFC 7208, Sender Policy Framework
- RFC 9989, DMARC
Last reviewed: 19 October 2026.
