DIAGNOSTIC PLAYBOOK
Which Authentication-Results header should you trust?
Authentication-Results headers are assertions by the system that added them. A sender can insert misleading header text, so trust depends on the receiving system's handling and the identified authentication service.
HealthCheck Email editorial team · · Examples are illustrative
How to investigate
- Find the header added by your own receiving provider and identify its authserv-id.
- Keep results from different hops separate instead of merging every pass and fail.
- Use the provider's raw-message view or logs to confirm which result belongs to the final trusted boundary.
What this looks like
ILLUSTRATIVE EXAMPLE
A message contains a lower header claiming dmarc=pass, while the trusted receiving provider reports failure. The earlier text is not automatically authoritative.
A mistake to avoid
The presence of a familiar provider name inside a header does not prove that provider added it. Trust requires context from the receiving infrastructure.
Keep the result in context
Inspect the original raw message rather than a forwarded screenshot. Headers can contain private addresses, message identifiers and routing information, so redact a separate copy before sharing. Give the most weight to results added by your own trusted receiving infrastructure.
Take the next step
Use the related check to gather evidence, then compare it with the affected message or service. Keep the result and time with your notes so a later change can be distinguished from the original problem.
Sources and further reading
The protocol references below explain the underlying behavior. Your sending or DNS provider supplies the account-specific settings for its service.