Email header analyzer

The email header analyzer above turns the block of raw header text that every message carries into a readable report: the route from server to server with the time each hop took, the SPF, DKIM and DMARC verdicts of the receiving server, the sending IP address, and the addresses that should match but sometimes don’t. It works for Gmail, Microsoft 365 and Outlook.com, Yahoo, Apple Mail and anything else that can show the raw message. Use it to find out where a delay happened, why a message landed in spam, or whether a message really came from the company it names; for a quick check of one sender address, the scam email checker is faster.

What the email header analyzer reports

Folded header lines are joined first: RFC 5322 lets a long header continue on the next line if that line starts with a space or tab, and “unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP”. Encoded subjects and names such as =?UTF-8?B?…?= are decoded. Dates in any time zone, including the old names like EDT and PST, are converted to UTC so delays between servers in different zones come out right. Rule names in a SpamAssassin X-Spam-Status header link to their explanation in our SpamAssassin rules section.

The optional button under the report looks up the SPF and DMARC records that the From domain publishes today, with links to the full checks.

How to get the full headers

Mail apps hide most headers. You need the complete block, from the first Received: line to the last header before the message text. Copy it as one piece; if you paste the whole raw message, the analyzer ignores the body.

Google’s page covers Gmail in a browser on a computer, so use a computer if the Gmail app on your phone doesn’t offer the option. For a bounce message, analyze the headers of the original message quoted inside it; the Mail Delivery Subsystem guide explains how a bounce is built.

How to read email headers

Headers are written by different parties at different times. The sender’s software writes From, To, Subject, Date and Message-ID. Every server on the way adds trace headers on top of the existing ones: RFC 5322 §3.6.7 defines Return-Path and Received as trace fields and says they “SHOULD be kept in blocks prepended to the message”. So you read the raw text from the bottom up to follow the message, and the closer a header is to the top, the more likely it was written by your own provider rather than by someone you can’t verify.

Received: the route, hop by hop

Received: from out-25.mail.example.com (out-25.mail.example.com. [198.51.100.25])
        by mx.google.com with ESMTPS id 5b1f17b1804b1-42f9a1b2c3dsi123456f8f
        for <jane@example.org>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 08 Oct 2026 09:14:06 -0700 (PDT)

• from is the name the connecting server announced, followed in parentheses by what the receiving server found out itself: here the reverse DNS name and the IP address in brackets. If a server you trust wrote the line, that IP address is the one detail the sender could not choose.
• by is the server that wrote the line.
• with names the protocol. ESMTPS means the connection used STARTTLS, ESMTPA that the client logged in with SMTP AUTH, and ESMTPSA both (RFC 3848). Some servers write their product name here and put the TLS version in a comment; the analyzer recognizes both.
• id is the identifier the receiving server gave the message, useful when you ask that server’s administrator to look up the message in their logs.
• The date after the semicolon is when this server received the message. The difference from the line below is the delay of that hop.

Only the Received lines added by your provider and the servers it talked to directly can be trusted. Anything below the first server you don’t recognize may have been written by the sender, who can add made-up Received lines. Server clocks also drift: when a hop seems to arrive before the previous one, the analyzer marks it as clock skew instead of reporting a negative delay as a real one.

Authentication-Results: SPF, DKIM and DMARC verdicts

Authentication-Results: mx.google.com;
       dkim=pass header.i=@news.example.com header.s=s1 header.b=AbCdEfGh;
       spf=pass (google.com: domain of bounce+7f3a@mail.example.com designates 198.51.100.25 as permitted sender) smtp.mailfrom="bounce+7f3a@mail.example.com";
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=news.example.com

The receiving server records here what it checked (RFC 8601). The first word, mx.google.com, is the authserv-id of the server that did the checks. Each result names the method, the verdict and the domain it applies to:

• spf checked whether the sending IP is allowed to send for the envelope sender (smtp.mailfrom), the address that also ends up in Return-Path. fail and softfail mean it isn’t listed in that domain’s SPF record (RFC 7208 §2.6).
• dkim checked a signature; header.d or header.i is the signing domain. A fail can mean the message was changed after signing, by a forwarder or mailing list for example.
• dmarc checked whether SPF or DKIM passed for a domain that matches the From address. In relaxed mode, news.example.com matches example.com because both have the same organizational domain (RFC 9989). The comment shows the domain’s policy, p=REJECT here. More on policies in what is a DMARC record.
• compauth appears in Microsoft 365. It is Microsoft’s combined verdict for the From domain; the reason code explains it, for example 000 for a DMARC failure under a quarantine or reject policy (Microsoft’s list of reason codes).

