How to Analyze an Email Header for Authentication Results

When investigating a suspicious email, a delivery issue, or a spoofing report, the email header is the most reliable source of truth. It records every hop the message took, which servers handled it, and most importantly for authentication troubleshooting, whether the message passed SPF, DKIM, and DMARC checks.

Step 1: Retrieve the Email Header

The raw header is not visible in the normal message view; you need to explicitly view the "original message" or "source" in each client. Below are the general steps for the most common clients.

Outlook (Desktop, Windows)

Select More actions at the top of the message window.
Select View > View message details.

Outlook on the Web

Select More actions at the top of the message window.
Select View > View message details.

Gmail

From a browser, open Gmail.
Open the email you want to check the headers for.
Next to Reply, click More Show original.
- In a new window, the full header shows.
Click Copy to clipboard.

Apple Mail (on iCloud.com)

Go to icloud.com/mail, then sign in to your Apple Account (if necessary).
Select an email.
Select , then select Show All Headers. To stop showing all headers, select , then select Show Default Headers.

Apple Mail (MacOS)

Open Apple Mail.
Open the email you want to see the headers for.
Click ViewMessage All Headers.

Yahoo Mail

Click on an email to open it.
Click the More options icon ⋯
Select View Raw Message.

Mobile Clients (iOS/Android Mail apps)

Most native mobile mail apps do not expose full raw headers. It's generally easier to access the same mailbox via webmail (Gmail, OWA, etc.) to pull the header.

Step 2: View the Header with the Message Header Analyzer

Raw headers are long and difficult to read as plain text. Instead of scrolling through raw text, paste the header into the Message Header Analyzer.

Copy the entire raw header text from Step 1.
Paste it into the analyzer's input box.
Click Analyze headers.

The tool will organize the header into readable sections, including a timeline of hops (received chain) and a dedicated summary of authentication results, which is much easier to review than the raw text block.

The analyzer breaks the header into several collapsible sections. Here's what each one contains and what to look for:

Summary

The Summary section shows the basic envelope details of the message at a glance: Subject, Message Id, Creation time, From, Reply to, and To.

What to look for: Compare the From and Reply to addresses. A mismatch (e.g., the From domain looks legitimate but Reply to points to an unrelated domain) is a common sign of spoofing or phishing. Also, confirm the Creation time lines up with when the recipient actually received the message; a large gap can indicate delivery delays or replay.

Received Headers

This section lists every hop the message took from the originating server to the final mailbox, in order. Each row shows the Submitting host, Receiving host, Time, Delay, and connection Type (e.g., SMTP, HTTP, HTTPS, or a specific TLS cipher for Microsoft servers).

What to look for:

The first hop (lowest hop number) tells you the actual originating server/IP — this is the server whose IP is checked against SPF.
Long or unusual Delay values between hops can indicate the message was held, queued, or routed through an unexpected relay.
Unexpected or unfamiliar Submitting host entries partway through the chain can indicate the message was relayed through a compromised or unauthorized system.

Forefront Antispam Report Header (for Microsoft 365 / Exchange Online)

This section is specific to Microsoft 365 / Exchange Online and shows Microsoft's own spam and reputation evaluation of the message, independent of SPF/DKIM/DMARC. Key fields include Country/Region, Language, Spam Confidence Level (SCL), Spam Filtering Verdict, IP Filter Verdict, HELO/EHLO String, PTR Record, Connecting IP Address, Protection Policy Category, and Spam rules. Use the Anti-spam message headers article from Microsoft, to find an explanation for each field and value.

What to look for:

Spam Confidence Level (SCL): A numeric score. Higher values indicate a higher likelihood that the message is spam. A value of -1 typically means the message skipped filtering (e.g., from a trusted sender or intra-org mail).
Spam Filtering Verdict: A short code (e.g., NSPM = Not Spam) summarizing Microsoft's overall verdict.
HELO/EHLO String and PTR Record: Compare these to the Connecting IP Address and the sending domain. A mismatch between the PTR record's domain and the claimed sending domain can be a red flag.
Protection Policy Category: Indicates whether any specific anti-phishing or anti-spoofing policy was applied to the message.

Other Headers

This section lists all remaining headers not covered above, most importantly the Authentication-Results, Received-SPF, and DKIM-Signature headers. The core headers used for the authentication analysis in Steps 3 and 4 of this article. It will also include other technical headers like Content-Type, MIME-Version, and any vendor-specific tracking headers (e.g., X-SG-EID, X-SG-ID).

What to look for:

