How to Trace Email Headers Back to the Sender

To trace email headers, open the full original source and read the Received lines from bottom to top; each line is one server hop. Then check Authentication-Results for SPF, DKIM and DMARC.

Headers are the routing slip of an email. Every server that handles a message adds information, and together those lines show where the message came from, which systems relayed it and whether the sender passed authentication. This guide walks through the process step by step and explains which parts you can trust and which you cannot.

How do you view the full headers of an email?

Every mail client hides headers by default, but each one has a "show original" or "view source" option. Open the message, find that option, and copy the whole block of text from the first line down to the blank line that separates headers from the body.

Common locations:

Gmail: open the message, choose the three-dot menu, then "Show original".
Outlook (desktop): open the message in its own window, then File > Properties and read the "Internet headers" box.
Apple Mail: choose View > Message > All Headers, or Raw Source.
Other clients: look for "View source", "Message source" or "Headers" in the message menu.

Copy everything. Partial headers make tracing unreliable because a missing line can hide a hop.

How do you read Received lines to trace the route?

Read Received headers from the bottom up. Each server that accepts a message adds its own Received line at the top, so the lowest line was added first, closest to the original sender, and the top line was added last, by the server that delivered the message to your mailbox (see RFC 5321 for trace information).

Here is a shortened example:

Received: from mx.example.com (mx.example.com [198.51.100.25])
        by mailbox.example.net with ESMTPS; Tue, 04 Nov 2025 10:02:13 +0000
Received: from smtp.mailer.example.org (smtp.mailer.example.org [203.0.113.40])
        by mx.example.com with ESMTPS; Tue, 04 Nov 2025 10:02:11 +0000
Received: from [192.0.2.77] (unknown [192.0.2.77])
        by smtp.mailer.example.org with ESMTPA; Tue, 04 Nov 2025 10:02:09 +0000

Working from the bottom:

A client at 192.0.2.77 submitted the message to smtp.mailer.example.org. The "ESMTPA" keyword indicates an authenticated submission.
That server relayed it to mx.example.com.
mx.example.com delivered it to the final mailbox server.

For each hop, note the "from" host, the IP address in brackets, the "by" host and the timestamp. Timestamps should move forward as you read upward. A large gap between two hops points to a queue or delay at that server, which is useful when you are troubleshooting slow delivery as well as suspicious mail.

You can then look up each IP address and reverse DNS name to see who operates it. If you want to check a header you have copied against a second tool, the header lookup tool is a companion to this guide.

What do Authentication-Results tell you about the sender?

The Authentication-Results header records what the receiving server concluded about SPF, DKIM and DMARC for that message. It is defined in RFC 8601. A DMARC "pass" means at least one of SPF or DKIM passed and aligned with the visible From domain.

A typical example:

Authentication-Results: mailbox.example.net;
  spf=pass smtp.mailfrom=bounce.example.com;
  dkim=pass header.d=example.com header.s=selector1;
  dmarc=pass header.from=example.com

How to read it:

spf: the envelope sender (smtp.mailfrom) was checked against the SPF record of that domain and the connecting IP.
dkim: a signature was verified. The header.d value is the signing domain and header.s is the selector.
dmarc: the policy check against the From header domain (header.from).

Pay attention to alignment. A message can show "spf=pass" for a bounce domain belonging to a mail service while the From address shows your brand. If neither SPF nor DKIM aligns with the From domain, DMARC fails even though the individual checks passed. You can inspect the sending domain's published policy with the DMARC record lookup.

To check the record behind a DKIM result, query the selector yourself:

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Can email headers be forged?

Yes, partly. Any header added by the sender, including From, Reply-To and the earliest Received lines, can be faked. Only lines written by servers you trust are dependable, and the most important one is the line your own boundary MX wrote when it accepted the message from the internet.

This shapes how you should trace:

Find your boundary MX line. If your mail passes through internal relays, a security gateway or a cloud filter, the top line is not necessarily the one to trust. Trust the Received line added by the server that first took the message from the internet, and the Authentication-Results written by that same system. Lines below it are claims made by other parties.
Treat lower Received lines as claims. If the chain is plausible and matches the authentication results, it is probably genuine. If a hostname does not match its IP's reverse DNS, be cautious.
Compare From, Return-Path and Reply-To. Mismatched domains are a common sign of spoofing, or of a legitimate third-party sender that is not aligned.
Look at Message-ID. Its domain often reveals the real sending platform.
Allow for forwarding. Mailing lists and forwarders often break SPF, and can break DKIM if they alter the message. A failure on forwarded mail does not prove spoofing. Look for ARC headers (ARC-Seal, ARC-Message-Signature and ARC-Authentication-Results, defined in RFC 8617), which let an intermediary record the results it saw. They are only worth relying on if you trust the system that sealed them.

A forged From address with "dmarc=fail", no ARC chain from a trusted intermediary and a sending IP unrelated to the domain is the classic spoofing pattern. If the domain has a DMARC policy of quarantine or reject, receivers that honour it will act on that failure.

What should you do after you trace an email?

After tracing, decide whether the source is legitimate. If it is a service your organisation uses, fix its authentication so it aligns with your From domain. If it is not, report it and make sure your own domain's policy blocks similar abuse.

Practical next steps:

Legitimate sender failing DMARC: check which identifier failed to align. Most third-party senders use their own bounce (MAIL FROM) domain, so adding their include to your SPF record does nothing for DMARC. The reliable fix is to enable DKIM signing with your own domain, so the signature shows d=example.com. SPF helps only if the service is set up with a custom return-path or bounce domain under your From domain, for example bounce.example.com.
Unknown sender using your domain: this is spoofing. Move your DMARC policy towards enforcement, as described in RFC 7489.
Suspicious inbound message: report it to your security team and keep the full headers as evidence.

A custom bounce domain is usually a CNAME that the service tells you to publish, along these lines:

bounce.example.com. IN CNAME returns.mailer.example.org.

A single header only shows one message. To see every source sending as your domain, you need aggregate data. DMARC monitoring from yourDMARC collects and visualises DMARC aggregate reports for your domains, so you can find unknown senders without tracing messages individually. You can also run the domain scanner to check your DMARC, SPF and DKIM records.

Common mistakes when you trace email headers

Reading top to bottom. This reverses the path and leads you to the wrong origin.
Stopping at the first IP. The first visible IP may be your own gateway or a security filter, not the sender. Keep reading until you reach the hop where the message entered from outside your organisation.
Ignoring time zones. Timestamps carry offsets. Compare them in the same zone.
Trusting display names. The name shown in the inbox is not authenticated at all.
Judging forwarded mail at face value. Failed SPF or DKIM on a forwarded or mailing-list message may be a side effect of the forwarding.
Using forwarded copies for evidence. Forwarding as an attachment preserves the original headers, while inline forwarding replaces them with new ones.

Key takeaways

To trace email headers, copy the full original source of the message, not a trimmed view.
Read Received lines from bottom to top; each one is a server hop.
Trust the Received line and Authentication-Results written by your boundary MX, not simply the top line.
Authentication-Results shows SPF, DKIM and DMARC outcomes as judged by the receiving server.
Alignment with the From domain is what makes DMARC pass. For third-party senders, DKIM signing with your own domain is the dependable fix.
Forwarding and mailing lists can break SPF and DKIM; check ARC headers before calling a message spoofed.
Use header tracing for single messages and DMARC aggregate reporting to see all senders using your domain.

Protect your inbox, save time, and stay compliant. Subscribe to our newsletter for personalized email security audits, expert advice, and actionable tips.

Download to read the eBook