Email Header Forensics: How to Read a Suspicious Email

Email headers are the metadata behind every message. They are usually invisible to the user, but they contain the forensic evidence that distinguishes legitimate mail from fraud. This post is a practical guide for reading headers when you need to evaluate a suspicious email.

What Headers Are

Every email consists of two parts: the body (the message you read) and the headers (the metadata). Headers are added by every mail server in the delivery chain. They include:

• The visible From, To, Subject, and Date.
• The technical envelope sender (Return-Path).
• The path the email took through mail servers (Received chain).
• Authentication results from the receiving server.
• Routing identifiers, message IDs, and various forensic metadata.

The visible From is what you see in your mail client. The technical envelope can differ. Most fraud exploits the gap between the visible From and the technical envelope.

How to View Headers

The procedures vary by client.

Gmail. Open the message. Click the three-dot menu in the upper right of the message. Select “Show original.” A new tab opens with the full headers and body, plus a parsed summary at the top showing key forensic data.

Outlook desktop. Open the message in its own window. Go to File > Properties. The Internet Headers field shows the full headers.

Outlook web (Outlook.com or Microsoft 365). Open the message. Click the three-dot menu inside the message. Select “View message source.” The full source including headers opens.

Apple Mail. Open the message. Go to View > Message > All Headers (or Raw Source).

For other clients, search for “view email source” or “view email headers” in the client documentation.

Key Headers to Read

The headers that matter most for fraud detection.

The Received chain. A series of headers, one added by each mail server in the delivery path. Each Received header has a “from” hostname and IP, a “by” receiving server, and a timestamp. The chain traces the email’s path from the original sender to your inbox.

The most useful Received header is usually the bottom one (the original sender’s claim about itself) and the second-from-top (the last hop before your provider). Discrepancies in the chain (a hop in an unexpected country, a relay service known to be used by spammers) are signals.

Each receiving server adds its own Received header. Once added, headers cannot be retroactively forged because the sender does not control the receiving servers. The chain is forensically reliable in a way that other headers are not.

Authentication-Results. Added by your receiving mail server. Records the outcomes of SPF, DKIM, and DMARC checks. Examples:

• “spf=pass” means the sender’s IP is authorized to send for the claimed domain.
• “dkim=pass” means the cryptographic signature on the message validates against the claimed sender’s public key.
• “dmarc=pass” means the alignment between SPF, DKIM, and the visible From matches the sender domain’s policy.

A message that fails any of these checks is suspicious. A message that passes all three is authenticated to come from the claimed domain (but not necessarily a legitimate one; lookalike domains pass all three from their own infrastructure). We covered the limits in what is DMARC, DKIM, and SPF.

Return-Path or envelope-sender. The address used by mail servers for bounce handling. Often the same as the visible From for legitimate mail. For fraud, the Return-Path frequently differs from the visible From, indicating that the message came through a sending platform separate from the claimed source.

X-Originating-IP. When present, identifies the IP address of the original sender. Useful for confirming whether the message came from the claimed source.

Message-ID. A unique identifier for the message. Useful for forensic correlation but not directly for fraud detection.

X-Mailer or User-Agent. Identifies the email client that sent the message. Sometimes reveals automation tools used by spam senders.

A Practical Reading Workflow

When you receive a suspicious email and want to assess it:

Step one: check the visible From and Reply-To. Are they the same? If they differ, that is a strong signal of fraud. Some legitimate cases (mailing lists, automated systems) have legitimate reasons for different addresses, but always investigate.

Step two: open the original headers. Use the procedure for your client.

Step three: read the Authentication-Results. SPF, DKIM, and DMARC outcomes. Any failure is suspicious. All passes mean the message came from the claimed domain (legitimate or lookalike).

Step four: read the Received chain. Trace the path from bottom to top. Look for unexpected hops (countries you do not do business with, mail relay services, anonymizing services). The original sending IP at the bottom of the chain is the strongest signal of where the mail actually came from.

Step five: check the Return-Path. Does it match the visible From? If not, the message came through a sending infrastructure that is separate from the claimed source.

Step six: cross-reference with other clues. Lookalike domain in the From? Mismatched display name? Unusual Reply-To? The header analysis combines with the visible signals to produce a confident assessment.

Step seven: report. If the assessment is fraud, report to the relevant party (your IT team, your email provider’s phishing-report mechanism, the impersonated organization, the FBI’s IC3 if losses occurred).

What Header Analysis Cannot Prove

Header analysis is forensic. It tells you what happened. It does not always tell you whether what happened was fraudulent.

Authenticated lookalike domains. A lookalike domain that has its own DKIM, SPF, and DMARC records will pass all three authentication checks. The headers prove the mail came from the lookalike domain; they do not prove the lookalike domain is unauthorized to impersonate the legitimate one. We covered this at the lookalike domain problem.

Compromised legitimate accounts. When an attacker compromises a real sender’s account and sends from inside, the headers correctly identify the sender as legitimate. The attack is downstream of identity. Headers do not catch this.

Header forgery in legacy mail flows. Older mail systems can be tricked by forged headers in some configurations. Modern systems have largely closed these gaps but the residual exists.

Encryption and gateway products that obscure headers. Some email security gateways rewrite headers in ways that complicate analysis. The headers a recipient sees may differ from the headers the original sender sent.

Header analysis is a confirmation tool, not a definitive answer. Combined with other evidence, it produces a reliable assessment in most cases.

Why Most Users Should Not Be Doing This Routinely

Header analysis is forensic. It works after the email has arrived. It assumes the user has the time, expertise, and motivation to read headers on suspicious messages.

For most users, the workflow is impractical at scale. The realistic interactions:

• Critical messages (wire transfers, sensitive requests, suspicious flags) get header analysis when the stakes justify the effort.
• Routine messages do not. Most users will never read headers on most mail.
• Suspicious messages get reported to a security function (if one exists) or to the email provider’s phishing-report flow.

The structural defenses (filtering, MFA, verification protocols) are what scale to the volume problem because they do not require per-message human attention. Header analysis is the high-precision tool for the small fraction of messages that warrant it.

How Rythm Composes With Header Analysis

Rythm sits at the inbox layer and reduces the volume of unsolicited mail reaching the user. The composition with header analysis:

Less volume to triage. The cover charge gate reduces the volume of unsolicited mail. The user has more attention bandwidth for the messages that do arrive, including the suspicious ones that warrant header analysis.

Held-for-review folder is the natural triage queue. Messages that did not pay the cover charge wait in a separate folder. The user can choose to apply header analysis to messages in this folder before deciding to rescue them or leave them. The held folder is much smaller than the inbox would have been without the filter.

Targeted attacks still require analysis. A precision attack from a sender on the user’s guest list (or one willing to pay the cover charge) reaches the user. Header analysis is still the right tool for that case.

The combination: Rythm reduces volume; header analysis handles the high-precision cases that warrant the effort.

A Specific Honest Note

Email header analysis is a real skill that is genuinely useful for evaluating suspicious messages. We recommend learning it for the cases where stakes justify the effort.

What header analysis is not is a scalable defense for the volume problem. Most users cannot do this on every message, and the structural attacks (lookalike domains with their own authentication, compromised legitimate accounts) defeat the technique anyway. Structural defenses (filtering, MFA, verification protocols) are what hold against volume.

For the related guides, see the anatomy of a modern phishing email, the lookalike domain problem, what is DMARC, DKIM, and SPF, and vendor impersonation: the quiet phishing vector nobody talks about. For the broader frame, see why phishing emails are getting harder to spot in 2026 and what is BEC. Rythm is $1.65 per month, cancel anytime.