Introduction to Authentication-Results Headers
The Authentication-Results header is one of the most important fields in an email message, yet many email users and even IT professionals don't understand what it means. This header field contains the results of email authentication checks performed by the receiving mail server on incoming messages. It tells you whether the email has passed or failed authentication protocols like SPF, DKIM, and DMARC.
Learning to read Authentication-Results headers is essential for email security professionals, IT administrators, and anyone responsible for investigating suspicious emails. This header provides definitive information about whether an email is likely legitimate or potentially spoofed, and helps you identify compromised accounts or phishing attempts.
Structure of the Authentication-Results Header
The Authentication-Results header follows a standard format defined in RFC 5451. A typical Authentication-Results header looks like this:
Authentication-Results: example.com;
spf=pass smtp.from=company.com;
dkim=pass header.d=company.com header.s=default;
dmarc=pass header.from=company.com
Let's break down the components:
Header Components
Authserv-id: The authenticating authority that performed the checks. This identifies which mail server is reporting the results. In the example above, "example.com" is the organization that ran the authentication checks.
Authres-items: Individual authentication results, separated by semicolons. Each item contains:
- Method name: The authentication protocol (spf, dkim, dmarc, etc.)
- Result: The outcome (pass, fail, neutral, tempfail, none, etc.)
- Properties: Additional details specific to the authentication method
Understanding SPF Results
The SPF (Sender Policy Framework) portion of Authentication-Results indicates whether the sending mail server's IP address was authorized by the domain's SPF policy.
SPF Result Types
spf=pass: The sending server's IP address matches an IP address listed in the domain's SPF record. The email is from an authorized source for that domain.
spf=pass smtp.from=company.com smtp.mailfrom=company.com
This indicates the email passed SPF authentication, and the Return-Path address (envelope sender) is company.com.
spf=fail: The sending server's IP address does not match any authorized IPs in the SPF record. The domain's SPF policy explicitly rejects emails from this source.
spf=fail smtp.from=company.com smtp.mailfrom=company.com
This is a strong indicator of spoofing or misconfiguration. The email is claiming to come from company.com, but the sending IP isn't authorized.
spf=softfail: The sending server is not authorized, but the domain's SPF policy uses a soft fail (~all) rather than hard fail (-all). This means "probably not authorized, but don't necessarily reject."
spf=softfail smtp.from=company.com smtp.mailfrom=company.com
Softfail indicates the domain lacks strict SPF enforcement. The email might be legitimate (forwarded, misdirected) but could also be spoofed.
spf=neutral: The domain explicitly states it's not asserting whether the IP is authorized or not. This is less common and indicates the domain hasn't configured a clear SPF policy.
spf=neutral smtp.from=company.com
spf=none: No SPF record exists for the domain. The domain hasn't published an SPF policy.
spf=none smtp.from=example.com
spf=temperror: A temporary DNS error occurred while looking up the SPF record. The result is inconclusive.
spf=temperror smtp.from=example.com
spf=permerror: A permanent error occurred—usually because the SPF record is malformed or exceeds DNS lookup limits.
spf=permerror smtp.from=example.com
SPF Properties
SPF results include additional properties:
- smtp.from=domain.com: The Return-Path domain (envelope sender)
- smtp.mailfrom=domain.com: Alternative notation for the envelope sender
- client-ip=192.0.2.1: The IP address of the sending mail server
- identity=mailfrom: What identity was being checked
Understanding DKIM Results
DKIM (DomainKeys Identified Mail) results indicate whether the email's cryptographic signature is valid and whether it was signed by the claimed domain.
DKIM Result Types
dkim=pass: The email has a valid DKIM signature, and the signature is from the domain shown in the header.
dkim=pass header.d=company.com header.s=default c=relaxed/relaxed
This indicates the email is authentic and hasn't been modified since it was signed. The header.d property shows the domain that signed it, and header.s shows the selector (key identifier) used.
dkim=fail: The DKIM signature is invalid. This could mean:
- The signature was forged
- The email was modified after signing
- The DKIM record was unavailable or incorrect
dkim=fail header.d=company.com reason="signature did not verify"
DKIM failures are serious indicators of tampering or spoofing.
dkim=neutral: A DKIM signature is present, but the signing domain is unsigned, unsigned by the identity being queried, or the signature was invalid in some other way.
dkim=neutral header.d=company.com reason="no key for signature"
This often means the DKIM public key couldn't be found in DNS or the key doesn't match the signature.
dkim=softfail: The signature verification failed in a way that indicates the message should be treated as unsigned, but the failure is not due to the signature being invalid.
dkim=softfail header.d=company.com
dkim=none: No DKIM signature is present. The email wasn't signed.
dkim=none
DKIM Properties
Important DKIM properties include:
- header.d=domain.com: The domain that signed the message
- header.s=selector: The DKIM selector (identifies which public key was used)
- header.i=[email protected]: The identity/address that signed the message
- header.b=hash: The hash of the signature (first 16 characters)
- c=relaxed/relaxed: Canonicalization algorithm used
- a=rsa-sha256: The signing algorithm
- reason=: Explanation for failures
Understanding DMARC Results
DMARC (Domain-based Message Authentication, Reporting and Conformance) results indicate whether the email passed alignment checks that compare authentication results against the visible sender address.
DMARC Result Types
dmarc=pass: The email passed DMARC alignment checks. This means either SPF or DKIM (or both) passed AND aligned with the From: header domain.
dmarc=pass header.from=company.com
This is the best possible result—the email is authenticated and the authentication aligns with what the user sees.
dmarc=fail: The email failed DMARC alignment. SPF or DKIM (or both) either failed or didn't align with the From: header.
dmarc=fail header.from=company.com policy=reject
This indicates the email is either spoofed or didn't follow the organization's email practices. The policy property shows what the organization requested happen with failing emails (reject, quarantine, or none).
dmarc=none: No DMARC policy exists for the domain, or the header.from domain doesn't match any domain in the DMARC hierarchy.
dmarc=none header.from=example.com
DMARC Properties
Important DMARC properties include:
- header.from=domain.com: The domain shown in the email's From: header
- policy=reject|quarantine|none: The policy the domain published
- policy.report_interval=86400: How often aggregate reports are sent
- alignment=relaxed|strict: The alignment mode used
- auth=spf|dkim|both: Which mechanism(s) passed alignment
Advanced Interpretation Patterns
The Alignment Gap: SPF/DKIM Pass, DMARC Fail
It's possible to see:
spf=pass smtp.from=bounce.company.com
dkim=pass header.d=company.com
dmarc=fail [email protected]
This happens when:
- SPF passes for bounce.company.com (the Return-Path domain)
- DKIM passes for company.com (the signing domain)
- But the visible From: is [email protected], and alignment is strict
SPF alignment requires the Return-Path domain to exactly match the From: domain in strict mode. This might fail due to legitimate forwarding or misconfiguration.
The Suspicious Pass: Normal Results, Odd Context
spf=pass smtp.from=company.com
dkim=pass header.d=company.com
dmarc=pass header.from=company.com
This could be legitimate, but combined with other header anomalies (unusual timestamps, unexpected origin IP, or suspicious content), it might indicate an account compromise where an attacker is using legitimate credentials.
The Red Flag: Multiple Failures
spf=fail smtp.from=company.com
dkim=fail header.d=company.com reason="no key for signature"
dmarc=fail header.from=company.com policy=reject
All failures indicate strong spoofing indicators. If this email reached your inbox despite the policy=reject, it either:
- Came through an unusual routing path
- Was delivered before policy enforcement
- Indicates a filtering system bypass
Common Real-World Examples
Legitimate Company Email
Authentication-Results: company.com;
spf=pass smtp.from=company.com;
dkim=pass header.d=company.com header.s=default;
dmarc=pass header.from=company.com
All checks pass and align—this is legitimate.
External Email from Gmail
Authentication-Results: company.com;
spf=pass smtp.mailfrom=gmail.com;
dkim=pass header.d=gmail.com header.s=20120113;
dmarc=pass (policy=none) header.from=gmail.com
The user has Gmail authentication. SPF/DKIM pass for Gmail, not the user's domain. DMARC might show policy=none because Gmail's DMARC policy allows this.
Phishing Attempt Spoofing Your Company
Authentication-Results: company.com;
spf=fail smtp.from=company.com;
dkim=none;
dmarc=fail header.from=company.com policy=reject
Clear indicators of spoofing: SPF fails, no DKIM signature, DMARC fails.
Compromised Account Sending from New Location
Authentication-Results: company.com;
spf=pass smtp.from=company.com;
dkim=pass header.d=company.com header.s=default;
dmarc=pass [email protected]
Authentication passes (attacker uses real credentials), but combined with unusual IP in Received headers, suggests compromise rather than spoofing.
Using Authentication-Results for Security Decisions
Creating Email Security Rules
Use Authentication-Results to:
- Quarantine SPF/DKIM/DMARC failures from high-risk domains
- Flag alignment failures for manual review
- Whitelist authenticated emails from trusted domains
- Create policies based on policy property (reject vs. quarantine failures)
Investigating Suspicious Emails
Always check:
- Does the result match what you'd expect from the claimed domain?
- Are there contradictions between SPF/DKIM/DMARC results?
- Do the properties (sender domains, selectors) match the email's content?
- How does this compare to normal emails from this sender?
Training Your Team
Help your team understand:
- Pass = likely legitimate, but not absolutely certain (could be a compromised account)
- Fail = strong indicator of spoofing or compromise, especially if policy=reject
- None/Neutral = inconclusive, requires additional context
- Errors (temperror, permerror) = DNS issues, not authentication results
Conclusion
The Authentication-Results header provides definitive information about email authenticity. By understanding the differences between SPF, DKIM, and DMARC results, and learning to interpret the various status values and properties, you can effectively identify spoofed emails, compromised accounts, and phishing attempts.
The key takeaway is that authentication results should be just one part of your email security strategy. Combine header analysis with other techniques like user behavior analysis, content filtering, and URL analysis to create comprehensive email security that stops threats before they reach users. Organizations that invest in understanding Authentication-Results headers gain a significant advantage in defending against email-based attacks.
