Paste your email headers below to see the complete delivery path, authentication results, hop-by-hop delay analysis, and spam indicators. Everything runs in your browser — nothing leaves your machine.
To get headers: Gmail → Open email → Three dots → Show original. Outlook → Open email → File → Properties → Internet Headers
Email headers are hidden metadata attached to every email message you send or receive. They contain the complete story of that email: who sent it, what servers handled it, whether it passed authentication checks, what spam filters thought about it, and exactly when each step happened.
Think of email headers like the shipping label and tracking history on a physical package. The label tells you who sent it and where it is going. The tracking history shows you every warehouse and truck it passed through, when it arrived at each stop, and whether anyone opened or inspected it along the way.
Your email client hides all of this information by default. When you open an email in Gmail or Outlook, you see the clean version: the sender name, subject line, date, and body text. But behind that simple display sits a block of structured data that can be dozens or even hundreds of lines long, recording every technical detail of the email's journey.
For most people, email headers are invisible and irrelevant. But if you're an email marketer, a deliverability specialist, an IT admin, or anyone trying to figure out why an email landed in spam, bounced, or arrived late, email headers are the single most useful diagnostic tool available. They tell you exactly what happened and where things went wrong.
Our email header analyzer above parses all of this automatically. Paste your headers in and it will extract, organize, and visualize every piece of information so you don't have to read raw header text line by line.
Every email client buries headers in a different place. Here's exactly how to find them in the most popular clients so you can paste them into the analyzer above.
The Authentication-Results header is the single most important header for diagnosing deliverability problems. It is added by the receiving mail server and contains the verdicts for SPF, DKIM, and DMARC checks. Here is what each result means and what to do about it.
SPF checks whether the sending server's IP address is authorized to send email for the domain listed in the Return-Path. The receiving server queries the sending domain's DNS for a TXT record starting with v=spf1 and compares the sending IP against the authorized list.
IP is authorized
IP is not authorized
IP not listed, soft policy
No assertion made
If SPF fails or softfails, verify that the sending server's IP is included in your SPF record. Check your SPF record with our free SPF Checker.
DKIM verifies that the email was cryptographically signed by the claimed domain and was not modified in transit. The receiving server uses the s= (selector) and d= (domain) values from the DKIM-Signature header to look up the public key in DNS and validate the signature.
Signature verified
Signature invalid or tampered
No DKIM signature found
When DKIM fails, check the d= (domain) and s= (selector) values, then verify the DNS record contains the correct public key. Verify your DKIM configuration with our free tool.
DMARC ties SPF and DKIM together with domain alignment. It requires that at least one of SPF or DKIM passes AND that the authenticated domain aligns with the domain in the visible From header. The DMARC policy tells receiving servers what to do when alignment fails: none (monitor), quarantine (spam), or reject (bounce).
Authentication + alignment OK
No aligned authentication
No DMARC record published
If DMARC fails, check whether your SPF and DKIM domains align with your From domain. Validate your DMARC policy to review your alignment and reporting settings.
The Received headers form the backbone of email header analysis. Every mail server that handles your email prepends its own Received header, creating a reverse-chronological log of every hop the message took from sender to recipient. Reading this chain tells you exactly where your email went, how long it spent at each stop, and where problems occurred.
The key rule: Received headers are listed in reverse order. The header at the very bottom of the chain is the first server that handled the email (the origin). The header at the top is the last server (the one that delivered it to your inbox). Read from bottom to top to follow the chronological path.
Received: from mail-sender.example.com (198.51.100.42) by mx.recipient.com with ESMTPS; Tue, 08 Apr 2025 14:23:17 -0400from — The server that sent the message to this hop. Usually includes the hostname and sometimes the IP address.
by — The server that received the message at this hop. This is the server writing the Received header.
with — The protocol used for the transfer (SMTP, ESMTP, ESMTPS for encrypted, etc.).
timestamp — The date and time when this server received the message. Used to calculate delay between hops.
By comparing the timestamps between consecutive Received headers, you can calculate exactly how long the email spent at each hop. Our analyzer does this automatically and flags any delays:
< 5s
Normal
Standard processing time
5-30s
Slow
Possible greylisting or filtering
> 30s
Delayed
Queuing, greylisting, or server issues
Email headers contain dozens of fields. Some are standard and appear in every email. Others are added by specific servers, spam filters, or sending platforms. Here are the most important ones and what they actually tell you.
This is the most confusing part of email headers for most people. There are actually multiple "sender" fields, and they can all be different:
From:The visible sender address shown to the recipient. This is what you see in your inbox. It can be set to anything by the sender and is not verified on its own — which is exactly why SPF, DKIM, and DMARC exist.Return-Path:The envelope sender, also called the bounce address. This is set during the SMTP transaction and is where non-delivery reports (bounces) are sent. SPF checks the sending IP against this domain, not the From domain.Reply-To:An optional field that tells email clients where to send replies. Often used by marketing platforms so replies go to a human inbox rather than the system that sent the email.When the From domain and Return-Path domain don't match, DMARC requires "relaxed" or "strict" alignment to pass. Mismatched sender addresses from completely unrelated domains are a red flag for phishing.
Message-ID:A globally unique identifier assigned to the email by the originating server. Formatted as a string like <random@domain.com>. Useful for tracking a specific message across logs, support tickets, and delivery systems. Duplicate Message-IDs from the same source suggest loops or re-sends.
Content-Type:Specifies the MIME type of the email body: text/plain for simple text, text/html for HTML emails, or multipart/alternative for emails containing both. Also includes the character encoding (charset) and, for multipart messages, the boundary string separating each part.
X-Mailer / User-Agent:Identifies the software that created the email. Can reveal whether a message came from Outlook, Thunderbird, Apple Mail, a marketing platform like Mailchimp, or a custom script. Useful for identifying the source of suspicious emails.
DKIM-Signature:Contains the cryptographic signature that proves the email was sent by the claimed domain. Key fields: d= (signing domain), s= (selector for DNS key lookup), b= (the signature itself), bh= (body hash). If d= does not match the From domain, DMARC alignment may fail.
X-Spam-Status:Added by spam filtering software like SpamAssassin. Contains the overall verdict (Yes/No), the total score, the threshold for spam classification, and a list of every individual test that was run with its score contribution.
X-Originating-IP:Added by some webmail providers (notably Outlook.com/Hotmail). Shows the actual IP address of the person who composed and sent the email, as opposed to the mail server IP. Can be used to geolocate the sender.
Email headers are your best diagnostic tool when emails land in spam, bounce, arrive late, or disappear entirely. Here is a systematic approach to using header analysis for troubleshooting common deliverability problems.
The most common cause of spam placement. Check the Authentication-Results header for SPF, DKIM, and DMARC verdicts. If any of them show "fail," that is almost certainly why the email was flagged.
Look for X-Spam-Status or X-Spam-Score headers. SpamAssassin scores above 5.0 typically result in spam classification. The header will list every individual test that contributed to the score, telling you exactly what to fix.
Common spam triggers visible in headers include: missing authentication (NO_SPF, NO_DKIM), HTML-only content with no text alternative (HTML_ONLY), URL shorteners (SHORTENED_URL), and excessive capitalization or spam phrases in the subject line.
If emails arrive late, the Received chain tells you exactly where the delay happened. Compare timestamps between consecutive hops to find the bottleneck. Common culprits:
Sometimes authentication passes but emails still land in spam. The headers may contain clues: look for X-Spam-Status entries mentioning RCVD_IN_SORBS, RCVD_IN_XBL, RCVD_IN_PBL, or similar blacklist test names. These indicate the sending IP appears on one or more reputation blacklists.
Extract the sending IP from the first Received header (or X-Originating-IP) and check if your domain is on any blacklists using our free tool.
Email headers are hidden metadata included in every email message. They contain the sender and recipient information, the delivery path (every server the email passed through), authentication results (SPF, DKIM, DMARC), timestamps, spam filter verdicts, and technical details about how the message was formatted and transmitted. Headers are automatically added by each mail server that handles the message and are normally hidden from view by email clients.
Open the email in Gmail, click the three vertical dots (More) in the upper-right corner of the message, and select "Show original." This opens a new tab with the complete email source, including all headers. You can click "Copy to clipboard" to copy the entire source, then paste it into this email header analyzer.
In the Outlook desktop app, open the email in its own window (double-click it), go to File, then Properties, and look for the "Internet headers" text box. In Outlook on the web (OWA), open the message, click the three dots (More actions), and select "View message source" or "View message details."
The Authentication-Results header is added by the receiving mail server and contains the results of SPF, DKIM, and DMARC checks. It tells you whether the sending server was authorized (SPF), whether the message was properly signed and unmodified (DKIM), and whether the overall authentication policy passed (DMARC). This is the single most important header for diagnosing deliverability problems.
Partially. The From header can be set to anything by the sender, which is exactly what spoofing and phishing emails do. However, Received headers added by intermediate and receiving servers cannot be faked by the original sender. Authentication results added by the receiving server are also reliable. This is why SPF, DKIM, and DMARC exist: they verify the legitimacy of the sender so you do not have to rely on easily forged fields.
The most common causes, all visible in email headers, are: authentication failures (SPF, DKIM, or DMARC not passing), high spam scores from content filters, blacklisted sending IP addresses, and poor sender reputation. Paste your email headers into the analyzer above to check authentication results, spam scores, and sending IP details.
Look at the bottom-most Received header (the first hop in the delivery chain). The IP address after "from" is typically the originating server's IP. Some webmail providers also add an X-Originating-IP header that shows the actual IP of the person who composed the email, rather than the mail server.
The From header is the visible sender address shown to the recipient. It can be set to anything. The Return-Path (envelope sender) is set during the SMTP transaction and is where bounce notifications are delivered. SPF checks are performed against the Return-Path domain, not the From domain. For DMARC to pass via SPF, the Return-Path domain must align with the From domain.
Now that you have analyzed your email headers, use these tools to check and fix the issues you found:
ScaledMail configures SPF, DKIM, and DMARC correctly for every inbox from day one. Dedicated IPs, clean reputations, and proper authentication out of the box — so you never have to dig through email headers wondering what went wrong.
Get Started with ScaledMail