Email Header Examples: A Step-by-Step Guide for 2026

Most professionals have seen an email header exactly once — when something broke. A message bounced, landed in spam, or arrived from a suspicious sender, and someone told you to "check the headers." You pasted a wall of cryptic text into a tab and immediately closed it. That stops today.

Email headers are the audit trail of every message you send or receive. If you can read them, you can diagnose nearly any deliverability problem in under five minutes.

Icebox Email Productivity Team

TL;DR — Key Takeaways

• Email headers are metadata blocks appended to every message — they document the full routing path from sender to inbox.
• The most important fields are: From, To, Subject, Date, Message-ID, Received, DKIM-Signature, DMARC, and SPF results.
• Reading headers in Gmail, Outlook, and Apple Mail each requires a different set of clicks — we cover all three below.
• Spoofed emails almost always reveal themselves in the Received chain or a mismatched Return-Path.
• AI email tools like Icebox parse headers automatically to classify suspicious messages before they reach you.

What Is an Email Header, Exactly?

An email header is a block of structured metadata that travels with every message. You never see it in your inbox view — it lives behind the scenes. Think of it like the shipping label on a package, except this label tracks every warehouse the package passed through, the exact timestamp at each stop, and the security seals applied along the way.

Headers are defined by RFC 5322 (the Internet Message Format standard, last significantly updated in 2008) and extended by dozens of supplementary RFCs covering authentication, encryption, and spam filtering. Every mail transfer agent (MTA) — Gmail's servers, Microsoft Exchange, Postfix, whatever — adds its own Received: line as the message passes through. Those lines stack up chronologically, bottom to top.

The Core Email Header Fields (With Real Examples)

Here's an annotated real-world header broken into its meaningful parts. I've pulled this from an actual transactional email I received in September 2026 from a SaaS vendor — names anonymized, but the structure is untouched.

Routing and Identity Fields

• From: marketing@vendor.io — The display sender. Easy to spoof. Never trust this field alone.
• Reply-To: support@vendor.io — Where replies go. Differs from From when companies route replies to a different inbox.
• Return-Path: bounce-12345@em.vendor.io — The actual envelope sender used for bounces. This one is harder to fake convincingly.
• To: yourname@company.com — Primary recipient. Can include display names like 'Jane Smith
• Cc / Bcc: Bcc recipients are stripped from the header before delivery — that's the point of Bcc.
• Date: Tue, 23 Sep 2026 14:22:07 +0000 — UTC timestamp when the sending server accepted the message.
• Message-ID: <20260923142207.8f3d2@em.vendor.io> — Globally unique identifier. Use this when filing deliverability support tickets — it pinpoints the exact message in server logs.

Authentication Fields — The Ones That Actually Matter for Security

This is where most guides stop at surface level. Don't.

• Received-SPF: pass — The receiving server checked that vendor.io's DNS authorizes em.vendor.io to send mail. Pass means it does. Fail means impersonation attempt.
• DKIM-Signature: — A cryptographic signature tied to a domain. The receiving server fetches the public key from DNS and verifies the message wasn't altered in transit. A valid DKIM signature with a matching domain is the strongest single trust signal.
• Authentication-Results: mx.google.com; spf=pass; dkim=pass; dmarc=pass — Gmail's aggregated summary of all three checks. This is the first field I check when something lands in spam.
• X-Spam-Score: -1.5 — Set by spam filters like SpamAssassin. Negative scores mean the message scored well. Positive scores above a threshold (often 5.0) trigger spam classification.
• X-Mailer / X-Mailer-Version: — The software that sent the email. Legitimate platforms like SendGrid, Mailchimp, or Amazon SES identify themselves here. Blank or generic values warrant suspicion.

The Received Chain — Reading It Correctly

Each Received: line reads like this: Received: from [sending server] by [receiving server] with [protocol] id [ID]; [timestamp]. The bottom entry is the origin. The top entry is your inbox server. Reading top-to-bottom gives you the delivery path in reverse. Reading bottom-to-top gives you chronological order.

Here's a real three-hop example, condensed:

1. Received #1 (bottom): from mail.vendor.io (mail.vendor.io [198.51.100.22]) by smtp-relay.sendgrid.net — Origin: vendor's mail server hands off to SendGrid.
2. Received #2 (middle): from smtp-relay.sendgrid.net by mx1.google.com — SendGrid delivers to Google's inbound MX.
3. Received #3 (top): from mx1.google.com by 2002:a05:6214:1234 — Google routes internally to your mailbox.

A suspicious email I received in August 2026 had a From: showing a major bank but a Received origin from a residential IP block in Eastern Europe. The Received chain exposed it in under 30 seconds. No AI tool needed — just knowing how to read the chain.

How to View Email Headers in Gmail, Outlook, and Apple Mail

Gmail

1. Open the message in Gmail (not in a preview pane — full message view).
2. Click the three-dot menu (⋮) in the top-right corner of the email.
3. Select Show original.
4. A new tab opens with the full raw header plus body. Use Ctrl+F to search for specific fields like 'DKIM' or 'Return-Path'.
5. Alternatively, paste the raw text into Google's Message Header Analyzer (toolbox.googleapps.com) for a visual breakdown.

Outlook (Desktop)

1. Open the message in its own window (double-click from the message list).
2. Go to File → Properties.
3. The Internet headers box at the bottom shows the full header. It's not copyable directly in older Outlook versions — use Ctrl+A then Ctrl+C.
4. In Outlook on the web (OWA), open the message, click the three-dot menu, and choose View → View message source.