Trust only the topmost Authentication-Results header, the one your provider added. RFC 8601 warns that “a malicious user or agent could forge a header field using the DNS domain of a receiving ADMD”, and requires servers to delete any copy that claims their own name when a message comes in. Copies further down were written before the message reached your provider. A Received-SPF header (RFC 7208 §9.1) carries the SPF result once more, with the checked IP as client-ip.

DKIM-Signature

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=news.example.com; s=s1;
        t=1791476038; h=from:to:subject:date:message-id:list-unsubscribe:list-unsubscribe-post;
        bh=…; b=…

d= is the domain that takes responsibility for the message, s= the selector, a= the algorithm, c= the canonicalization, t= the signing time and h= the list of signed header fields (RFC 6376 §3.5). The public key is a DNS record at <selector>._domainkey.<domain>, here s1._domainkey.news.example.com; the analyzer links each signature to the DKIM checker with both values filled in. It does not verify the signature itself, because that needs the exact original message, body included; the receiver’s dkim= result is the verdict that counts. The DKIM record guide explains keys and selectors.

ARC: results that survived forwarding

Forwarding breaks SPF, because the forwarding server is not in the original sender’s SPF record, and mailing lists that edit the subject or body break DKIM. The Authenticated Received Chain lets each intermediary record the results it saw, sign the message and seal the chain with three headers (RFC 8617, published as an Experimental RFC):

• ARC-Authentication-Results “records the message authentication assessment” made when the message arrived at that intermediary.
• ARC-Message-Signature is a DKIM-like signature of the message.
• ARC-Seal signs the ARC headers. Its cv= value says whether the chain was intact when the intermediary received it: none for the first set, then pass or fail.

Each set carries an instance number i= from 1 to 50. A receiver may use a passing chain from an intermediary it trusts to deliver a forwarded message despite a DMARC failure; Microsoft’s compauth reason 130 means exactly that.

Return-Path, From, Reply-To and Sender

Different domains in these fields are normal for newsletters and support desks: an email service provider uses its own bounce domain (for example bounce.esp.example) in Return-Path, and a shop may send from news.example.com with replies going to support@example.com. They matter when nothing else passes: a DMARC failure plus a Reply-To on an unrelated domain deserves a close look.

Signs of spoofing or phishing in the headers

The analyzer reports these as signals rather than giving a verdict, because each has innocent explanations too:

1. dmarc=fail in the topmost Authentication-Results. Neither SPF nor DKIM passed for the From domain. With p=reject or p=quarantine in the comment, the domain owner has said such mail is not theirs.
2. A display name that contains another address. "service@example.com" <alerts@example.net> can appear as service@example.com in apps that show only the name, while the message comes from example.net.
3. Reply-To on a different domain. The message looks like it comes from a bank or a colleague, but your answer goes to someone else.
4. A From domain that only looks right. Swapped characters (examp1e.com), extra words (example-security.com) or the real name in front of another domain (example.com.login.example.net). Run the domain through the scam email checker, which compares it with about 230 official domains of frequently impersonated brands.
5. A spam filter verdict. Microsoft 365 writes its classification into X-Forefront-Antispam-Report, for example CAT:PHSH for phishing or CAT:SPOOF for spoofing.
6. Authentication that passed for the wrong domain. SPF and DKIM can pass for any domain the sender controls. A pass only helps if the domain is the one you expect, which is why DMARC alignment matters.

A message can pass every check and still be a scam: the sender may own a look-alike domain with perfect SPF and DMARC records, or write from a real account that was taken over. Headers prove where a message came from, not what the sender intends.

When the analyzer is useful beyond phishing

• Slow delivery. The delay column shows which server held the message. A long delay at the receiving side can be greylisting or a temporary rejection; the SMTP error codes explain the replies.
• Mail in the spam folder. Check that SPF, DKIM and DMARC pass for your own domain. If they don’t, fix the records with the SPF record generator and the DMARC generator.
• Forwarding problems. A dkim=fail after a mailing list, or an ARC chain with cv=fail, shows where a message was changed on the way.