Can email headers reveal the sender's location?

Sometimes. If the message was sent from a personal mail server or an older desktop client, the first Received line or an X-Originating-IP header may contain the sender's own IP address, which gives an approximate location. Mail sent through Gmail, Outlook.com and similar services shows only the provider's servers, which reveals nothing about the individual.

Why does a message from a company I trust fail SPF or DKIM?

Common causes are forwarding (which changes the sending IP and breaks SPF), mailing lists that modify the body (which breaks DKIM), or the company adding a new sending service without updating its DNS records. A single failure is not proof of forgery, but a DMARC failure on a message asking you to act is reason to verify through another channel.

Are headers the same as the email source?

The source, or raw message, is everything: headers plus the body and any attachments encoded as text. The headers are the block at the top of the source, ending at the first blank line. Most clients let you view either.

Can attackers forge the Authentication-Results header?

They can include one in the message they send, but your receiving server adds its own, and a well-behaved server strips or ignores any that arrived with the message. Trust the Authentication-Results line whose first field names your own provider's server, and be wary if there are several.

What does 'ESMTPS' or 'TLS' in a Received line mean?

That the connection between those two servers was encrypted in transit. It protects the message from eavesdropping between hops, but it says nothing about who sent it or whether the content is safe. Nearly all mail between major providers is encrypted this way now.

How to Read Email Headers: Trace Where a Message Really Came From

The From line of an email is just text. Anyone can put any name and address there, which is why fraud by email is so easy. The headers above the message, hidden by every mail client, are different: they are written by the servers that handled the message, in order, and they record where it entered the mail system, which hops it took, and whether it passed the authentication checks that prove a domain really sent it. Reading them takes a few minutes to learn and is the most reliable way to decide whether a suspicious email is what it claims to be.

How to open the full headers

Gmail: open the message, click the three-dot menu next to Reply, choose "Show original". Gmail also shows a summary table at the top with SPF, DKIM and DMARC results.
Outlook (desktop): open the message in its own window, then File, Properties; the headers are in the "Internet headers" box. In Outlook on the web: three dots, View, "View message source".
Apple Mail: View, Message, "All Headers", or "Raw Source" for the whole thing.
Thunderbird: View, Message Source, or press Ctrl+U.
iPhone and Android apps generally do not expose headers; forward the message to a desktop client, or use the web version of your mail service.

You will see a block of lines in the form Name: value, often several dozen of them, with the newest at the top. Copy the whole block. You can read it by hand with the guide below, or paste it into an email header analyzer, which lays the hops out in order with timing and highlights the authentication results.

The headers that matter

Received: the delivery chain

Each server that handles the message adds a Received: line to the top of the headers. Reading from the bottom up therefore follows the message from its origin to your inbox. A typical line looks like this:

Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41])
        by mx.example.net with ESMTPS id k7si2290871
        for <you@example.net>; Tue, 7 Oct 2026 09:14:22 -0700 (PDT)

"from" names the server that handed the message over, with the IP address it connected from in brackets; "by" names the server that received it; the timestamp says when. The bottom-most Received line shows where the message entered the system. If an email claims to be from your bank but the first hop is a residential broadband address or a server in a country the bank does not operate in, you have your answer.

Two cautions. First, the sender can add fake Received lines below the real ones, because they control the message before it is sent; only the lines added by servers you trust, starting with your own provider's, are guaranteed genuine. Second, large providers route mail through several internal servers, so five or six hops from Google or Microsoft is normal, not suspicious.

Return-Path: where bounces go

This is the envelope sender, the address the sending server gave in the SMTP conversation, which is often different from the From header. Bulk senders use a unique Return-Path per recipient to track bounces. SPF is checked against this domain, not the From domain, which is why the two must be looked at together.

From, Reply-To and Sender

From: is what you see in your client. Reply-To:, if present, is where replies actually go; a Reply-To that differs from the From domain is a classic sign of a scam. Sender: appears when a message is sent on behalf of someone, for example by a mailing-list service.

Message-ID, Date and X- headers

Message-ID is a unique identifier assigned when the message was created, and its domain part often reveals the real sending system even when the From address is forged. Date is set by the sender's software and can be wrong or faked; compare it with the Received timestamps. Headers beginning with X- are non-standard extras: X-Mailer names the software used, X-Originating-IP sometimes records the author's IP, and X-Spam-Score or similar shows what your provider's filter thought.

Authentication results: SPF, DKIM and DMARC

Modern receiving servers check three things and write the results into an Authentication-Results: header. This is the most useful line in the whole block.

Authentication-Results: mx.example.net;
       spf=pass smtp.mailfrom=bounces.shop.com;
       dkim=pass header.d=shop.com;
       dmarc=pass header.from=shop.com

SPF (Sender Policy Framework) asks: is the IP address that delivered this message on the list the Return-Path domain publishes in DNS? pass means yes. fail means an unauthorised server sent it. softfail and neutral mean the domain's policy is lenient; treat them as "unknown".
DKIM (DomainKeys Identified Mail) asks: was this message cryptographically signed by the domain in header.d, and is it unmodified since? A pass proves the message really came through that domain's mail system. A fail usually means the message was altered in transit, often by a mailing list, or forged.
DMARC asks: does the domain in the visible From header match the domain that passed SPF or DKIM, and what does the From domain's policy say to do if not? dmarc=pass is the strongest signal that the From address is genuine. A domain whose DMARC policy is p=reject cannot be easily impersonated; one with no DMARC record can.

The crucial subtlety: these checks verify that the message came from the domain it says it came from. They do not verify that the domain is trustworthy. A phishing email sent from secure-paypal-login.com will pass all three with flying colours, because the attacker set them up correctly. Authentication tells you the sender is who they claim; you still have to decide whether that claimant is the real company. Our guide to spotting phishing emails covers the rest of that judgement.

A worked example

Suppose a message arrives apparently from billing@yourbank.com saying a payment failed. In the headers:

Authentication-Results shows spf=pass smtp.mailfrom=mail.promo-blast.net, dkim=pass header.d=promo-blast.net, dmarc=fail header.from=yourbank.com. The message was genuinely sent by promo-blast.net, but that domain is not authorised to use yourbank.com in the From line. DMARC failed because the domains do not align.
The bottom Received line shows the message entered the mail system from an IP address belonging to a cheap hosting provider, not the bank.
Reply-To is a webmail address.

Each of those alone is suspicious; together they are conclusive. The visible From line was a lie, and the headers said so.

Reading headers from your own mail

Headers are also the fastest way to debug mail you send. If your newsletters land in spam, the Authentication-Results on a test message tells you whether SPF, DKIM and DMARC are set up correctly for your domain. If delivery is slow, the gaps between Received timestamps show which hop is holding the message. Developers testing signup and password-reset emails can send to a disposable test inbox and inspect the headers there without cluttering a real mailbox.

Limits of header analysis

Headers show the path a message took and whether it was authenticated. They do not reveal the identity of a person behind a free webmail account, since the originating IP is that of the provider's servers, and they cannot tell you whether a correctly authenticated domain is run by honest people. They are one input to a judgement, not a verdict. Combined with the content checks in the phishing guide, though, they settle almost every case.