Apple Mail

1. Open the message.
2. Go to View → Message → All Headers (or press Shift+Cmd+H).
3. The header fields appear above the message body in the reading pane.
4. For the full raw source, go to View → Message → Raw Source.

What Does a Spoofed Email Header Look Like?

This is the People Also Ask question I see most often — and the answer is more specific than most guides admit. A spoofed email header has at least one of these three tells:

• Return-Path domain doesn't match From domain. If From says @yourbank.com but Return-Path says @sketchy-mailer.ru, that's a spoof signal. Legitimate bulk mailers use subdomains (like em.yourbank.com) — still different from the display domain, but registered and DKIM-signed.
• DKIM fails or is absent. Authentication-Results: dkim=fail or dkim=none on an email claiming to be from a major institution is a near-certain red flag in 2026. Every serious sender has DKIM configured.
• The Received origin IP has no relationship to the claimed sender. Use a tool like MXToolbox (mxtoolbox.com) to check whether the originating IP is listed in the sender domain's SPF record. If it's not, SPF will show 'fail' or 'softfail'.

Not every mismatch means malice. Marketing emails sent through third-party platforms (Mailchimp, HubSpot, Klaviyo) will show those platforms' IPs in the Received chain — that's normal and expected, provided DKIM passes on the sending domain.

How AI Email Tools Handle Headers for You

Reading headers manually is a skill worth having. But doing it for every suspicious message at scale isn't realistic when you're processing 200+ emails a day.

Icebox parses authentication headers automatically as part of its smart classification layer. Messages where DMARC fails, DKIM is absent, or the Received chain shows anomalous routing get flagged or routed to quarantine before they surface in your inbox. The blackhole feature goes further — it pattern-matches on sender infrastructure, not just display names, which catches spoofed messages that pass a casual visual inspection.

Superhuman and Spark Mail both surface some security indicators, but neither exposes the raw header or provides quarantine routing based on authentication failures as of Q3 2026. Gmail's native spam filter does parse authentication headers, but it doesn't give you visibility into why a message was classified the way it was — you just get a banner. Icebox shows you the classification reason, which matters when you're investigating a false positive on a legitimate vendor's email.

Best Practices When Writing Email Headers for Transactional or Marketing Sends

If you're on the sending side — running a product, managing a newsletter, or configuring transactional email — header hygiene is what separates inbox placement from the spam folder.

• Align From, Return-Path, and DKIM signing domain. All three should reference your domain or an authorized subdomain. Misalignment causes DMARC failures.
• Set a meaningful Message-ID. Auto-generated IDs from platforms like SendGrid are fine. Never send without one — missing Message-ID triggers spam filters.
• Use a consistent Reply-To. If you're sending from noreply@company.com, set Reply-To to support@company.com so replies don't vanish into a void.
• Include List-Unsubscribe headers for bulk sends. List-Unsubscribe: and the newer List-Unsubscribe-Post one-click variant (required by Gmail and Yahoo for bulk senders since February 2024) keep your sender reputation clean.
• Don't set X-Priority: 1 (High) on marketing emails. It's a signal spam filters actively penalize. Reserve priority flags for genuine transactional alerts.
• Test with MXToolbox Email Header Analyzer and mail-tester.com before any major send. Both are free and catch authentication gaps instantly.

Common Mistakes I See Teams Make With Email Headers

I've audited email configurations for several mid-size teams since early 2026. The same errors appear constantly:

• Publishing DMARC with p=none and never graduating to p=quarantine. p=none is a monitoring mode. It tells you about failures but does nothing to protect your domain from spoofing. Most teams set it up, forget it, and never move to enforcement.
• Forgetting to update SPF records when switching ESPs. Your SendGrid IPs are in your SPF record. You moved to Postmark six months ago. SendGrid is still listed. Now your SPF record has unnecessary entries that could push you toward the 10 DNS lookup limit.
• Using a shared IP without checking its reputation. Shared IP pools on entry-level plans at any ESP mean your sender reputation is partially influenced by other senders on that pool. If the pool is abused, your delivery suffers. Worth the upgrade to a dedicated IP once you're sending 10k+ emails/month consistently.
• Setting Reply-To to a monitored alias and then ignoring it. The header is correct; the process is broken. Not a technical problem — still a real one.

Your DMARC record sitting at p=none is like having a security camera with no recording. You can see what's happening, but nothing stops it.

Common deliverability principle, widely cited by M3AAWG practitioners

Quick Reference: Email Header Fields Cheat Sheet

• From: Display sender — can be spoofed
• Return-Path: Envelope sender — harder to fake
• Reply-To: Where replies route — set intentionally
• Received: Routing hops — read bottom-to-top for origin
• Message-ID: Unique identifier — use for support tickets
• DKIM-Signature: Cryptographic integrity proof
• Authentication-Results: SPF + DKIM + DMARC summary
• X-Spam-Score: Filter scoring — negative is good
• List-Unsubscribe: Required for bulk senders since Feb 2024
• Content-Type: MIME type declaration — text/plain, text/html, multipart/mixed

Email headers stopped being mysterious the day I realized they're just a paper trail. Every field answers a specific question: who sent it, where it went, whether it was tampered with, and how filters scored it. Once you can answer those four questions from a header block, you're ahead of 95% of professionals who have been sending email for decades.

If you want a tool that reads headers for you in real time — flags authentication failures, quarantines suspicious senders, and surfaces classification reasons — try Icebox free at icebox.cool. For teams dealing with email-borne phishing at scale, the time savings compound fast.