Authentication-Results Header Guide
Received-message headers show what the receiving system evaluated; a DNS record alone cannot prove that a production message authenticated.
Use an independent recipient
Send through the exact mailbox, application or marketing route being tested to an account outside the sending system. Forwarding can change the path, so inspect the originally received message.
Find Authentication-Results
Look for SPF, DKIM and DMARC results recorded by the receiver you trust. Multiple intermediary headers can exist; identify which system added each one.
Interpret SPF
Record the evaluated envelope or return-path domain and sending IP. An SPF pass for a provider domain does not by itself align with the visible From domain.
Interpret DKIM
Record the signing domain and selector from the signature. A pass shows the signed content verified against the public key; DMARC separately considers alignment with the visible From domain.
Interpret DMARC
DMARC passes when a passing SPF or DKIM identity is suitably aligned. Record the aligned mechanism instead of reducing the result to a generic score.
Protect evidence
Keep only the fields needed for diagnosis. Redact addresses, identifiers and message content before sharing, and never disclose private keys or account credentials.
Authoritative references
Read the underlying standards and provider instructions before changing production DNS: RFC 7208 (SPF), RFC 9989 (DMARC), Google Workspace SPF guidance and your sending provider's current DKIM documentation.
Editorial responsibility
Published by Acerville Sparks Limited. Software assists research, drafting and automated record testing. Internet standards, provider documentation, reproducible checks and limitations are shown so readers can inspect the work. No independent deliverability consultant review is claimed. Reviewed 4 September 2026.
What this site does not do
No inbox guarantee. No live DNS checks. No storage of entered data. No passwords or private keys requested.