Email Header Analyzer - Decode Headers & Check for Scam Emails

Paste email headers to trace the complete delivery path, verify SPF/DKIM/DMARC authentication, identify the originating IP, and see whether the message shows signs of a scam.

Copy and paste the full email headers from your email client.

Understanding Email Headers

Email headers are like the digital envelope of an email, containing crucial metadata about its journey from sender to recipient. They are not usually visible in standard email clients but can be accessed via "Show Original" or "View Source" options.

Key Information in Headers:

  • From/To/Cc/Bcc: Sender and recipient addresses.
  • Subject: The email's subject line.
  • Date: When the email was sent.
  • Message-ID: A unique identifier for the email message.
  • Received: A series of entries tracing the path the email took through various mail servers. Each "Received" header is added by a server that handled the email. Analyzing these can help identify the origin and route.
  • Return-Path: The address where bounce messages are sent.
  • Authentication-Results: Contains results of security checks like SPF, DKIM, and DMARC, which help verify the sender's authenticity and prevent spoofing.
  • MIME-Version & Content-Type: Define the email's format (e.g., HTML, plain text) and character encoding.

Email Authentication Explained

Why Analyze Email Headers?

  • Troubleshooting Delivery Issues: Identify where an email got delayed or rejected.
  • Detecting Phishing & Spoofing: Uncover forged sender information or suspicious routing by scrutinizing authentication results and the received path.
  • Spam Investigation: Determine the true origin of spam emails.
  • Learning Email Flow: Understand the technical journey of an email.

Common Issues Identified Through Header Analysis

  • Sender Spoofing: Mismatch between the "From" address and actual sending server
  • Missing or Failed Authentication: Emails without SPF, DKIM or with failed validation
  • Suspicious Routing: Email taking unusual paths through unexpected or known-problematic servers
  • Time Anomalies: Unusual delays between server hops that may indicate issues
  • X-Headers Anomalies: Custom headers sometimes reveal information about spam filtering or other processing

Is this email a scam? How to check the headers

Every message carries a block of headers your mail app hides from you. They record which server actually sent it, whether the sending domain approved that server, and where a reply would really go. A scam has to forge all three, and it usually gets at least one of them wrong.

Paste the full header block into the box above and the scam email checker reads it for you. The Security Assessment card returns a scam risk of Low, Medium or High, lists what triggered it, and says what to do next. Your headers are analysed on the server for that one request and are never stored.

Five signs it looks for:

  • Authentication failures. SPF, DKIM and DMARC are the sending domain's own way of saying "this server speaks for us". A fail means it did not.
  • A From address that does not match the envelope. The address you see and the address bounces go back to should belong to the same company. Forged mail often splits them.
  • A Reply-To pointing somewhere else. You answer what looks like the brand, and your answer lands in a stranger's inbox.
  • A brand name in front of a webmail address. "PayPal Support" writing from a gmail.com account is not PayPal. Large companies send from their own domain.
  • A delivery chain with holes in it. Servers that announce themselves as a bare IP or as "unknown", or hops carrying no timestamp, mean part of the route was written by hand.

Legitimate mail from a large company looks the opposite way round. SPF, DKIM and DMARC all pass, the From domain matches both the DKIM signing domain and the bounce address, any Reply-To stays on that same domain, and every server in the chain names itself and stamps a time.

If you are asking "is this email a scam" because it wants a password, a payment or an urgent decision, stop before you click anything. Open the company's website or app yourself, the way you normally would, and check your account there. If the warning in the email is real it will be waiting for you. Then report the message as phishing in your mail app and delete it.

A scam email checker that reads headers has limits worth knowing. It cannot open attachments or follow the links in the message body, so a Low result means nothing in the routing looks wrong, not that the message is safe.

How to trace an email to its sender's IP address

