PureTempMail

How to Spot a Phishing Email by Reading Its Headers

Read a suspicious email's headers line by line: From, Reply-To and Return-Path, the Received chain, and what SPF, DKIM and DMARC results really prove.

PureTempMail Team

The engineers who build and run PureTempMail

Short answer

Open the message source and check three things: whether DMARC passed for the domain in the From line, whether Reply-To points somewhere else, and whether the first Received line comes from the company's own servers. A failure on any of them is a strong warning. A pass on all three only proves who sent the email, not that the sender is honest.

Every email carries a block of headers above the text you read. Your mail app hides it, but it records which server the message came from, which domain vouched for it and where your reply would actually go. Phishing usually gives itself away there, even when the message itself looks perfect.

We run an inbound mail server, so raw headers are what we read whenever a message behaves strangely. This guide walks through a realistic phishing header block one line at a time, then shows the harder case where every check passes. You can paste any message's headers into our email header analyzer as you read along. It runs in your browser and the headers are never sent to our servers.

Step one: get the headers out of your mail app

Every mail client hides the headers by default. In Gmail, open the message, click the three-dot menu next to Reply and choose Show original. In Outlook on the web, open the three-dot menu, then View and View message source. In Apple Mail on a Mac, choose View, Message, All Headers. The header analyzer page lists the menu paths for Outlook for Windows, Yahoo and others.

Copy everything above the first blank line. That is the header block. The message body comes after it and is not needed. On iPhone and iPad the built-in Mail app does not show headers at all, so forward the message to a computer or check it in webmail.

A phishing email's headers, line by line

Here is the header block of a typical account-alert phish, trimmed to the lines that matter. The domains and addresses are fictional placeholders, but the pattern is the one we see over and over. Headers are stacked newest first, so the server that delivered the message to you is near the top and the place it started is lower down.

Return-Path: <[email protected]>
Authentication-Results: mx.example.com;
    spf=pass smtp.mailfrom=mail.example.net;
    dkim=none;
    dmarc=fail (p=none) header.from=examplebank.com
Received: from mail.example.net (unknown [203.0.113.45])
    by mx.example.com with ESMTPS; Thu, 29 Oct 2026 09:14:07 +0000
Received: from desktop-4kq2 (unknown [198.51.100.23])
    by mail.example.net with ESMTPA; Thu, 29 Oct 2026 09:14:05 +0000
From: "Example Bank Security" <[email protected]>
Reply-To: [email protected]
To: [email protected]
Subject: Unusual sign-in: confirm your account within 24 hours
Date: Thu, 29 Oct 2026 09:14:02 +0000
Message-ID: <20261029091402.4471@desktop-4kq2>
A shortened header block. Example Bank is fictional; examplebank.com is the real bank's domain in this scenario and example.net is the attacker's.

What each line tells you

Return-Path
The address bounces go to, also called the envelope sender. Here it is on mail.example.net, not the bank's domain. On its own this proves little, because newsletters sent through a mailing provider look the same. Keep it in mind for the next lines.
Authentication-Results
The verdict your provider recorded when the message arrived. SPF passed, but for mail.example.net, the attacker's server. There is no DKIM signature. DMARC, the only check that looks at the From domain you actually see, failed for examplebank.com. This is the single most useful line in the block.
Received (top)
Added by your own provider's server, mx.example.com, when it accepted the message from 203.0.113.45. Lines your provider writes are trustworthy. Everything below this point was written by machines you know nothing about.
Received (bottom)
The oldest hop, so read the chain from the bottom up. The message started on a machine calling itself desktop-4kq2 and was handed to mail.example.net with a logged-in submission (ESMTPA). A bank's alert system does not run on someone's desktop. A stolen or rented mailbox does.
From
The display name says Example Bank Security and the address claims examplebank.com. Anyone can type anything into this field. The DMARC failure above is the proof that this From line is forged.
Reply-To
If you hit Reply, your answer goes to example.org, a third domain. A bank that wants you to call or log in has no reason to collect replies on someone else's domain. Phishing that asks you to reply with details almost always sets this.
Subject and Date
Urgency plus a deadline. The Date is only what the sending machine claims, but compare it with the Received timestamps: a gap of hours or days between the Date and the first hop can mean the message sat in a spam queue before reaching you.
Message-ID
A unique ID that the sending software makes up. Large companies' systems stamp it with their own domain. This one ends in desktop-4kq2, the same home machine from the bottom Received line. A mismatch here is a hint, not proof, because plenty of legitimate software uses generic IDs.

Put together, the story is clear: a message claiming to be from the bank was sent from a desktop through a stranger's mail server, failed the bank's own authentication and wants your reply at a third domain. You can reach that conclusion in under a minute once you know where to look, and the header analyzer flags the DMARC failure and the Reply-To mismatch for you.

SPF, DKIM and DMARC explained in plain terms

These three checks are the part of the headers that a receiving server writes after testing the message, rather than text the sender typed. Each one answers a different question.

SPF
Is this server allowed to send mail for the envelope sender's domain? The domain owner publishes a list of permitted servers in DNS, and the receiver compares it with the connecting IP address. SPF checks the Return-Path domain, not the From address you see, which is why a phish can pass SPF for its own domain. See SPF in our glossary.
DKIM
Was the message signed by a domain, and has it been changed since? The sending server adds a cryptographic signature, and the receiver checks it against a public key in the signer's DNS. The header.d= value names the domain that signed. A valid signature from an unrelated domain says nothing about the brand in the From line.
DMARC
Does the domain in the From line match a domain that passed SPF or DKIM? This alignment step is what ties the checks to the name you actually read. DMARC also lets the domain owner tell receivers what to do with failures: nothing (p=none), quarantine or reject. That is why a forged message can still reach your inbox when the real company has not switched on enforcement.

