Email Header Analyzer: How to Read Your Own Headers for Deliverability

Every email that arrives anywhere carries a complete audit trail above the body text. The receiving server writes down which machines handled the message, whether authentication passed, and what its filters thought. If you are guessing why a campaign underperformed, the headers already have the answer.

How to get the raw headers

• Gmail: open the message, the three-dot menu, then *Show original*. You get the full source plus a summary table with SPF, DKIM and DMARC results.
• Outlook / Microsoft 365: open the message in its own window, *File*, *Properties*, and copy the *Internet headers* box.
• Apple Mail: *View*, *Message*, *All Headers*.
• Any client: forward the message as an attachment to yourself — forwarding inline strips the originals.

Send a test to a mailbox on each provider you care about. Gmail headers tell you nothing about how Outlook treated the same message.

The lines that actually matter

Authentication-Results

This is the receiver's verdict on who you are:

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of you@yourdomain.com designates 1.2.3.4 as permitted sender);
  dkim=pass header.i=@yourdomain.com;
  dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

Three passes is the only acceptable state for cold outreach. A dkim=none means your provider never signed the message. An spf=softfail means you are sending from an IP your SPF record does not list — common when a tool sends on your behalf and you forgot to include its mechanism.

Watch the header.from value: DMARC only passes when the visible From domain aligns with the SPF or DKIM domain. Many "SPF pass but DMARC fail" cases are pure alignment problems, not authentication problems.

Received

The Received lines read bottom to top: the oldest hop is last. Each one carries a timestamp, so subtracting them gives you real queue delay:

Received: from mail.yourdomain.com (1.2.3.4) by mx.google.com; Tue, 14 Oct 2026 09:12:04 -0700
Received: from app-sender-7 (10.0.0.9) by mail.yourdomain.com; Tue, 14 Oct 2026 09:12:01 -0700

Three seconds is healthy. Minutes of gap between your own MTA and the recipient's edge usually means greylisting or throttling — the receiver is deliberately slowing you down because your reputation is thin.

X-Spam and provider-specific headers

Servers running SpamAssassin add X-Spam-Status with a score and the rules that fired. Rule names are self-documenting once you see them: URI_HEX, HTML_IMAGE_ONLY_28, DKIM_ADSP_NXDOMAIN. Microsoft adds X-Microsoft-Antispam with a BCL (bulk complaint level); anything above 4 means Microsoft considers you bulk mail and will treat you accordingly.

Return-Path and Reply-To

Return-Path is where bounces go — if it does not point at a mailbox you monitor, you are flying blind on hard bounces. A Reply-To that differs from From is a mild spam signal on its own and a strong one when the domains differ.

A five-minute triage routine

1. Read Authentication-Results. Anything other than three passes, stop and fix that first.
2. Confirm DMARC alignment against header.from.
3. Diff the Received timestamps for throttling.
4. Check the spam score and, more useful, the rule names.
5. Confirm Return-Path lands somewhere you read.

Only after all five are clean is it worth blaming copy, list quality or send volume.

What headers cannot tell you

Headers describe one message to one mailbox. They do not tell you which folder it landed in — Gmail stamps the same INBOX label on Promotions as on the primary tab — and they say nothing about aggregate reputation over time. For placement you need seed inboxes across providers; for reputation you need a daily trend. MailPilot runs both continuously so the header read becomes a confirmation step rather than your only instrument.