How to Read Email Headers: Received, SPF, DKIM and DMARC

To read email headers, open the message's full source, then read the Received: lines from the bottom up to see each server the message passed through. Next, find the Authentication-Results: header added by your own provider: it shows whether SPF, DKIM and DMARC passed, and for which domain. Mismatched domains or a DMARC fail are the classic signs of spoofing.

Headers are long and messy, so paste them into our free email header analyzer. It runs entirely in your browser and nothing is uploaded. It lays out each hop with the delay between them and pulls out the authentication results and spam scores. The rest of this guide explains what you're looking at, so you can trust your own reading of it.

AI Automation for Law Firms, Explained Step by Step · 3:08 Subscribe

How to view full headers

Gmail (web)

1. Open the message.
2. Click the three-dot More menu next to the reply arrow.
3. Choose Show original.

Gmail shows a summary box at the top with SPF, DKIM and DMARC results, then the raw message below. Copy to clipboard grabs the whole thing.

Outlook

Per Microsoft's instructions:

• New Outlook for Windows, Outlook on the web and Outlook.com: open the message, select More actions (three dots), then View > View message details.
• Classic Outlook for Windows: double-click the message to open it in its own window, then File > Properties. The headers are in the Internet headers box. Click inside, press Ctrl+A then Ctrl+C.

Apple Mail (Mac)

• View > Message > All Headers shows headers above the message.
• View > Message > Raw Source (Option-Command-U) shows the complete message, which is easier to copy.

Phones

The Gmail, Outlook and Apple Mail apps on phones don't show full headers in a useful way. Open the message on a computer or in webmail instead.

The anatomy of a header block

Here's a trimmed example of a message from a fictional supplier, as received by a Gmail user. IPs are from the documentation ranges.

Delivered-To: accounts@example.com
Received: by 2002:a05:6a10:8f0c with SMTP id ...;
        Tue, 20 Oct 2026 09:14:07 -0700 (PDT)
ARC-Authentication-Results: i=1; mx.google.com; ...
Authentication-Results: mx.google.com;
       dkim=pass header.i=@supplier.com header.s=s1 header.b=Kp3x...;
       spf=pass (google.com: domain of bounces@mail.supplier.com designates 198.51.100.20 as permitted sender) smtp.mailfrom=bounces@mail.supplier.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=supplier.com
Received: from mta20.mailplatform.example (mta20.mailplatform.example. [198.51.100.20])
        by mx.google.com with ESMTPS id ...
        for <accounts@example.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384);
        Tue, 20 Oct 2026 09:14:06 -0700 (PDT)
Received: from app01.internal (unknown [10.20.0.5])
        by mta20.mailplatform.example with ESMTP id ...;
        Tue, 20 Oct 2026 16:14:02 +0000
DKIM-Signature: v=1; a=rsa-sha256; d=supplier.com; s=s1; ...
Return-Path: <bounces@mail.supplier.com>
From: "Supplier Ltd Accounts" <accounts@supplier.com>
Reply-To: accounts@supplier.com
To: accounts@example.com
Subject: Invoice 4471
Date: Tue, 20 Oct 2026 17:14:01 +0100
Message-ID: <20261020161401.abc123@supplier.com>

There's a lot here, but you only need a handful of fields.

Reading the Received chain

Every mail server that handles a message adds a Received: line to the top of the headers. So the newest hop is at the top and the original sender is at the bottom. To follow the journey, read from the bottom up.

Each line has the same basic shape, defined in RFC 5321:

• from: the server that handed the message over, as it named itself, followed in brackets by the hostname and IP the receiving server actually saw.
• by: the server that received it and wrote the line.
• with: the protocol. ESMTPS means the hop was encrypted with TLS.
• Date and time: when this server received it.

In the example, reading upwards:

1. An internal app server (10.20.0.5, a private address) handed the message to the supplier's sending platform mta20.
2. mta20 at 198.51.100.20 connected to Gmail's mx.google.com over TLS 1.3.
3. Gmail moved it internally to the mailbox.

Which Received lines can you trust?

Only the ones added by servers you trust. Your own provider's lines are reliable. The first line your provider added is the key one, because the IP in its from brackets is the one that really connected, and that IP can't be faked.

Everything below that line was written by the sender's own systems, and a spammer can put anything they like there. Fake Received: lines pretending a message came from a bank's servers are a common trick. So when you need the true sending IP, for example to check whether a server is blacklisted, take it from your provider's first hop, then look it up with our blacklist checker or at check.spamhaus.org.

Spotting delays

Compare the timestamps on consecutive hops. The analyzer does this for you, but by hand:

• Convert each time to UTC first. In the example, 16:14:02 +0000, 09:14:06 -0700 and 17:14:01 +0100 are all within five seconds of each other.
• A gap of seconds is normal. A gap of minutes or hours on one hop shows where the message sat in a queue.
• A long gap at the sender's first hop usually means their system queued or throttled it. A long gap entering your provider often means your provider gave the sender a temporary error first (greylisting or rate limiting), and the sender retried later.
• Small negative gaps happen when servers' clocks disagree. Ignore a second or two.

If customers complain that your emails arrive late, ask one of them to send you the headers of a late message. That pinpoints which hop caused the delay.