Authentication-Results: The primary field for this investigation. Contains the SPF, DKIM, and DMARC results in one place (see Step 3).
Received-SPF: A secondary, more verbose SPF-specific header. It restates the SPF result along with the reasoning (e.g., which domain's SPF record was checked and why it passed or failed) and the exact client-ip and helo values used in the check.
DKIM-Signature: Shows the raw signature data, including the signing domain (d=) and the selector (s=) used to locate the public key in DNS. You generally don't need to decode the signature itself — the pass/fail result in Authentication-Results already tells you the outcome — but the d= value here is useful to double check against the From: domain for alignment.

Step 3: Understand the Authentication-Results Header

Look for a header field called Authentication-Results. This is typically added by the receiving mail server (e.g., Microsoft 365, Google Workspace) and records the outcome of SPF, DKIM, and DMARC checks performed on the message.

A typical example looks like this:

Authentication-Results: mx.example.com; spf=pass (sender IP is 203.0.113.10) smtp.mailfrom=bounce.senderdomain.com; dkim=pass (signature was verified) header.d=senderdomain.com; dmarc=pass action=none header.from=senderdomain.com;

Note: some organizations (e.g., Microsoft 365) use a similar but vendor-specific field, Authentication-Results (compauth), or an additional X-MS-Exchange-Authentication-Results / ARC-Authentication-Results header when the message passed through intermediate relays. Always check for multiple authentication header instances; the one closest to the final recipient's receiving server is usually the most relevant to your investigation.

SPF Results

SPF (Sender Policy Framework) checks whether the sending server's IP address is authorized to send mail for the domain used in the envelope-from (also called smtp.mailfrom or Return-Path).

Result	Meaning
pass	The domain's SPF record authorizes the sending IP.
fail	The sending IP is explicitly not authorized (`-all`).
softfail	The IP is not authorized, but the domain's policy is lenient (`~all`);
neutral	The SPF record explicitly states no assertion either way (`?all`).
none	No SPF record exists for the domain.
temperror	A temporary error occurred during the DNS lookup (e.g., timeout); retry may succeed.
permerror	A permanent error occurred, often due to a malformed SPF record.

DKIM Results

DKIM (DomainKeys Identified Mail) verifies that the message was signed with a private key and that the signature matches a public key published in DNS by the signing domain (d= value in the DKIM-Signature header).

Result	Meaning
pass	The DKIM signature is valid and matches the published public key.
fail	The signature is present but invalid (e.g., message was modified in transit, or key mismatch).
none	No DKIM-Signature header was found on the message.
policy	A signature was found but did not meet the verifier's local policy requirements.
neutral	The signature could not be verified for reasons unrelated to validity (rare).
temperror	Temporary failure, often a DNS lookup issue retrieving the public key.
permerror	Permanent failure, such as a malformed signature or missing DNS record.

A message can have multiple DKIM signatures (e.g., one from the original sender and one added by a mailing list or forwarding service). The analyzer will list each one; check the d= domain on each to know who signed it.

DMARC Results

DMARC (Domain-based Message Authentication, Reporting & Conformance) doesn't perform its own cryptographic or IP check; instead, it evaluates whether SPF and/or DKIM passed and are aligned with the domain in the visible From: header, then applies the policy published in the domain's DMARC DNS record.

Result	Meaning
pass	At least one of SPF or DKIM passed and was aligned with the From: domain.
fail	Neither SPF nor DKIM passed with alignment. The receiving server will apply the domain's published policy (p=none, quarantine, or reject).
none (as a result, distinct from p=none)	No DMARC record was published for the domain.
temperror / permerror	Same meaning as above. DNS lookup issues (temporary) or a malformed DMARC record (permanent).

You may also see an action= or policy applied disposition (e.g., action=none, action=quarantine, action=reject). This tells you what the receiving server actually did with the message based on the domain's published DMARC policy, which is separate from the pass/fail result itself.

Step 4: Check DMARC Alignment for SPF and DKIM

This is the step most people get wrong: SPF or DKIM can individually "pass," but DMARC still fails if the passing domain doesn't align with the visible From: address.

DMARC alignment compares the domain in the message's From: header against the domain used in the SPF and DKIM checks. There are two alignment modes:

Relaxed alignment (default): The domains just need to share the same organizational domain (e.g., mail.example.com aligns with example.com).
Strict alignment: The domains must match exactly, including subdomains.

The domain's DMARC record specifies which mode applies via the aspf (SPF alignment) and adkim (DKIM alignment) tags. If not specified, both default to relaxed.

How to Check SPF Alignment

Find the header.from domain (the visible sender address the recipient sees).
Find the domain used in the SPF check. This is the smtp.mailfrom or envelope-from domain shown in the Authentication-Results header (also called the Return-Path).
Compare them:
- If they match (exactly, for strict; or same org domain, for relaxed) → SPF is aligned.
- If they don't match → SPF may have "passed," but it does not count toward DMARC.

Example for aligned:

header.from: [email protected]

smtp.mailfrom=bounce.example.com → aligned (relaxed, same org domain)

Example for not aligned:

header.from: [email protected]

smtp.mailfrom=vendor.com → NOT aligned, even if SPF result = pass

How to Check DKIM Alignment

Find the header.from domain.
Find the d= domain in the DKIM-Signature (shown in Authentication-Results as header.d=).
Compare them the same way as SPF.

Example for aligned:

header.from: [email protected]

header.d=example.com → aligned

Example for not aligned:

header.from: [email protected]

header.d=esp-provider.com → NOT aligned, even if DKIM result = pass

Putting It Together

DMARC passes if either SPF or DKIM passes and is aligned. It's common and expected for one mechanism to fail or be unaligned as long as the other one is aligned and passing. For example, mail forwarded through a mailing list often breaks SPF alignment but still passes DMARC via an aligned DKIM signature that survives the forward (as long as the message is not modified in transit).

If you find a message where SPF and DKIM both show pass in the Authentication-Results header, but DMARC shows fail, alignment is always the reason. Go back and compare the From: domain against the smtp.mailfrom and header.d domains individually to identify which one broke.

Quick Reference Checklist

When analyzing a header, work through these in order:

Pull the raw header from the client (Step 1) and paste into the Message Header Analyzer.
Locate the Authentication-Results header (use the one closest to your organization's inbound server).
Note the SPF, DKIM, and DMARC results individually.
Identify the smtp.mailfrom domain, and the header.d= domain.
Compare each against the From: domain (header.from) to confirm SPF alignment and DKIM alignment.
Confirm the overall DMARC result and the policy action applied (none, quarantine, reject).