Every mail server that touches a message stamps a Received line on top of the ones before it. Read that stack from the bottom up and you get the route the message took, starting with the machine that first accepted it.

  1. Copy the raw headers. Open the message, pick your mail app's raw or original view, then copy the whole block from the first Received or Return-Path line down to the Subject line.
  2. Paste it above and run the analyzer. The Routing Path view rebuilds the chain in the order it happened, so row 1 is the oldest hop and the last row is your own mailbox.
  3. Read row 1. It carries the hostname and IP of the server that handed the message to the internet. When you trace an email, that address is as close to the origin as the headers can take you.
  4. Check the address and the authentication. Run the IP through our IP Lookup to see who owns the network, then open the Authentication view. SPF, DKIM and DMARC tell you whether the sending domain approved that server at all.

How to find the full email headers

Mail apps hide headers behind a menu item with a different name in every product. Use the one that matches yours, then paste the result into the box above.

What a header trace can and cannot prove

A sender can forge the lower Received lines before a message ever leaves their machine, so trust only the hops your own mail provider added at the top of the chain. Anyone writing from Gmail, Outlook.com or another webmail service also hands you the provider's outbound server IP rather than the computer they typed on, which is why a trace email lookup usually ends at a data center instead of a home address.

Example headers

A short chain looks like this. The Received lines wrap onto continuation lines that start with a space or tab, and the analyzer joins them back together before it reads them.

Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53])
	by mx.example.com (Postfix) with ESMTPS id 8DBCF21478
	for <[email protected]>; Wed, 21 Jul 2021 14:22:01 -0700 (PDT)
Authentication-Results: example.com;
	dkim=pass [email protected];
	spf=pass (example.com: domain of [email protected] designates 209.85.221.53 as permitted sender) [email protected];
	dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com
From: "Sender Name" <[email protected]>
To: "Recipient Name" <[email protected]>
Subject: Example Email with Headers
Date: Wed, 21 Jul 2021 14:22:00 -0700
Message-ID: <[email protected]>

Related Tools

Frequently Asked Questions

What information is in email headers?
Email headers contain: sender/recipient addresses, routing path (servers that handled the email), timestamps, SPF/DKIM/DMARC authentication results, message ID, and client software details.
How can I tell if an email is spoofed?
Check: SPF/DKIM/DMARC authentication (should pass), 'Received' headers for suspicious servers, Return-Path vs From address, and whether routing makes geographic sense.
What do the 'Received' headers mean?
Each 'Received' header represents a mail server that processed the email. Read bottom-to-top to see the path from sender to recipient. Unexpected servers may indicate relay abuse.
What are SPF, DKIM, and DMARC?
SPF verifies sender IP is authorized. DKIM cryptographically signs messages proving they weren't altered. DMARC builds on both, specifying what to do with authentication failures.
Can I trust the From address?
No, From addresses can be easily spoofed. Check authentication results (SPF/DKIM/DMARC pass), Return-Path, and Received headers. Don't trust display names - check actual email addresses.
Why does email show a different time than it was sent?
Timestamps in headers use the sending server's timezone. Your email client converts to your local time. Time discrepancies can also indicate spoofing or compromised servers.
How can I tell if an email is a scam from its headers?
The headers record which server actually sent the message, whether the sending domain approved that server, and where a reply would really go. Paste them into the analyzer and it returns a scam risk of Low, Medium or High with the reasons behind it. The strongest signals are an SPF, DKIM or DMARC failure, a Reply-To on a different domain to the From address, and a big-brand name in front of a free webmail address.
The email says it is from PayPal but the checker flagged it. Why?
Look at the address, not the name. Anyone can put "PayPal Support" in the sender name, but only PayPal can send from paypal.com and pass PayPal's own SPF and DKIM records. When the name says one company and the address is a gmail.com or outlook.com account, or any domain that is not theirs, that is impersonation. Open the company's app or website yourself and check your account there rather than clicking anything in the email.
The scam risk came back Low. Does that mean the email is safe?
No. A header check can only tell you the message came from where it claims to and travelled a normal route. It cannot open the attachment or follow the links in the body, and a real account that has been broken into will pass every authentication check. Treat Low as "the routing looks normal", then still judge what the message is asking you to do.
Last reviewed: Reviewed by the

How this tool works: This tool runs in your browser and on our server in real time. Depending on the tool, results are computed directly from the input you provide or retrieved from live, authoritative data sources at the moment you run a lookup. We do not sell your data, and your lookups are kept private — any history shown here is stored only on your device.