Gmail
In a web browser- Open the email in Gmail on the web.
- Next to Reply, click More (⋮).
- Click Show original. The headers open in a new tab.
- Click Copy to clipboard and paste here.
The Gmail app for Android and iPhone can’t show full headers.
Paste an email’s headers to see the route it took, how long each step took, what SPF, DKIM and DMARC reported, and what deserves a closer look.
Headers are a record of what each server wrote. Anyone who handled the message, including the sender, can add or edit lines, so this report shows what the headers say. It doesn’t verify signatures or prove who sent the email.
Three steps, about a minute. You need the full header text of the message, and every email app can show it.
In your email app, open the message and choose the option that shows the original message or its headers. Copy everything from the first line down to the first blank line. See the steps for your app.
Paste the text into the box at the top of this page and click Analyze headers. If you paste the whole message, only the headers are read and the body is ignored. Nothing leaves your browser.
Start with Worth a look, then check the reported SPF, DKIM and DMARC results and the delivery route. Before sending headers to anyone, use Copy or download report to hide addresses and IPs.
Look for “Show original”, “View message details”, “View source” or “Raw message”. Most phone apps can’t show headers, so use a computer when you can.
The Gmail app for Android and iPhone can’t show full headers.
Works the same in Outlook on the web.
Mail sent inside one Microsoft 365 organization may have only a few header lines.
View › Message › Raw Source also works and shows the complete original.
In AOL Mail, the option is called View Message Source.
To show more headers in the reading pane, use View › Headers › All.
It’s the block of technical lines at the top of every message. Your email app shows only From, To, Subject and Date, but the full header records every server that handled the message and what each one concluded.
Each server that passes the message on adds a Received line, so together they show the path from the sender to your inbox.
ReceivedEvery Received line has a timestamp. Comparing them shows where a message waited, even across time zones.
TimingThe receiving server writes down whether the message passed sender authentication, and who checked it.
Authentication-ResultsThe display name can say anything. The address, reply address and bounce address tell you more.
From · Reply-To · Return-PathMicrosoft 365, SpamAssassin and other filters leave scores and codes such as SCL, BCL, SFV and CAT.
X-Forefront-Antispam-ReportMessage IDs, unsubscribe links, the app that sent it and the X- lines your mail system added along the way.
All other fieldsThe fields you’ll see most often. Some are written by the sender and some by servers along the way, which matters when you decide how far to trust them.
| Field | What it tells you | Written by |
|---|---|---|
| From | The sender shown in your inbox: a display name and an address. Easy to fake on its own, which is why SPF, DKIM and DMARC exist. | Sender |
| Reply-To | Where replies go, if different from From. Common in newsletters, and also in invoice scams. | Sender |
| Return-Path | The envelope sender, where bounces go. SPF is checked against this domain. | Receiving server |
| To, Cc, Delivered-To | The listed recipients, and the mailbox the message was actually delivered to. | Sender, receiver |
| Date | When the sender’s app says the message was written. It comes from the sender’s clock, so it can be wrong. | Sender |
| Subject | The subject line. Non-English text is often encoded (=?UTF-8?…?=), and the analyzer decodes it. | Sender |
| Message-ID | A unique ID for the message, usually ending in the sending system’s domain. Useful when asking a provider to trace a message. | Sender’s system |
| Field | What it tells you | Written by |
|---|---|---|
| Received | One line per server hop: who handed the message over, who took it, the protocol, often TLS details, and a timestamp. The newest is at the top. | Each server |
| Authentication-Results | The receiving server’s verdict on SPF, DKIM, DMARC and sometimes ARC (RFC 8601). The one your own provider added is the one to trust. | Receiving server |
| Received-SPF | An older, SPF-only result line, including the sending IP that was checked. | Receiving server |
| DKIM-Signature | The cryptographic signature. d= is the signing domain and s= the selector used to look up its key. | Sending system |
| ARC-Seal, ARC-Authentication-Results | Added by forwarders and mailing lists to record the authentication results they saw before changing the message (RFC 8617). | Intermediaries |
| Field | What it tells you | Written by |
|---|---|---|
| List-Unsubscribe, List-Unsubscribe-Post | The unsubscribe link and email. List-Unsubscribe=One-Click means one-click unsubscribe, which Gmail and Yahoo require from bulk senders. | Sender |
| X-Forefront-Antispam-Report | Microsoft 365’s filter report: SCL (spam confidence), SFV (verdict), CAT (threat category), CIP (connecting IP) and more. | Microsoft |
| X-Microsoft-Antispam | Includes BCL, the bulk complaint level from 0 to 9. Higher means the sender’s bulk mail draws more complaints. | Microsoft |
| X-Spam-Status, X-Spam-Score | Verdicts and scores from SpamAssassin and similar filters. | Receiving filter |
| X-Originating-IP | Some webmail services record the IP of the device that sent the message. Many providers no longer add it, for privacy. | Sender’s provider |
When your provider receives a message, it checks the sender’s DNS records and writes the outcome into an Authentication-Results header. Here’s how to read one.
Authentication-Results: mx.inbox.example;
spf=pass smtp.mailfrom=bounce@mail.esp.example;
dkim=pass header.d=shop.example header.s=s2026;
dmarc=pass (p=QUARANTINE) header.from=shop.example
smtp.mailfrom)? It often breaks when mail is forwarded.header.d verify, proving the signed parts weren’t changed in transit?header.from)? This ties authentication to the sender you see.Each server adds its Received line at the top, so the newest hop comes first. To follow the message from the sender to you, read them from the bottom up.
Received: from out-24.mail.esp.example
(out-24.mail.esp.example [198.51.100.24])
by mx.inbox.example with ESMTPS id 5b1f17b18
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384);
Mon, 2 Nov 2026 01:14:08 -0800
The topmost Received lines come from your own provider and are the most trustworthy. Everything below was written by servers outside its control.
A delay of minutes or hours at one hop points to greylisting, retries or a busy server. Times that go backwards usually mean a server clock is wrong.
The earliest public IP is usually the sender’s mail server or provider, not their computer. Providers like Gmail don’t include the sender’s own IP at all.
Often, but not always. These are the header signs worth checking. Each has innocent explanations too, so judge them together with the message itself.
The display name says “PayPal Support” or even shows a real-looking address, but the actual From address is something else.
Compare the name with the address in angle brackets. The analyzer flags names that contain a different address.
The From address looks right, but Reply-To sends your answer to a different domain, often a free mailbox.
Before replying with payment details or documents, confirm the Reply-To domain belongs to the sender.
Your provider reported dmarc=fail: the message couldn’t prove it came from the domain in From.
Be careful with links and attachments unless you expected the message. Real senders sometimes fail after forwarding.
paypa1.com, micros0ft-support.com, or a name using letters from another alphabet (shown as xn-- in headers).
Read the domain letter by letter. A domain can pass every check and still be a fake.
Two From fields, or two Authentication-Results headers that disagree. Different apps may show different values.
Trust the authentication report your own provider added, normally the topmost one.
Times that go backwards, or a Date long after the first server timestamp.
Usually a wrong clock. Occasionally the lower part of the route was invented to look legitimate.
Honest limits, so you don’t read more into a report than it contains.
Headers identify domains and servers, not the person at the keyboard.
An IP usually belongs to a mail provider or data center, not the sender’s location.
Anything written before your provider received the message can be made up.
A clean report means no common warning signs, not that links or attachments are harmless.
It turns the raw header text of an email into a readable report: the servers the message passed through and the delay at each, the SPF, DKIM and DMARC results the receiving server recorded, who the message claims to be from and where replies go, spam filter verdicts, and anything unusual worth a closer look.
The analyzer runs entirely in your browser. The headers you paste aren’t uploaded, saved or sent to analytics, and they disappear when you close the page. Headers do contain email addresses, IP addresses and message IDs, so use the redaction options before you share a report with anyone.
Partly. The sender controls fields like From, Reply-To, Date and Subject, and can add made-up Received lines below the real ones. What they can’t easily fake are the lines your own provider adds when it receives the message, including its Authentication-Results. That’s why the analyzer separates what was reported from what is proven.
Sometimes you can find the IP of the server that sent the message: it’s in the earliest Received line with a public address. That’s usually the sender’s email provider, not their device, and big providers like Gmail and Outlook.com don’t include the user’s own IP. IP location shows where a server is registered, which says little about where a person is. This tool doesn’t look up IP locations.
DMARC passes when either SPF or DKIM passes for a domain that matches the From address. When a message is forwarded, the forwarding server isn’t in the original sender’s SPF record, so SPF fails, but the DKIM signature usually survives and DMARC still passes.
Every server that handles the message adds one: the sender’s app, the sending provider’s internal systems and outbound servers, then your provider’s gateway, filters and mailbox servers. Five to ten is normal for mail from a large service.
SCL is Microsoft’s spam confidence level: −1 means filtering was bypassed, 0 and 1 mean not spam, 5 and 6 mean spam, and 7 to 9 mean high-confidence spam. BCL, the bulk complaint level, runs from 0 (not bulk) to 9 (bulk mail with many complaints). Microsoft says SFV and CAT are the better signals for cloud mailboxes, and the analyzer explains those too.
Most phone apps, including the Gmail and Outlook apps, don’t show full headers. Open your webmail in a browser, preferably on a computer, and follow the steps for Gmail, Outlook or Yahoo on this page.
From is the sender you see. Return-Path is the envelope sender, where bounces go. They often differ when a company sends through a mailing service. SPF checks the Return-Path domain, and DMARC checks that it, or the DKIM domain, matches From.
Free, with no signup. They all run in your browser.
Atomic Mail encrypts your mail end to end, filters spam and phishing, and lets you hide your real address behind aliases. It’s free to start, and you don’t need a phone number to sign up.
Business
Free tools
Features
Compare
Learn
© 2026 Atomic Mail. All rights reserved.
AtomicMail Systems OÜ, Harju maakond, Tallinn, Kesklinna linnaosa, Harju tn 3 // Vana-Posti tn 2, 10146