1. The Authentication-Results Header – Your Summary Dashboard
The Authentication-Results header is the single most important header for quickly assessing an email's authenticity. Added by the receiving mail server, it provides a summary of all authentication checks performed.
Header Format
Authentication-Results: [server] [version]; [method]=[result] [detail]Real Example from Gmail
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of example.com designates 192.0.2.45 as permitted sender) smtp.mailfrom=example.com;
dkim=pass header.i=@example.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.comWhat Each Part Means
- mx.google.com: The server that performed the authentication
- spf=pass: SPF check passed
- dkim=pass: DKIM signature validated
- dmarc=pass: DMARC check passed (alignment + policy)
- Detail in parentheses: Additional information about why the result was given
Possible Results for Each Method
- pass: The check succeeded
- fail: The check explicitly failed
- softfail: The check failed but is considered weak evidence (SPF ~all)
- neutral: The domain didn't express a clear policy (SPF ?all)
- none: No record or signature was present to check
- temperror: Temporary error (DNS timeout, etc.) – try again later
- permerror: Permanent error (malformed record/signature)
💡 Quick Assessment: If you see "spf=pass, dkim=pass, dmarc=pass" from a domain that matches the From header, the email is almost certainly legitimate (absent other issues).
2. SPF Verification in Headers – Tracking Authorization
SPF (Sender Policy Framework) verifies that the sending IP address is authorized to send email for the domain in the Return-Path (envelope-from).
SPF Results in Authentication-Results
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of newsletter.example.com designates 192.0.2.45 as permitted sender) smtp.mailfrom=newsletter.example.comKey information extracted:
- spf=pass: The check passed
- smtp.mailfrom=newsletter.example.com: The domain that was checked (from Return-Path)
- 192.0.2.45: The IP that was checked
SPF Failure Example
Authentication-Results: mx.google.com;
spf=fail (google.com: domain of paypal.com does not designate 203.0.113.88 as permitted sender) smtp.mailfrom=paypal.comThis email claims to be from paypal.com but was sent from 203.0.113.88, which is not in PayPal's SPF record. Almost certainly a phishing attempt.
Additional SPF Headers
Some servers add a dedicated Received-SPF header with even more detail:
Received-SPF: pass (google.com: domain of example.com designates 192.0.2.45 as permitted sender) receiver=mx.google.com; client-ip=192.0.2.45; envelope-from=example.com; helo=mail.example.com;What to Check When SPF Fails
- Is the email from a legitimate source that forgot to update SPF?
- Is the email spoofed (most likely)?
- Is the email forwarded (which breaks SPF)?
- Is there an SPF syntax error (look for "permerror")?
3. Analyzing DKIM-Signature Headers – Cryptographic Verification
DKIM adds a digital signature to emails, allowing receivers to verify that the message hasn't been altered and that it came from an authorized sender.
The DKIM-Signature Header Structure
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; t=1717345800; bh=3X6fKL9Xj5P2Zg8QwE1RtyUioPAsDfGhJkLzXcVbNmQ=; h=from:to:subject:date; b=HgR7jK2LpQ9mN3XcVbZxCfGtHyJkLpQwErTyUiOpAsDfGhJkLzXcVbNmQ=Decoding Each Tag
- v=1: DKIM version (always 1)
- a=rsa-sha256: Signing algorithm (RSA with SHA-256 hash)
- c=relaxed/relaxed: Canonicalization method for headers/body (how whitespace is handled)
- d=example.com: The domain that signed the email (THIS IS CRITICAL)
- s=selector1: The selector that points to the public key in DNS
- t=1717345800: Timestamp of signature (Unix epoch)
- bh=...: Body hash (proves the message body wasn't altered)
- h=from:to:subject:date: Headers that were signed
- b=...: The actual digital signature
DKIM Results in Authentication-Results
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=selector1 header.b=HgR7jK2L- header.i=@example.com: The signing domain (the d= tag value)
- header.s=selector1: The selector used
- header.b=...: First few characters of the signature (for reference)
What DKIM Pass Means
When DKIM passes, it proves:
- The email was signed by a server holding the private key for the domain
- The message body hasn't been altered since signing
- The specified headers haven't been altered since signing
DKIM Failure Analysis
Authentication-Results: mx.google.com;
dkim=fail header.i=@example.comPossible causes:
- Message altered in transit: A forwarding server changed the content
- Wrong key: The selector points to a public key that doesn't match the private key used
- Missing public key: DNS record for the selector doesn't exist
- Header modifications: A signed header was added, removed, or changed
⚠️ Critical: Even if DKIM passes, check that the signing domain (d=) matches or is aligned with the From header domain. A DKIM signature from example.com for an email with From: bank.com is suspicious.
4. DMARC in Headers – Alignment and Policy Enforcement
DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails.
DMARC Results in Authentication-Results
Authentication-Results: mx.google.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com- dmarc=pass: DMARC check passed (either SPF+alignment OR DKIM+alignment succeeded)
- p=REJECT: The domain's published DMARC policy for the main domain
- sp=REJECT: The domain's policy for subdomains (if specified)
- dis=NONE: What action the receiving server actually took (may differ if pct<100)
- header.from=example.com: The domain from the From header that was evaluated
DMARC Failure Example
Authentication-Results: mx.google.com;
dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=example.comIn this case, DMARC failed (neither SPF+alignment nor DKIM+alignment passed), and the receiving server took QUARANTINE action (sent to spam).
Understanding dis (Disposition)
- none: The receiving server took no special action (p=none or pct<100 applied)
- quarantine: The email was marked as spam or sent to a quarantine folder
- reject: The email was rejected outright (not delivered)
DMARC Policy Tags in Headers
Some servers add a dedicated DMARC header with policy details:
DMARC-Filter: OpenDMARC Filter v1.4.1 mail.example.com 1234567
DMARC-Policy: pass (p=reject, dis=none)5. Why Alignment Matters – SPF vs DKIM vs DMARC
Understanding the difference between authentication (SPF/DKIM passing) and alignment (matching the From header) is crucial for DMARC.
SPF Without Alignment (Common Failure)
SPF can pass but DMARC can still fail if the From header domain doesn't match the Return-Path domain:
Return-Path: bounce@mail.sendgrid.net
From: newsletter@example.com
SPF result: pass (bounce@mail.sendgrid.net authorized)
DMARC result: fail (From header domain example.com not aligned with Return-Path domain sendgrid.net)This is why third-party senders (ESPs) need to either:
- Use a From address matching their sending domain (e.g., newsletter@mail.sendgrid.net)
- Add your domain to their SPF record and use DKIM signing with your domain
DKIM Without Alignment
Similarly, DKIM can pass but fail alignment if the signing domain doesn't match From:
DKIM-Signature: d=sendgrid.net
From: newsletter@example.com
DKIM result: pass (signature valid from sendgrid.net)
DMARC result: fail (signing domain sendgrid.net doesn't match From header domain example.com)Successful Alignment Examples
SPF Alignment: Return-Path domain matches From domain
Return-Path: bounce@example.com
From: newsletter@example.com
SPF passes → DMARC passes (SPF aligned)DKIM Alignment: DKIM signing domain matches From domain (or organizational domain)
DKIM-Signature: d=example.com
From: newsletter@example.com
DKIM passes → DMARC passes (DKIM aligned)
💡 Remember: DMARC passes if EITHER SPF+alignment OR DKIM+alignment (or both) succeed. You don't need both—one is sufficient.
6. Common Authentication Failures and Their Causes
SPF Failures
- Wrong Return-Path: A third-party sender forgot to set Return-Path to their own domain
- Missing SPF include: ESP's IPs not added to your SPF record
- Too many DNS lookups: SPF record exceeds 10 lookups → permerror
- Email forwarding: Forwarding servers change the Return-Path, breaking SPF
DKIM Failures
- Missing selector: DNS record for the selector doesn't exist
- Wrong key: Public key in DNS doesn't match private key used for signing
- Message modification: A mailing list or forwarder altered content or headers
- Expired key: The private key was rotated but old signatures still being used
DMARC Failures (Alignment Issues)
- Third-party sender not configured correctly: ESP using their own domain in Return-Path without DKIM alignment
- Subdomain mismatch: From header uses subdomain but authentication for parent domain
- Email forwarding with ARC not implemented
Reading Failure Details
The detail text in parentheses often explains why failure occurred:
spf=fail (google.com: domain of example.com does not designate 192.0.2.45 as permitted sender)
dkim=fail (body hash did not verify)
dmarc=fail (SPF and DKIM did not pass alignment)7. Forwarding and ARC Headers – Preserving Authentication Through Forwarders
Email forwarding traditionally breaks authentication, especially SPF. ARC (Authenticated Received Chain) solves this.
The Forwarding Problem
When email is forwarded:
- Original email passes SPF and DKIM to the forwarding server
- Forwarding server sends a NEW email to the final recipient
- This new email has the forwarder's Return-Path, breaking SPF alignment
- DKIM may still pass if the forwarder didn't modify content
ARC Headers to the Rescue
ARC allows forwarding servers to "seal" authentication results so final receivers can trust them:
ARC-Seal: i=1; a=rsa-sha256; d=forwarder.com; s=arc-2024; cv=none; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.com; s=arc-2024; h=from:to:subject; bh=...; b=...
ARC-Authentication-Results: i=1; mx.google.com;
spf=pass smtp.mailfrom=original.com;
dkim=pass header.i=@original.com;
dmarc=pass header.from=original.comWhat ARC Headers Mean
- ARC-Authentication-Results: The authentication results from the original email (before forwarding)
- ARC-Message-Signature: A signature of the original email to prevent tampering
- ARC-Seal: A signature of the ARC headers themselves, creating a chain of trust
How to Identify ARC-Forwarded Emails
Look for the ARC header set near the top of the header block. Legitimate forwarders (newsletters, mailing lists) should implement ARC to preserve authentication.
💡 Pro Tip: If you run a mailing list or email forwarding service, implement ARC to avoid breaking authentication for your senders. If you're a sender, check whether your forwarders support ARC.
8. Troubleshooting Authentication Failures – Step-by-Step Guide
When SPF Fails
- Check the smtp.mailfrom domain in Authentication-Results
- Look up that domain's SPF record (dig TXT domain.com)
- Identify the sending IP from the Received headers or SPF detail
- Verify if that IP is in the SPF record
- If not, add it or work with the sender to correct
When DKIM Fails
- Extract the selector (s=) and domain (d=) from DKIM-Signature
- Look up the public key: dig TXT selector._domainkey.domain.com
- If no record exists, the sender has a configuration error
- If the record exists, check if the email was modified in transit
- Forwarders are the most common cause—ask them to implement ARC
When DMARC Fails (But SPF/DKIM Pass Individually)
- This is an alignment failure, not an authentication failure
- Check if From header domain matches Return-Path (for SPF) or DKIM d= (for DKIM)
- If using an ESP, configure custom Return-Path or DKIM signing with your domain
- Consider using a subdomain for third-party sends
Tools for Troubleshooting
- dig (command line) or online DNS lookup tools
- SPF record testing tools (e.g., Kitterman SPF checker)
- DKIM validator tools
- DMARC analyzer tools
- Google Admin Toolbox (Messageheader)
9. Real-World Header Authentication Examples
Example 1: Perfect Authentication (Newsletter)
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of bounce.example.com designates 192.0.2.45 as permitted sender) smtp.mailfrom=bounce.example.com;
dkim=pass header.i=@example.com header.s=selector1;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...
Return-Path: bounce@example.com
From: "Newsletter" Analysis: All three pass. Return-Path matches From domain (example.com). DKIM signing domain matches. Perfect authentication.
Example 2: SPF Only (DKIM Neutral)
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of e.example.com designates 192.0.2.100 as permitted sender) smtp.mailfrom=e.example.com;
dkim=neutral (no signature);
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.comAnalysis: SPF passes and aligns (Return-Path e.example.com is a subdomain of example.com, which DMARC considers aligned). DKIM not present. DMARC still passes because SPF+alignment is sufficient.
Example 3: DKIM Only (SPF Fails)
Authentication-Results: mx.google.com;
spf=fail (google.com: domain of bounce.sendgrid.net does not designate 203.0.113.50 as permitted sender);
dkim=pass header.i=@example.com header.s=selector1;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.comAnalysis: SPF fails (Return-Path is sendgrid.net, IP not authorized). DKIM passes with example.com signing domain, which aligns with From header. DMARC passes because DKIM+alignment is sufficient.
Example 4: Complete Failure (Phishing)
Authentication-Results: mx.google.com;
spf=fail (google.com: domain of paypal.com does not designate 203.0.113.88 as permitted sender);
dkim=neutral (no signature);
dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=paypal.com
From: "PayPal Security"
Return-Path: verify@phishing-site.ru Analysis: SPF fails (IP not authorized for paypal.com), no DKIM, DMARC fails. The From header claims to be PayPal but authentication proves otherwise. Quarantine action was taken. This is almost certainly a phishing email.
Example 5: ARC-Preserved Forwarding
ARC-Authentication-Results: i=1; mx.google.com;
spf=pass smtp.mailfrom=original.com;
dkim=pass header.i=@original.com;
dmarc=pass header.from=original.com
ARC-Message-Signature: i=1; ...
ARC-Seal: i=1; ...
Authentication-Results: forwarding.com;
spf=pass (forwarder's server authorized);
dkim=pass (original signature intact);
dmarc=pass (ARC chain validated)Analysis: The email was forwarded, but ARC headers preserve the original authentication results. Final DMARC passes due to ARC validation.
10. Best Practices for Authentication Header Analysis
For Email Receivers (Security Teams)
- Always check Authentication-Results first – It's your summary dashboard
- Never trust the From header alone – It's easily forged
- For sensitive domains, expect DMARC=pass – If a bank email fails DMARC, it's phishing
- Check alignment – Passed SPF/DKIM mean nothing if they don't align with From
- Look for ARC headers on forwarded mail – They preserve trust through forwarders
For Email Senders (Marketers, IT)
- Test authentication before sending – Use tools to verify SPF, DKIM, DMARC
- Monitor your Authentication-Results – Set up DMARC reporting to see how receivers see your email
- Fix failures immediately – Every failure is a deliverability risk
- Implement DMARC p=reject when ready – Prevents spoofing and improves reputation
- Work with ESPs on alignment – Ensure custom Return-Path and DKIM signing with your domain
Quick Reference Card
- Good email: spf=pass OR dkim=pass AND dmarc=pass with matching From domain
- Suspicious email: spf=fail AND dkim=fail AND dmarc=fail
- Misconfigured legitimate email: One method passes but alignment fails
- Forwarded email: Look for ARC headers
🏆 Final Takeaway: Email authentication headers are your first line of defense against phishing and your primary tool for deliverability troubleshooting. By learning to read Authentication-Results, DKIM-Signature, and ARC headers, you can instantly assess email legitimacy and diagnose sending problems. Bookmark this guide and practice on your own emails until header analysis becomes second nature.