How to Read Email Headers Without Overtrusting Them

Email headers record parts of a message’s journey and the checks made along the way. They can help explain a delivery problem or a suspicious sender, but they cannot prove that a request in the message is safe. Start with a narrow question: which entries were added by the mail system responsible for your inbox, and what do those entries actually show?

To find the full header, look in your mail interface for an option such as “view source”, “show original” or “message details”. The familiar sender name and date shown beside a message are only a summary. Keep the original message while you examine it; copying a few lines into a note can lose the order and context needed to interpret them.

Separate the main fields

Consider an invented message. Its From address uses alerts.example.test, while its Return-Path uses mailer.example.test. A Received line says that an inbox server accepted it from a relay at 09:14 UTC; another Received line below says the relay accepted it at 09:13. The Date field says 09:12. An Authentication-Results field reports SPF and DKIM passes for mailer.example.test, but a DMARC failure for alerts.example.test. These are fictional labels for learning, not evidence from a real message.

From is the sender address presented to the reader. Return-Path identifies where delivery failures are directed and may use a different domain, especially when another system sends the mail. Neither field identifies the person who typed the message. A difference between them is a reason to check the authentication details, not an automatic sign of impersonation.

Received lines describe handoffs. Each receiving system normally puts its own line above the lines already present, so the newest handoff appears near the top. Read each line for the server that says it accepted the connection, the server or address it says connected, and the time. An older line may be genuine, but it arrived inside material supplied to the next receiver and deserves less confidence until you can establish who wrote it.

Locate the trust boundary

The most useful starting point is the point where the message entered the mail system that handles your inbox. A line written there can describe a connection that system observed. A hostname that merely looks familiar is not enough: a sender can place text in earlier header fields. Compare the claimed receiver with the information your own mail service provides, or ask its administrator if the route matters to an investigation.

Apply the same caution to Authentication-Results. An apparent “pass” has value only if the result came from a receiver whose checks your mail system trusts. The mere presence of that field is no guarantee of authenticity; RFC 8601’s trust-boundary guidance explains how results crossing an untrusted boundary can mislead. If several results appear, identify the system named in each rather than adding all the passes into a score. When you cannot identify the author of a result, leave it unresolved.

When reading a long header, mark the first handoff your own service can confirm, then work downwards. Treat any earlier line as a claim awaiting support. This keeps a forged upstream trace from giving false weight to later details. If your mail interface presents a summary of its own checks, compare that summary with the raw fields before relying on a result copied from another server.

Match each check to its domain

SPF asks whether the connecting server was authorised to send for the domain checked during the mail transaction. In the invented message, an SPF pass for mailer.example.test says something about that sending arrangement. It does not authenticate the visible alerts.example.test address or approve the words in the message. Write down the domain after the SPF result before drawing a conclusion about the sender shown on screen.

DKIM verifies a signature tied to a signing domain and specified parts of a message. A pass for mailer.example.test means the checked signature verified for that domain. It does not identify a particular human, show that every header field was signed, or establish that the request is honest. A sender who controls a domain can sign misleading mail. If verification fails, an alteration during forwarding may also be relevant; the failure alone does not explain why the message changed.

DMARC compares a passing SPF or DKIM identity with the domain in the visible From address. In the fictional example, both passes concern mailer.example.test, while From uses alerts.example.test. If neither passing identity aligns with that From domain, DMARC can fail despite the two passes. These checks concern domain authentication and alignment, as described in guidance on authenticating a sending domain. They do not judge the truth of a delivery notice, payment request or attachment.

A failed check needs context as well. A legitimate message can fail after forwarding, a mailing list changes signed content, or a sender misconfigures its mail. Conversely, a fully passing message can still ask you to do something harmful. Record the exact result, domain and receiving system before deciding what further evidence you need. “Authentication passed” is too broad to be useful when the checked domain differs from the one you thought you were assessing.

Use times and routes carefully

Compare times only after converting their time-zone offsets to the same zone. The Date field is supplied with the message and can be wrong. A server clock may also be wrong, and mail can wait in a queue between handoffs. In the invented sequence, the times are consistent, but that consistency proves little about who composed the message. The timestamp from a receiver you trust is strongest for the moment it accepted a connection, not for the message’s origin.

Do not turn the Received chain into a claim about someone’s physical location. Mail can travel through relays, gateways and hosted infrastructure; hostnames are chosen by their operators. A defensible observation is that a trusted receiver recorded a connection from a particular address at a particular time. If you need to establish whether an earlier hop really occurred, the relevant mail administrator may be able to compare the header with server logs unavailable to a recipient.

Forwarding also changes what each check measures. A final receiver may see a forwarder’s server rather than a server authorised by the original sending domain, causing SPF to fail. A gateway may modify content covered by a DKIM signature. Some systems preserve earlier authentication information, but the final receiver still has to decide whether to trust it. Look for a known forwarding step and distinguish the result at each hop; do not explain away every mismatch as forwarding without evidence of one.

Handle the header and the request separately

Full headers can reveal recipient addresses, subjects, message identifiers, internal server names and network addresses. Keep the original intact for anyone who must investigate. For a public question, work from a copy, remove personal or sensitive details, and mark every redaction. Keep the domains distinct if their relationship is the question. Substituting fictional domains can make a useful teaching example, but the altered copy cannot verify the original authentication result.

If the message asks you to change access, share information or make a payment, verify the request through a route you already know independently of the email. A header cannot authorise the request. For suspected phishing, follow your organisation’s reporting route or guidance on reporting a suspected phishing message. When asking a mail team for help, send the original through its approved private channel and state the precise question: which receiver wrote this result, was the message forwarded, or does a server log confirm the handoff?