Your mail client shows only a few fields of an email header: From, To, Subject and Date. The rest of the technical block stays hidden, and that is where the message’s route and its authentication verdict are recorded.
An email header is the series of “Name: value” lines placed before the body of a message. It tells you who sent the mail, which servers it passed through and whether SPF, DKIM and DMARC checks succeeded. To read it, open “Show original” in Gmail or “View message details” in Outlook, then read the Received lines from the bottom up.
How to view the email header in Gmail, Outlook, Apple Mail and Yahoo
Each mail client hides the raw header behind a different menu. The paths below follow the Gmail help page and the Microsoft documentation:
- Gmail: open the message, click the three dots next to Reply, then “Show original”. The “Copy to clipboard” button grabs the full header. Gmail also summarizes the SPF, DKIM and DMARC results (Pass or Fail) at the top of the window.
- Outlook on the web and new Outlook: open the message, then More actions > View > View message details.
- Classic Outlook for Windows: double-click the message to open it outside the reading pane, then File > Properties. The header sits in the “Internet headers” box.
- Apple Mail: open the message, then View > Message > All Headers.
- Yahoo Mail: open the message, click More, then “View raw message”.
Paste the result into a text editor such as Notepad++ or TextEdit. A header is hard to read in a narrow window.
An annotated email header example
Here is a header cut down to the essentials, with the fictional domain example.com (reserved by RFC 2606, 1999) and IP addresses from the 203.0.113.0/24 documentation range (RFC 5737, 2010). A real message in 2026 often has more lines, notably Delivered-To and DKIM-Signature fields.
Return-Path: <bounce+8f2a@bounce.example.com> Authentication-Results: mx.destinataire.example; spf=pass smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com Received: from smtp1.example.com (smtp1.example.com [203.0.113.25]) by mx.destinataire.example with ESMTPS; Tue, 3 Nov 2026 09:14:07 +0100 Received: from app.example.com (app.example.com [203.0.113.10]) by smtp1.example.com with ESMTP; Tue, 3 Nov 2026 09:14:02 +0100 From: Camille Martin <camille@example.com> Reply-To: <support@example.com> To: <lea@destinataire.example> Subject: Your October invoice Date: Tue, 3 Nov 2026 09:14:01 +0100 Message-ID: <20261103091401.8f2a@app.example.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8
The message is composed at 09:14:01 (Date field) on 3 November 2026. smtp1.example.com receives it from app.example.com (203.0.113.10) at 09:14:02, then mx.destinataire.example receives it at 09:14:07. That is 5 seconds between the two servers and 6 since composition. All 3 authentication checks show “pass”.
Reading the header fields, from most visible to most technical
The first 4 fields below appear in the inbox. The others require the full header view.
- From: the address displayed as the sender. The sender writes it, so it proves nothing on its own.
- To and Date: the declared recipient and the time of composition, set by the mail client or the submission server.
- Subject: the subject line. It belongs to the header and shows in the inbox, like From and Date. Writing a good one is covered in our guide to eye-catching email subject lines. The preview text shown after the subject is not part of it: see the pre-header guide.
- Return-Path: the address that receives bounces. The receiving server copies it from the SMTP envelope (the MAIL FROM command of RFC 5321 (2008)). For mail sent through an email service provider, it points to a bounce domain different from the From domain. That is normal, as explained in the article on the return path.
- Reply-To: the address that receives your reply. Without this field, the reply goes to the From address.
- Message-ID: the unique identifier of the message, generated at sending. Technical support asks for it to find the mail in their logs.
- MIME-Version and Content-Type: the content format (text/html or multipart/alternative) and its character set, as defined in RFC 2045 (1996).
- X- fields: added by filters. X-Spam-Status, for example, carries the SpamAssassin score, covered in the guide to the SpamAssassin score.
The syntax of these fields is defined by RFC 5322 (2008).
Reading the Received lines from the bottom up
Each SMTP server that relays the message adds its own Received line above the previous ones. The lowest line is therefore the first server and the highest is the last. This trace is specified in section 4.4 of RFC 5321.
A line contains the name announced by the sending side (from), its IP address in brackets, the receiving server (by) and a timestamp. Only the lines added by your own provider or by the receiving server deserve trust: a malicious sender can forge the lowest lines before sending.
Received describes the route. It contains no SPF or DKIM verdict.
Reading Authentication-Results: SPF, DKIM and DMARC
The Authentication-Results field (standard RFC 8601 (2019)) is written by the receiving server on arrival. The line added by your own server is out of the sender’s reach, which makes it the most reliable one in the header. Be wary of same-name lines placed lower down, which a sender may have invented.
- spf=pass (RFC 7208 (2014)): the IP that delivered the message appears in the DNS record of the envelope domain. How it works is explained in the article on SPF.
- dkim=pass (RFC 6376 (2011)): the cryptographic signature is valid. The header.d value gives the signing domain. See also DKIM.
- dmarc=pass: SPF or DKIM succeeds with a domain aligned with the From domain (the same domain, or the same organizational domain under relaxed alignment, per RFC 7489 (2015)). Setup is covered in the DMARC guide.
For SPF, the failure values are fail (“-all” in the DNS record) and softfail (“~all”). An SPF evaluation stops at 10 DNS lookups (RFC 7208); beyond that, the result is permerror. Temporary errors (temperror) and permanent errors (permerror) point to a DNS or configuration problem. After forwarding, SPF often fails because the relay’s IP is not authorized. ARC lines (RFC 8617 (2019)) then preserve the verdict each intermediary saw on arrival when it seals the message.
Spotting phishing or spoofing in the header
Compare From, Return-Path and Reply-To first. A Return-Path that differs from the From is common in email marketing. A Reply-To pointing to a domain unrelated to the displayed sender, on the other hand, deserves a check.
Move on to Authentication-Results. A dmarc=fail on a message claiming to come from a bank or a carrier signals spoofing. A missing line means the receiving server recorded no verdict, so draw no reassuring conclusion from it. Finally, look at the lowest Received line, the first server: if the origin IP of a “customer service” mail belongs to a host with no link to the company, your suspicion is confirmed.
Diagnosing a delay or a spam placement
You launch a campaign, the email tool says “sent”, and the recipient gets the message 60 minutes later or in the spam folder. Ask them for the full header.
For a delay, subtract the timestamps of two consecutive Received lines. If the clocks are synchronized, the hop that concentrates the gap points to the faulty server: a saturated queue or rate limiting at the recipient. For a deliverability problem (message filed as spam), reread Authentication-Results: a fail on one of those three checks is the first lead. Also look for an X-Spam-Status field with a high score. Since 2024, Google’s sender guidelines require SPF or DKIM authentication for any mail sent to a personal Gmail account. Above 5,000 messages a day, both SPF and DKIM are required, plus a DMARC record. A failure on one of these checks weighs heavily on a campaign’s reputation.
Common mistakes
- Looking for SPF and DKIM in Received. Those verdicts live in Authentication-Results.
- Reading Received lines from top to bottom and taking the last server for the message’s origin.
- Trusting the displayed From without checking dmarc.
- Forwarding the message as text to technical support: forwarding rewrites the header. Attach it as an .eml file.
Using a header analyzer
A header analyzer, such as Google Admin Toolbox or MxToolbox, takes the header pasted as plain text. It rebuilds the route hop by hop and computes the delay of each relay.
An analyzer does the legwork but cannot tell you whether the server that wrote a Received line is trustworthy. That judgment is yours.
