How to read email headers

Email headers are the message's travel record. They show which servers handled it, whether it passed SPF, DKIM and DMARC, and what your spam filter decided. Once you know which lines to trust, you can answer most "why did this land in spam?" and "is this real?" questions in a few minutes.

How do I see the full email headers?

Every client hides headers by default. Here's where to find them:

The steps come from Gmail Help, Microsoft Support and Apple's Mail guide. Copy everything, from the first line to the blank line before the message body.

If a user forwards you a suspicious email, the headers you see belong to the forward, not the original. Ask them to send it as an attachment, or to copy the headers using the steps above.

Which email headers can you trust?

This is the most important idea in header analysis. A header is only as trustworthy as the system that wrote it.

• Written by the sender: From, To, Subject, Date, Reply-To, Message-ID, and any Received lines added before the message reached your systems. The sender can put anything here.
• Written by your receiving systems: the top Received lines, Authentication-Results, and filter headers such as Microsoft's X-Forefront-Antispam-Report. These are reliable, as long as you know which servers are yours.

RFC 8601, which defines Authentication-Results, requires a receiving server to delete any copy of that header that claims to come from its own domain but arrived from outside. That stops an attacker pre-stamping dmarc=pass. It only works if you read the header with your provider's name in it.

How to read the Received chain (bottom up)

Each mail server that accepts a message must add a Received line at the top of the header. RFC 5321, section 4.4 says servers must not change or reorder existing lines. So the newest hop is at the top, and the oldest is at the bottom.

A simplified chain:

Received: from mx.filter.example (mx.filter.example [198.51.100.25])
    by mail.yourcompany.example with ESMTPS id 4Xk2...; Thu, 8 Oct 2026 09:14:07 +0000
Received: from out.mailer.example (out.mailer.example [203.0.113.40])
    by mx.filter.example with ESMTPS id a81f...; Thu, 8 Oct 2026 09:14:05 +0000
Received: from [192.0.2.17] (helo=laptop)
    by out.mailer.example with ESMTPSA; Thu, 8 Oct 2026 09:14:03 +0000

Read it from the bottom:

1. A device at 192.0.2.17 submitted the message to out.mailer.example (the SA in ESMTPSA means TLS plus SMTP authentication, per RFC 3848).
2. out.mailer.example, at 203.0.113.40, delivered it to the filtering server.
3. The filtering server passed it to your mail server.

Each line has the same parts: from (the host name it claimed and the IP the receiving server actually saw), by (the server that wrote the line), with (the protocol; ESMTPS means TLS was used), and a timestamp.

What to look for in the Received chain

• The handover point. Find the first line written by a server you trust, such as your provider or gateway. The IP in its from part is the real connecting server. Everything below it is the sender's claim.
• Gaps in time. Compare timestamps hop by hop. A long gap shows where a message was delayed, for example when a server was down and the sender retried.
• Mismatched names. A server that calls itself mail.bank.example but connects from an IP with no matching reverse DNS is worth a closer look.
• Unexpected routes. If mail to your domain reaches your mailboxes without passing your filter, someone may be bypassing your MX. See how to block direct-to-tenant delivery.

How to read Authentication-Results

Find the Authentication-Results header that starts with your receiving system's name. In Microsoft 365, a typical one looks like this:

Authentication-Results: spf=pass (sender IP is 203.0.113.40)
  smtp.mailfrom=bounce.mailer.example; dkim=pass (signature was verified)
  header.d=example.com; dmarc=pass action=none header.from=example.com;
  compauth=pass reason=100

The key fields, as described by Microsoft Learn:

Now compare the three domains. In the example, SPF passed for bounce.mailer.example, which doesn't align with example.com. DKIM passed for example.com, which does. That aligned DKIM pass is why DMARC passed. For a refresher on alignment, see SPF vs DKIM vs DMARC.

A few compauth reason codes worth knowing: 000 means explicit DMARC failure against a quarantine or reject policy; 001 means implicit failure, often a sender with weak or missing records; 130 means a trusted ARC sealer overrode a DMARC failure; 905 means DMARC wasn't enforced because of complex routing, such as mail passing through a non-Microsoft service first.

What are ARC headers?

When a mailing list or forwarding service changes a message, SPF and DKIM can break, and DMARC fails. ARC (RFC 8617) lets each intermediary record what the authentication results were when it received the message, then seal that record with a signature.

Each intermediary adds a set of three headers, numbered with i=1, i=2 and so on:

• ARC-Authentication-Results: the results that intermediary saw.
• ARC-Message-Signature: a DKIM-like signature over the message.
• ARC-Seal: a signature over the ARC headers, with cv= (chain validation) set to none, pass or fail.

ARC is an Experimental RFC. A receiver only uses it if it trusts the sealer. In Microsoft 365, admins can add trusted ARC sealers, which is how compauth reason 130 happens.

Return-Path and Message-ID

Return-Path is added by the server that makes final delivery. It records the envelope sender (the SMTP MAIL FROM address), which is where bounces go (RFC 5321, section 4.4). It's often different from From. Mailing platforms usually use their own bounce domain, which is normal. A Return-Path on a domain with no connection to the From domain, combined with failing DKIM, is a stronger warning sign.

Message-ID is a unique identifier the sending system creates. RFC 5322 says every message should have one. The part after the @ often hints at the system that created it. It's useful for searching logs and message traces, but it's written by the sender, so it proves nothing on its own.

How to read Microsoft 365 anti-spam headers

Microsoft 365 adds two headers to every inbound message. Microsoft Learn documents the useful fields:

Every SFV and CAT value, plus the compauth reason codes, is listed in Microsoft 365 spam headers explained.

If CIP shows your gateway's IP rather than the original sender's, Microsoft is judging the gateway, not the sender. That's what Enhanced Filtering for Connectors fixes.

A five-minute header check

1. Copy the full headers using the steps above.
2. Paste them into the Email Header Analyzer to lay out the hops and results.
3. Find the first Received line written by a server you trust. Note the connecting IP.
4. Read the Authentication-Results from your own system. Check spf, dkim and dmarc, and compare smtp.mailfrom, header.d and header.from.
5. If you use Microsoft 365, read CAT, SFV and compauth to see what the filter decided and why.
6. Note anything that doesn't fit: a lookalike domain in From, a Reply-To on a different domain, a failed DMARC check, or an unusual route.

What do common header warning signs mean?

If the message is suspicious, the patterns in what is email spoofing will help you decide what it is.

Next steps

• Practice on a message you know is legitimate, so you recognize your own normal path.
• Bookmark the Email Header Analyzer. It runs in your browser, so nothing is uploaded.
• If legitimate mail keeps landing in junk, work through why did this email land in spam.
• If you use a filtering service such as iBlockSpam, its Received line will appear between the sender and your mailbox. Knowing its host names makes the handover point easy to find.

Browse more guides on running email day to day.