Every message carries a stack of header fields that record how it was routed, whether it passed authentication, and how the sending software built it. Most people never look at them, but they are the most reliable evidence available when a message looks wrong. This article explains the headers that matter, how to read them in order, and which ones you can trust.
How to see the raw headers
Most clients have a "show original", "view source", or "message headers" command, usually in the message menu, and webmail clients offer the same. Use the raw form rather than a formatted summary, since summaries drop fields. Headers are plain text, one field per logical line, and a continuation line begins with whitespace.
The order matters
Each server that handles a message prepends its own headers to the top. The list therefore runs from newest at the top to oldest at the bottom. The first Received line was added by the last server before your mailbox, and the last one was added by the sender's first server. Read from the bottom up to follow the path.
Received
A typical Received header looks like this:
Received: from mail.example.com (mail.example.com [203.0.113.25])
by mx1.itpromail.com (Postfix) with ESMTPS id 4kP2nq1sZkz9
for <you@itpromail.com>; Sat, 31 Oct 2026 09:14:02 +0000The parts are: the name and IP address the previous hop claimed, the server that received it, the protocol and TLS status (ESMTPS means TLS was used), the queue ID, the recipient, and the timestamp. Compare timestamps between hops to find slow links or delays.
Trust these lines with care. Each server records what the connecting machine claimed about itself, and a sender can forge the earlier lines. The lines added by your own receiving server are the most reliable, because they describe the connection your server actually accepted. Anything added by a remote server is a claim until you check it.
Authentication-Results
This is the most useful header for security work. It is defined in RFC 8601 and is added by the receiving server to summarise its checks:
Authentication-Results: mx1.itpromail.com;
spf=pass smtp.mailfrom=example.com;
dkim=pass header.d=example.com header.s=sel1;
dmarc=pass header.from=example.comThe first token is the authserv-id, the name of the server that performed the checks. Trust only the one that matches your own server. Each method reports a result, such as pass, fail, softfail, none, neutral, temperror, or permerror. The properties after each method show what was checked. For example, smtp.mailfrom is the envelope sender used for SPF, and header.from is the visible From domain used for DMARC.
Other headers worth knowing
- Return-Path: the envelope sender, copied in at final delivery.
- DKIM-Signature: the signing domain (d=), the selector (s=), the headers covered, and the signature. Changing a signed header breaks verification.
- Received-SPF: a record of the SPF result, added by some servers in addition to Authentication-Results.
- ARC-Authentication-Results, ARC-Seal, ARC-Message-Signature: the Authenticated Received Chain. Intermediaries such as mailing lists use it to preserve authentication results across forwarding.
- Message-ID: a unique identifier, usually including the sending domain. Useful for matching replies and spotting forged identifiers.
- Date: written by the sending client. It is not reliable for ordering, so compare it with the Received timestamps.
- List-Unsubscribe: present on bulk and list mail, often with a one-click option.
A quick checklist
- Find the Authentication-Results line added by your own server.
- Check the SPF, DKIM, and DMARC results, and which domains each one checked.
- Compare the From domain with the DKIM d= domain. A mismatch is a common sign of spoofing, although legitimate third-party senders also produce it.
- Read the Received chain from the bottom up, and look for hops that do not fit.
- Check that the Return-Path and Reply-To domains are the ones you expect.
For how the authentication checks are set up on the sending side, read SPF, DKIM and DMARC explained. For a worked phishing example, see spotting modern phishing.