How to Read Email Headers: Trace Sender, Route, SPF, DKIM, and DMARC
How to Read Email Headers: Trace Sender, Route, SPF, DKIM, and DMARC
The visible part of an email is only the message body. The most useful security information is often hidden in the raw headers. Headers show where a message came from, which servers handled it, and whether SPF, DKIM, and DMARC checks passed.
You do not need to understand every line. You only need to know which fields matter.
Start with Authentication-Results
The Authentication-Results header is usually the fastest place to start. It summarizes whether SPF, DKIM, and DMARC passed for the receiving server.
Look for values such as:
spf=passdkim=passdmarc=passspf=faildkim=faildmarc=fail
A single fail does not always prove malicious intent, but it is a strong signal to slow down and inspect the message more carefully. For a deeper explanation of how these checks work, see our guide to SPF, DKIM, and DMARC.
You can paste raw headers into the email header analyzer to surface these values quickly.
Read Received headers from bottom to top
Email can pass through several servers before reaching your inbox. Each server usually adds a Received header, a behavior defined by the SMTP transport standard (RFC 5321).
The newest hop is normally near the top. The oldest hop is normally near the bottom. When tracing the original route, read from bottom to top.
Watch for:
- Unexpected sending hosts
- Private or unusual IP addresses
- Domain names that do not match the claimed sender
- Long or strange routing paths
Compare From and Return-Path
The visible From address is what most people see in their mail app. The Return-Path is used for bounces and may reveal a different sending domain.
These fields do not have to be identical, but they should make sense together. A brand message with a strange unrelated return path deserves more scrutiny.
Check Message-ID
Message-ID is a unique identifier created by the sending system, one of the header fields standardized in the Internet Message Format (RFC 5322). It often contains the sending domain.
If the Message-ID domain is unrelated to the sender, it may still be legitimate if a third-party email provider is used. But combined with failed authentication, it becomes a useful warning sign.
Use DNS tools when headers point to a domain issue
Headers can tell you that authentication failed, but DNS records explain why. If you own the sending domain, inspect the records directly:
- Use SPF checker to confirm allowed senders.
- Use DKIM checker to confirm the selector publishes a key.
- Use DMARC checker to confirm the domain policy.
- Use MX lookup to confirm inbound mail routing.
A quick suspicious email checklist
Before clicking a link or downloading a file, check:
- Does the sender domain match the brand?
- Did SPF, DKIM, or DMARC fail?
- Are the links pointing to the expected domain?
- Does the message create urgency or ask for credentials?
- Do the Received headers show an unexpected path?
If two or more answers feel wrong, do not click. Visit the service directly from your browser instead.
Final thought
Raw headers look intimidating, but the first useful signals are simple: authentication results, sending path, sender identity, and message links. Once you know where to look, headers become one of the fastest ways to evaluate a suspicious email.