How to Read Email Headers to See Why a Message Was Flagged

Every email carries a hidden log of where it came from and what each server thought of it. When a message is flagged as spam, suspicious or spoofed, the headers usually say exactly why. This guide shows how to open them in each app and how to read the handful of lines that matter.

Quick summary

• Gmail: open the message, three dots, Show original. The top summary already shows SPF, DKIM and DMARC results.
• Outlook desktop: open the message in its own window, File, Properties, then read the Internet headers box. In new Outlook and Outlook.com: three dots, View, View message source.
• Apple Mail: View, Message, All Headers, or Raw Source for everything.
• Thunderbird: View, Headers, All, or More, View Source (Ctrl+U).
• Most webmail: a menu entry such as View source, Show headers or Download .eml. Open the .eml in a text editor if the app shows nothing.

How to open the headers

• Gmail: open the message, three dots, Show original. The top summary already shows SPF, DKIM and DMARC results.
• Outlook desktop: open the message in its own window, File, Properties, then read the Internet headers box. In new Outlook and Outlook.com: three dots, View, View message source.
• Apple Mail: View, Message, All Headers, or Raw Source for everything.
• Thunderbird: View, Headers, All, or More, View Source (Ctrl+U).
• Most webmail: a menu entry such as View source, Show headers or Download .eml. Open the .eml in a text editor if the app shows nothing.

The lines to look for

• authentication (proof that email really comes from your company)-Results: added by the receiving server. It lists SPF (Sender Policy Framework — a list of servers allowed to send email as your domain)=, DKIM (a digital signature that proves your email was not tampered with)= and DMARC (a policy that tells providers what to do if someone fakes your domain)= with pass, fail, none, softfail or temperror. This single header answers most "why was it flagged" questions.
• Received: one per server hop, newest at the top. Read bottom to top to trace where the message really originated. The bottom-most Received shows the first server, often with an IP address.
• Return-Path: the envelope sender, where bounces go. If it is a different domain from the From address, SPF is being checked against that domain, which is why SPF can pass while DMARC fails.
• From: the visible sender. Compare the domain here with header.d= in the DKIM result and with the Return-Path domain; DMARC needs one of them to match.
• DKIM-Signature: d= is the signing domain, s= is the selector. If d= is a third-party service rather than your domain, your DKIM is not aligned.
• X-Spam-Status or X-Spam-Score: many receivers add their spam verdict and sometimes the rules that fired.

Reading a real example

Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourdomain.com header.s=oqumail header.b=abc123;
  spf=pass (google.com: domain of jane@yourdomain.com designates 203.0.113.5 as permitted sender) smtp.mailfrom=jane@yourdomain.com;
  dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

What each failure usually means

• spf=fail or softfail: the server that sent the message is not in the domain's SPF record. Either the record is missing a sender, or the message is forged. For your own mail, check the record matches your host (OquMail: v=spf1 MX (Mail Exchanger — where incoming email is delivered) a:mail.oqumail.com ~all).
• spf=permerror: the SPF record is malformed or has more than ten DNS lookups. Fix the record; every receiver treats permerror as a fail.
• DKIM (a digital signature that proves your email was not tampered with)=none: the message was not signed at all. Common with contact forms, scanners and misconfigured plugins. Route those through your real mail host or its API.
• DKIM (a digital signature that proves your email was not tampered with)=fail: signed, but the signature does not verify, usually because the DNS record is truncated or the message was altered in transit by a forwarder or a mailing list.
• DMARC (a policy that tells providers what to do if someone fakes your domain)=fail: neither SPF nor DKIM aligned with the From domain. If the domain's policy is p=reject, the message may never arrive at all.
• dmarc=none with a pass on SPF and DKIM: fine, it means the domain publishes no DMARC policy. Add one.

Tracing forged mail

If a message claims to be from your own domain and you did not send it, read the bottom Received line for the originating IP, note SPF (Sender Policy Framework — a list of servers allowed to send email as your domain)=fail and DKIM (a digital signature that proves your email was not tampered with)=none in authentication (proof that email really comes from your company)-Results, and include those lines when you report it. Then tighten your DMARC policy to p=quarantine or p=reject so receivers discard such forgeries automatically. OquMail's guided DMARC setup starts you at p=none so you can review reports before tightening.

Common questions

Why are there several Authentication-Results headers?

Each server that handled the message can add one. Trust the one added by the final receiver (the top-most, from the recipient's provider). Earlier ones may refer to a forwarding hop.

Can I paste headers into a tool instead of reading them?

Yes. Google's Messageheader tool in the Admin Toolbox and Microsoft's Message Header Analyzer both accept pasted headers and lay out the hops and results. They are useful for timing questions such as which server delayed a message.

Do the headers show if someone read my message?

No. Headers describe delivery up to the recipient's server. Whether the message was opened is not recorded, and read receipts are a separate, optional mechanism.