What each result means

ResultWhat it meansHow worried to be
passThe check succeeded for the domain named next to it.Low, but read which domain passed. A pass for a lookalike domain is still a phish.
failThe domain's own rules say this message should not have come from where it did.High when it is DMARC for a brand you recognise.
softfailSPF only. The domain says the server is probably not allowed, but asks receivers not to reject outright.Medium. Common with forwarding and badly kept SPF records, suspicious alongside other flags.
neutralThe domain makes no statement either way about this server.Treat as no evidence.
noneNo record or signature existed to check.Medium for a large company, which would normally publish all three.
temperror / permerrorThe check could not run: a DNS timeout, or a broken record on the sender's side.Low on its own. Look at the other results.

The harder case: every check passes

Careful attackers do not forge a bank's domain at all. They register a similar one, set up SPF, DKIM and DMARC properly and send from it. The headers then look spotless:

Authentication-Results: mx.example.com;
    spf=pass smtp.mailfrom=examplebank-secure.com;
    dkim=pass header.d=examplebank-secure.com;
    dmarc=pass header.from=examplebank-secure.com
From: "Example Bank" <[email protected]>
All three checks pass, because the attacker owns examplebank-secure.com and configured it correctly.

Authentication proves that examplebank-secure.com sent this email. It cannot tell you whether that domain belongs to your bank. That part is your job, and it comes down to reading the domain itself very slowly. These are the tricks we see most:

  • Extra words. The real name plus -secure, -login, -support or -verify.
  • Swapped characters. rn in place of m, a zero for the letter o, a doubled or missing letter.
  • A different ending. The right name on .co, .net or a new top-level domain instead of the one the company uses.
  • The real name as a subdomain. In examplebank.com.account-check.net the domain is account-check.net. Read domains from the right.
  • Lookalike alphabets. A Cyrillic а looks identical to a Latin a. In the raw headers such domains often show up starting with xn--, which is how non-Latin domain names are encoded.
  • A display name doing the work. "Example Bank" in front of an address on a free webmail domain. Many phones show only the name, so tap it to see the address.

If you are unsure whether a domain belongs to the company, do not use anything in the email to find out. Type the company's address into your browser yourself and compare.

Red flags in email headers, ranked

Some signals are close to proof, others only count when they stack up. This is roughly how we weigh them.

SignalWhere to lookWeight
DMARC fails for a known brandAuthentication-Results, dmarc=fail header.from=Strong. The From line is very likely forged.
From domain is close to, but not exactly, the real oneFrom, and the header.from= valueStrong, even when everything passes.
Reply-To on a different domainReply-ToStrong when the message asks you to reply.
First hop is a home machine or an unrelated providerBottom Received lineMedium. Legitimate mail usually starts inside the company or its mailing provider.
No authentication results at allMissing Authentication-ResultsMedium for big brands, which publish SPF, DKIM and DMARC.
Message-ID domain unrelated to the senderMessage-IDWeak. Supporting evidence only.
Return-Path on a different domainReturn-PathWeak. Normal for newsletters sent through a mailing service.

A five-minute routine for any suspicious email

  1. Copy the full headers

    Use Show original or View source, as described above, and copy the whole block, including every Received line.

  2. Paste them into a header analyzer

    Our email header analyzer lays out the From, Reply-To and Return-Path side by side, shows the SPF, DKIM and DMARC results and lists the delivery route oldest first. The parsing happens in your browser.

  3. Check DMARC against the From domain

    Find dmarc= and the domain next to it. A fail for a brand you know is enough to stop here and delete the message.

  4. Read every domain slowly, from the right

    From, Reply-To and the domain that passed DKIM should all belong to the company. Watch for the lookalike tricks above.

  5. Read the Received chain from the bottom

    The lowest line is where the message began. Only trust the lines added by your own provider, at the top. A sender can insert fake Received lines and even a fake Authentication-Results line below them.

  6. Check the links without clicking

    Headers do not show the links in the body. On a computer, hover over each button and read the address in the corner of the window. Anything that does not lead to the company's real domain is a reason to leave.

If you think it is phishing

  • Do not click, reply or open attachments. Replying confirms your address is read, and attachments are the usual way malware arrives.
  • Contact the company another way. Type its address into your browser or use the number on your card or contract, never the one in the email.
  • Report it in your mail app. In Gmail, use the three-dot menu and Report phishing. In Outlook, use Report and then Report phishing. This trains the filter for everyone on that service.
  • Forward it to the Anti-Phishing Working Group at [email protected], which shares reports with security companies and browsers.
  • In the US, report it to the FTC at ReportFraud.ftc.gov, especially if money or personal details were involved.
  • If you already entered a password, change it now on the real site, turn on two-factor sign-in and change it anywhere else you reused it. Our guide to checking whether your email was in a data breach covers the first hour after an exposure.

The bottom line

To spot a phishing email from its headers, trust only what your own provider wrote, check that DMARC passed for the exact domain in the From line, and read that domain carefully enough to catch a lookalike. Those three habits catch most forged mail. For the rest, the safest move is the same as always: go to the company directly instead of through the email. Paste the next suspicious message into the header analyzer and see what it shows.

Sources