A header block is a record of claims, some of them verified by somebody and some of them simply asserted. Reading it usefully means knowing which is which.
Each server prepends a line as it hands the message on, so the chain reads backwards. This tool renumbers it into travel order and works out how long each hop took.
Only the lines added above your first trusted hop are reliable. A sender writes everything below.
The receiving server records what SPF, DKIM and DMARC said when it handled the message. It is usually right, and it cannot be repeated now: the body and that day’s DNS are both gone.
What can be re-checked is the domain’s current configuration.
Three different senders, and they routinely differ for honest reasons. The envelope sender takes the bounces, the From is what the recipient sees, and Reply-To decides where a reply goes.
Invoice fraud lives in the gap between the second and the third.
SPF, DKIM and DMARC authenticate domains. None of them authenticates the name your mail client displays.
A message whose From header reads "billing@yoursupplier.com" <accounts@unrelated.tld> passes DMARC — on unrelated.tld, which the sender owns and has configured properly. Most mail clients show only the display name, and the display name here is an email address at somebody else’s domain. There is no DNS record anyone can publish to prevent this, because nothing is being forged: the sender is telling the truth about their own domain and lying in a free-text field.
The same trick works with a lookalike domain — one character different, or a different top-level domain — and with a Reply-To that points somewhere other than the From. Both are visible in the headers and neither is visible in the reading pane, which is why this page reports them as findings of their own rather than as part of the authentication summary.
The defences are not technical in the way the acronyms suggest. Publishing a strict DMARC policy on your own domain stops people sending as you, which is worth doing and is what the email security checker measures. Stopping people sending at you with a convincing display name is a matter of inbound rules and of what your finance team does before changing a bank account.
| Result | What it means | What to make of it |
|---|---|---|
| spf=pass | The sending server was listed in the envelope domain’s SPF record. | Says nothing about the visible From address, which SPF never checks. |
| spf=softfail | The domain publishes ~all: probably not authorised, do not reject on it alone. | Common leftover from a migration. Worth fixing on your own domain. |
| dkim=pass | The signature verified, so the signing domain vouches for the message and it arrived intact. | Check which domain signed. A mailing list signing its own forward is not the author vouching. |
| dmarc=pass | SPF or DKIM aligned with the domain in the From header. | The strongest statement here, and still only about the domain — not the display name. |
| dmarc=fail | Neither aligned. | Either a forgery or a forwarder that broke alignment. The path tells you which. |
| compauth=fail | Microsoft’s composite verdict, combining the above with its own reputation signals. | What actually drives Exchange Online’s anti-spoofing action. |
In Gmail, open the message, use the three-dot menu and choose 'Show original'. In classic Outlook, File → Properties shows them in the 'Internet headers' box. In new Outlook and Outlook on the web, the three-dot menu has 'View message details'. In Apple Mail, View → Message → Raw Source. The Subject and From lines shown in the reading pane are not enough — what matters is the Received and Authentication-Results lines, and those are only in the raw source.
The ones at the bottom of the chain, yes, completely. Each server adds its own Received line at the top, so the order is newest first. Everything below the first line added by infrastructure you control was written by a machine you do not control, and a sender can invent as many plausible-looking hops as it likes. This is why the analysis here is explicit about which part of the chain carries weight: the top. Forged lines are added to make a message appear to have come from somewhere reputable, and they are convincing if you read the chain as a single trustworthy record.
It means the domain in the envelope was authorised to send, and that the message was signed by the domain claimed in the signature and arrived unmodified. It does not mean the message is honest. An attacker who registers a lookalike domain passes SPF, DKIM and DMARC on their own domain perfectly — the authentication is real and the domain is theirs. It also says nothing about the display name, which is not covered by any of these checks and is the part your mail client shows you.
Usually greylisting — the receiving server temporarily refuses the first attempt from an unknown sender and accepts the retry, which costs whatever the sending server's retry interval is. Queue backlogs and content scanning look the same. Bear in mind the delay is computed from two different servers' clocks, so a few seconds either way is meaningless, and a negative delay means one of the clocks is wrong rather than that something was tampered with.
It limits the signature to the first n bytes of the message body. Anything appended beyond that point is unsigned, so a message can be modified in transit — content added to the end — and still verify as authentic. It exists for mailing lists that append footers, and it is a bad trade: RFC 6376 permits it and security guidance has recommended against it for years. If your own signing configuration sets it, remove it.
No. The parser is JavaScript that runs in your browser, and this page is a static file with no server behind it to receive anything. You can disconnect from the network after the page loads and it will still work. That matters here more than for most tools: headers contain recipient addresses, internal hostnames, internal IP addresses and message identifiers, and every other analyser on the web posts all of it to somebody's server.
Getting to an enforced DMARC policy means finding every system that sends as you — the CRM, the invoicing platform, the scanner in the corner — and authorising them before you tell the world to reject the rest. We do that migration, and then the inbound side that display-name spoofing walks straight past.