Authentication-Results: the verdict

The Authentication-Results: header, defined in RFC 8601, records what the receiving server concluded. It starts with the name of the server that did the checks (mx.google.com above). Only trust the one added by your own provider. A sender can insert a fake one further down, but providers remove or ignore results that claim to be from them.

Notice that in the example SPF passed for mail.supplier.com, the bounce subdomain used by the sending platform, not for supplier.com. DMARC still passed because DKIM passed for supplier.com, matching the From address. That's normal for messages sent through newsletter and CRM platforms.

Values you'll see besides pass:

• fail: the check ran and failed. For SPF, softfail means the record ends in ~all.
• none: there was nothing to check, for example no DKIM signature or no DMARC record.
• temperror / permerror: a DNS timeout, or a broken record. An SPF permerror often means too many DNS lookups.

If DMARC failed on your own mail, our guide to what DMARC fail means walks through the fixes. If DKIM failed, check the selector from header.s= with our DKIM checker, and see how to find your DKIM selector.

ARC headers on forwarded mail

ARC-Authentication-Results, ARC-Message-Signature and ARC-Seal appear when a message has passed through a forwarder or mailing list that recorded the original authentication results (RFC 8617). If a forwarded message fails DMARC but the ARC results show it passed originally, the receiver may still deliver it. Our ARC guide explains how that works.

Spotting spoofing and phishing

Most fake emails give themselves away in the headers. Check these in order:

1. DMARC result. dmarc=fail with header.from= showing your bank, your supplier or your own domain is a strong warning sign.
2. From vs Return-Path. Different domains aren't automatically suspicious, since mail platforms use their own bounce domains. But a From of a tax authority domain such as irs.gov or hmrc.gov.uk with a Return-Path at a random free webmail domain is.
3. From vs Reply-To. A Reply-To at a different domain sends your answer somewhere else. This is the core of most invoice-fraud emails.
4. Display name tricks. "HSBC Security" <alerts@hsbc-secure-verify.example> passes every check, because the attacker owns that domain. Authentication proves who sent it, not that they are who they claim to be.
5. The real connecting IP. Take it from your provider's first Received: line and check who owns it.
6. Lookalike domains in header.d= or smtp.mailfrom=, such as supp1ier.com.

If someone is spoofing your own domain, a strict DMARC policy is the fix. See how to stop scammers spoofing your email domain.

Spam score headers

Providers often leave their filtering verdict in the headers:

• X-Spam-Status and X-Spam-Flag: added by SpamAssassin, common on cPanel hosting. X-Spam-Status: Yes, score=7.2 required=5.0 lists the rules that fired.
• SCL (spam confidence level), shown in X-MS-Exchange-Organization-SCL and inside X-Forefront-Antispam-Report: a value from -1 to 9, where 5 or higher generally means the message was considered bad. Microsoft now says SCL no longer decides the verdict in Microsoft 365 on its own, so read it as a hint.
• X-Forefront-Antispam-Report: Microsoft's fuller verdict. CAT shows which filter category caught the message and SFV shows the spam filter verdict.

When your own messages land in junk, these headers are the fastest way to find out why. Combine them with our guide on why emails go to spam.

Other useful fields

• Message-ID: a unique identifier. The domain part normally belongs to the sending system. Useful for asking a provider to trace a specific message.
• Date: set by the sender's software, so it can be wrong or faked. Trust Received: timestamps from your own provider more.
• DKIM-Signature: shows the signing domain (d=) and selector (s=). One message can carry several signatures, for example one from your domain and one from the platform.
• Received-SPF: an older way some servers record the SPF result. It says the same thing as the spf= part of Authentication-Results.

Privacy when sharing headers

Headers can include internal server names, private IP addresses, and sometimes the sender's own public IP. Be careful about pasting them into online tools that upload them. Our email header analyzer parses everything inside your browser and sends nothing to our servers. If you're sending headers to a support team, that's fine, but don't post them in public forums without removing addresses first.

FAQ

Should I read the Received headers from the top or the bottom?

From the bottom. Each server adds its line on top of the previous ones, so the bottom line is the oldest and the top line is the newest. Reading upwards follows the message from sender to your inbox.

Can email headers be faked?

Partly. The sender can forge anything added before the message reached your provider, including fake Received: lines and a fake Authentication-Results. The lines your own provider added, including its authentication verdict and the connecting IP, can be trusted.

What does "spf=pass" but "dmarc=fail" mean?

SPF passed for the envelope sender domain, but that domain didn't match the From address you can see, and DKIM didn't pass for a matching domain either. It's common with misconfigured mail platforms, and also how many spoofing attempts look.

Why does Gmail show "via" next to the sender name?

Gmail shows "via" when the domain that signed or sent the message differs from the From domain. Setting up DKIM signing with your own domain on the sending platform usually removes it.

How can I tell if an email was delayed?

Compare the timestamps on consecutive Received: lines after converting them to the same time zone. A gap of minutes or hours on one hop shows where the message waited, and the server names either side of the gap tell you whose system caused it.

Is it safe to paste email headers into an online analyzer?

It depends on the tool. Headers can reveal internal hostnames and IP addresses. Our email header analyzer runs entirely in your browser, so the headers never leave your computer.