9 Steps to Analyze Email Header Information

What an Email Header Contains

An email header is the metadata attached to every message you send or receive: routing information, timestamps, authentication results, and sender identification. It records who sent the message, when, which mail servers handled it along the way, and whether it passed the security checks the receiving server ran.

Headers come in two parts. The visible ones (From, To, Subject, Date) appear in every mail client. The full headers, which carry the routing and authentication data, stay hidden until you ask for them.

Header analysis is the fastest route to a deliverability diagnosis. If your mail keeps landing in spam, the header usually identifies which link in the chain broke, and that is more useful than guessing at subject lines.

How to View Full Email Headers in Gmail and Outlook

Both clients hide the raw header behind a menu, and each one labels it differently. Gmail calls it "Show original." Outlook calls it "Internet headers" in the desktop client and "message source" on the web, and the exact menu path shifts between releases.

Viewing headers in Gmail

Open the email you want to inspect. Click the three dots menu (more actions) in the top right corner of the message, then select "Show original." A new tab opens with the complete raw source, headers and body together.

That raw view contains every header field and the full routing path. Select it, copy it, and paste it into an analyzer tool or a text editor.

Viewing headers in Outlook

Open the message, click the "File" tab, and select "Properties." Some versions put it under "Info" instead. The dialog that opens includes an Internet headers section, and you will need to scroll inside that box to see all of it.

In Outlook on the web, click the three dots menu next to the message and choose "View message details" or "View message source." The headers appear in a new panel or window.

Copy the text with Ctrl+C, or Cmd+C on a Mac.

Understanding Email Header Fields Explained

Email headers follow RFC 5322, the Internet message format standard. Each field does a specific job in routing or authentication.

The From field identifies the sender, To lists recipients, Date records when the message was sent in a standardized format, and Subject holds the subject line. These are the four you already see in your inbox.

The Message-ID is a unique identifier assigned to each message. Received is the field that matters most for tracing delivery. Every mail server that handles the message adds its own Received entry, and the resulting chain maps the message's path from sender to recipient.

The Return-Path field says where bounce messages go when delivery fails. Reply-To tells email clients where to send replies, which is sometimes a different address than the one in From.

The Authentication-Results field carries the SPF, DKIM, and DMARC results, which record whether the message passed the checks that verify the sender's identity and domain ownership.

How to Read the Received Fields and Trace Delivery

The Received fields form a chain showing each step the message took. Read them from the bottom up, because the bottom entry is the first mail server that accepted the message and the top entry is the last one that touched it.

Each Received entry contains:

• The mail server that handled the message
• The IP address of that server
• The timestamp when it was processed
• The next server in the chain

Compare the timestamps as you go. A large gap between two entries means the message sat in a queue at that server. Entries clustered within a second or two mean it moved straight through without holdups.

The top Received entry shows when the message reached the recipient's mail server.

An SPF check shows up in the Authentication-Results line as spf=pass or spf=fail, and many servers also add a separate Received-SPF line. Our guide to configuring DKIM for custom domains explains where the DKIM signals in these headers originate. A failed SPF or DKIM check means the sender's domain did not verify, and that is among the most common reasons a message ends up in the spam folder.

Detecting Email Header Spoofing

Email spoofing is when someone forges the From address to impersonate another sender. The header can't stop that, but the receiving server's checks usually expose it.

Start with the dmarc= result in the Authentication-Results line. DMARC passes only when SPF or DKIM passes for the same domain shown in the From address. A forged message can pass SPF for the spammer's own domain, but it can't pass for the domain it pretends to be, so dmarc=fail is the clearest sign of a spoof. Our walkthrough on setting up DMARC for a small business covers how a DMARC policy tells receivers to quarantine or reject those messages.

Don't treat a different domain in the Received chain or the Return-Path as proof on its own. Most legitimate mail goes out through Google, Microsoft or an email service provider, so the first server and the bounce address often belong to them. A mismatch is worth a second look when DMARC also fails or the domain doesn't publish a DMARC record at all.

Phishing relies on the From line alone. The message looks like it came from your bank or a vendor you work with every week, and the headers are where that claim falls apart.

Interpreting Email Authentication Results in Email Headers

The receiving server writes its authentication verdicts into one Authentication-Results field, as spf=, dkim= and dmarc= entries. Gmail's "Show original" also lists them in a summary table above the raw text.

SPF (Sender Policy Framework) checks whether the mail server sending the message is authorized by the sender's domain. If the server appears in the domain's SPF record, the check passes. If it does not, you get a fail.

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to the message, which proves the message came from the domain and arrived unaltered. The check passes when the signature validates against the key published in DNS. Missing, broken, or mismatched signatures all produce a fail.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) sits on top of the other two. It requires that the domain SPF or DKIM authenticated match the domain in the From address, and it tells receiving mail servers what to do when neither does.

Our 2026 guide to email authentication and inbox placement goes further into how alignment between these three shapes what you see in the headers.

Any failed check raises the odds of a spam flag, since receiving servers use these results to decide between the inbox and the spam folder. One mistyped DNS record is enough to put a whole campaign on the wrong side of that decision.

Using an Email Header Analyzer Tool

Email header analyzer tools parse raw headers and lay the information out in a readable format. They pull the key fields, flag the authentication results, and render the delivery path as a timeline.

To use an analyzer:

1. Copy the full raw email header from your email client
2. Visit an email header analyzer website
3. Paste the header text into the input field
4. Click "Analyze" or "Parse"

The tool shows you the sender, recipient, subject, date, and authentication results, plus the delivery path with timestamps and mail server details. Most of them call out failed authentication or unexpected routing.

Some analyzers add IP geolocation for each server in the chain, which helps when a message has passed through infrastructure that has no connection to the sender. I still skim the raw text before I load an analyzer, mostly because the summarized views tend to drop fields I want to read for myself.

Free analyzers are easy to find online, and many email service providers build header analysis into their dashboards. For your own domain, the free deliverability scan checks the SPF, DKIM and DMARC records behind these results, and SEMAOS's DMARC monitoring shows which servers send as your domain and which of them fail.

Common Header Analysis Mistakes and Privacy Considerations

Reading a failed SPF or DKIM check as proof of spoofing is a mistake. Legitimate mail fails these checks for ordinary reasons: a misconfigured DNS record, a mail server set up without the right entries, or a forwarding server that resends the message from an address the original domain never authorized. Look at the full context before you call a message fraudulent.

Another mistake is reading the Received fields top to bottom. Do that and the delivery path comes out reversed, which makes a normal route look suspicious and a suspicious one look normal. Start at the bottom.

Treat raw headers as sensitive. They contain IP addresses, internal mail server names, and sometimes personal information. If you need help with a delivery problem, send them to your email service provider or a security professional you already work with, not to a public forum.

Be careful with headers from suspicious messages. Do not click links or open attachments in an email you believe is a phishing attempt, even when you opened it only to read the headers.

Headers themselves are plain text and execute nothing, so viewing them carries no risk. The body of the message is a different matter, so isolate anything suspicious before you start working with it.

When you bring a deliverability problem to your provider, include the full raw header, the send time, and the recipient address. That gives the support team enough to locate the exact point where delivery failed.

FAQ