What do the different Authentication-Results mean?

What the Authentication-Results header means

The Authentication-Results header is a trace field the receiving mail server stamps onto every incoming email, recording the pass/fail outcome of its SPF, DKIM, and DMARC checks. Reading it left to right tells you three things: whether the sending IP was authorized (spf=), whether the message carried a valid cryptographic signature (dkim=), and whether either of those aligned with the visible From: address (dmarc=). A line like spf=pass dkim=pass dmarc=pass is the receiving server's verdict that the message is authenticated and not spoofed. The header is defined by RFC 8601.

That's the summary an AI overview gives you. What it can't give you is the part that actually matters during an investigation: which result value you're looking at (there are eight for SPF alone), why an email can show spf=pass and dkim=pass yet still dmarc=fail, and how to tell a legitimate pass from a compromised-account pass. The table and diagram below decode every value, and a real header appears at the bottom for you to practice on.

The header you can trust is the one written by your own receiving system's authserv-id.

Learning to read Authentication-Results headers is essential for email security professionals, IT administrators, and anyone investigating suspicious mail. This one field provides definitive information about whether an email is likely legitimate or potentially spoofed, and helps you spot compromised accounts and phishing attempts. Try our free Email Authentication Validator to check a domain's SPF, DKIM, and DMARC setup instantly.

Structure of the Authentication-Results Header

The Authentication-Results header follows a standard format defined in RFC 8601 (published May 2019, obsoleting RFC 7601 and the original RFC 5451). Some older tools and MTAs still cite RFC 5451, but the field syntax and result values are the same lineage. 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, softfail, none, temperror, permerror, etc.)
• Properties: Additional details specific to the authentication method

Quick decode: every result value at a glance

This is the fastest way to read a header. Find the token in the header, match it below, and act on the verdict. The three methods do not share the same set of values — softfail exists only for SPF, and policy only for DKIM.

Token	Method	What it means	Verdict
spf=pass	SPF	Sending IP is authorized in the Return-Path domain's SPF record	✅ Authorized source
spf=fail	SPF	IP not authorized; record ends in -all (hard fail)	⛔ Likely spoof / misconfig
spf=softfail	SPF	IP not authorized; record ends in ~all (soft fail)	⚠️ Suspicious — forward or spoof
spf=neutral	SPF	Domain asserts nothing about the IP (?all)	➖ Inconclusive
spf=none	SPF	No SPF record published for the domain	➖ No policy
spf=temperror	SPF	Temporary DNS error during lookup	⚙️ Retry — not a verdict
spf=permerror	SPF	Malformed record or >10 DNS lookups	⚙️ Fix the record
dkim=pass	DKIM	Valid signature; body unaltered since signing	✅ Cryptographically authentic
dkim=fail	DKIM	Signature did not verify (forged or modified in transit)	⛔ Tampering indicator
dkim=neutral	DKIM	Signature present but couldn't be evaluated (e.g. no public key)	➖ Inconclusive
dkim=policy	DKIM	Signature verified but violates the verifier's local policy	⚠️ Accepted with caveat
dkim=none	DKIM	No DKIM signature present	➖ Unsigned
dkim=temperror / permerror	DKIM	DNS timeout / malformed key or signature	⚙️ Not a verdict
dmarc=pass	DMARC	SPF or DKIM passed and aligned with the From: domain	✅ Strongest single signal
dmarc=fail	DMARC	No aligned, passing mechanism; see the policy= value	⛔ Spoof or alignment break
dmarc=none	DMARC	No DMARC record, or no aligned identifier to evaluate	➖ No policy

Key insight: pass never means "safe" and fail never means "block automatically." SPF and DKIM authenticate infrastructure; only DMARC ties that back to the address a human actually sees. Always read all three tokens together.

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=policy: The signature verified correctly, but it does not satisfy the verifier's local policy (for example, the signature covers too few headers, or the key is too weak to be trusted). Note there is no dkim=softfail — that value belongs to SPF only. If you see "softfail" attached to a DKIM result, the MTA is using non-standard wording.

dkim=policy header.d=company.com reason="unacceptable key size"

dkim=none: No DKIM signature is present. The email wasn't signed.

dkim=none

dkim=temperror / dkim=permerror: A temporary DNS failure (temperror) or a permanent problem such as a malformed signature or unretrievable key record (permerror). Like their SPF counterparts, these are processing errors, not authentication verdicts.

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=name@domain.com: 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 header.from=ceo@company.com

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 ceo@company.com, 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 header.from=ceo@company.com

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

Paste a full raw header below to have every field — including Authentication-Results, Received hops, and originating IP — parsed and explained automatically:

To then confirm a domain's published SPF, DKIM, and DMARC records while reviewing a header, run it through the Email Authentication Validator. Always check:

1. Does the result match what you'd expect from the claimed domain?
2. Are there contradictions between SPF/DKIM/DMARC results?
3. Do the properties (sender domains, selectors) match the email's content?
4. 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.