Email header decoder

One message, four sender fields

A paper letter has a name signed at the bottom, a return address on the envelope and a postmark added by the post office. Nothing forces the three to agree. Email works the same way, with one more field thrown in.

The “Who really sends it” block puts the four side by side and shows the registrable domain of the From address in bold. That way paypal.com.account-review.help reads as what it is, a name under account-review.help.

The verdict your own provider wrote

When a message arrives, the receiving service (Gmail, Outlook, your company’s server) tests it and writes the outcome in an Authentication-Results header at the top. This tool doesn’t redo those tests. It reads that header, because it’s the one line the sender had no way to write.

spf=pass

The connecting server is on the list published by the Return-Path domain.

dkim=pass

A cryptographic signature covers the message and it still verifies, so the content wasn’t altered. The d= value names the domain that signed.

dmarc=pass

At least one of the two passed and its domain matches the one in From.

If there are several Authentication-Results headers, only the topmost counts. The others were added earlier on the route and could have been forged. When there’s none at all, the tool falls back to the newest ARC-Authentication-Results, then to Received-SPF.

The signals the decoder looks for

Signals are sorted into three levels. A single red one is enough for the overall “Strong warning signs”, and yellow gives “Be careful”.

• Display name against address. A name that contains a different email address, or that names a brand from our list while the address sits on another domain. It’s red when that address is a free mailbox such as gmail.com.
• Sender domain. Mixed alphabets, invisible characters, or a spelling within one or two letters of a known brand. These are the same tests the lookalike character detector runs.
• Reply-To on a free mailbox while the message claims to come from an organization’s domain. That’s the pattern behind fake invoices and the “urgent request from the director”.
• Failed checks. dmarc=fail is red. SPF fail or softfail and an invalid DKIM signature are yellow, because honest forwarding and mailing lists cause them too.
• Filter marks. Microsoft’s spam confidence level (SCL) of 5 or more, a category such as PHSH or SPOOF, compauth=fail, or an X-Spam-Flag: YES.

If you paste the whole message, or drop the .eml file, the body gets parsed as well, without being displayed and without anything being loaded from it. Links are grouped by real destination domain, once Microsoft Safe Links, Proofpoint and Google redirects have been unwrapped. A link whose visible text names one site while its address leads to another is red. Attachments are judged by extension: programs and scripts, double extensions such as invoice.pdf.exe, HTML pages, Office files with macros.

Reading the route

Every server that handles a message adds a Received line above the ones already there. The decoder flips them into chronological order and shows, for each hop, which machine handed the message to which, whether the link was encrypted with TLS, and how long the hop took. Any delay over an hour is highlighted.

The “origin server” is the first public IP address on the route, and it deserves some suspicion. The earliest hops are written by the sender’s own machines, so they can be made up. The last hops, added by your provider, are the ones you can rely on. For mail sent from a webmail service, the origin is that service’s server, not the writer’s home connection.

Headers can’t tell you whether a real account was taken over. A message sent from a colleague’s hacked mailbox passes every check here. So when a message asks for money, a password or a change of bank details, confirm through a channel you already trust, such as a phone number you had before the message arrived.