Email Header Analyzer

About the Email Header Analyzer

Email headers record a message’s journey: every server it passed through, and what your provider found when it checked who sent it. This analyzer reads them in your browser and puts them into plain language — the delivery path from the first server to your mailbox with the time each step took, the SPF, DKIM, DMARC and ARC results your provider recorded, and whether the From, Reply-To, Return-Path and Sender addresses agree.

It then points out the usual signs of a forged or phishing email: a display name that shows a different address, a sender domain that imitates a known brand or uses look-alike letters, replies that go somewhere else, failed or missing authentication, dates that do not fit the path, weak DKIM signatures, and the verdicts that Microsoft 365 and SpamAssassin wrote into the message. Nothing is uploaded or looked up: the headers stay on your device.

Common uses

• Checking a message that claims to be from your bank, the tax department, a courier or your employer before you act on it.
• Finding out why an email arrived late, or which servers and services handled it.
• Checking that your own domain’s mail passes SPF, DKIM and DMARC at Gmail or Microsoft 365 after a DNS change.
• Triaging phishing reports in an IT or security team, and attaching a plain-text report to the ticket.

Reading the delivery path

Every mail server that handles a message adds a Received line at the top (RFC 5321, section 4.4), so the oldest is at the bottom. The analyzer turns them around and numbers the hops from the first server to your mailbox, with the time between steps; hop 1 is measured from the Date the sender wrote. Gaps of seconds or minutes are normal — queues, retries, greylisting and spam scanning take time — and a small negative delay usually means a server’s clock is off.

Only the Received lines added by your own provider, at the top, are certain. Anything below them was written by servers you cannot check — or by the sender, who can invent extra lines to make a message look as if it came from somewhere else.

SPF, DKIM, DMARC and ARC in plain words

• SPF (RFC 7208) asks the domain of the envelope sender (Return-Path) whether the server that delivered the message may send its mail. It says nothing about the From address you see.
• DKIM (RFC 6376) checks a signature that the domain in d= put on the message. A valid signature means the signed parts are unchanged since that domain sent it.
• DMARC passes when SPF or DKIM passed for a domain that matches the From address, so dmarc=fail means the From domain could not be confirmed. DMARC was defined in RFC 7489, which RFC 9989 replaced in May 2026.
• ARC (RFC 8617) lets forwarders and mailing lists record the results they saw before they changed the message, so a later server can decide to trust them.

The results come from the Authentication-Results header (RFC 8601) that your provider added. Trust the topmost one, which starts with your provider’s name — mx.google.com at Gmail, for example; Microsoft 365 leaves the name out. Others further down were added by earlier servers or written by the sender, so they prove nothing.

Warning signs it looks for

• Display-name tricks: a name that contains an address or domain other than the real one, or a bank’s or brand’s name on a free webmail address.
• Look-alike sender domains: brand names with swapped letters (paypa1), extra words, letters from other alphabets and one-letter typos, checked with the Public Suffix List and Unicode’s confusables data (UTS #39).
• Address mismatches: Reply-To or Return-Path at another domain, several From addresses, or a Sender acting on someone’s behalf.
• Authentication: DMARC, SPF, DKIM or Microsoft’s composite authentication (compauth) failing, missing signatures, signatures that do not cover From, rsa-sha1 signatures (no longer allowed since RFC 8301) and l= signatures that cover only part of the body (RFC 6376, section 8.2).
• Path and dates: a Date after delivery or long before the first server saw the message, a Date or Received time stamp whose weekday does not fit the date (RFC 5322 requires them to match), steps without encryption, and a missing Date or Message-ID.
• Spam filter verdicts written into the message: Microsoft 365’s X-Forefront-Antispam-Report (category CAT, verdict SFV, safety tip SFTY) and bulk complaint level (BCL), as described in Microsoft Learn’s “Anti-spam message headers”, and SpamAssassin’s X-Spam-Status.

Is the email genuine?

If DMARC passed and the From domain is exactly the one you expect — read it letter by letter — the message really was sent through that domain’s mail system. That does not make it safe: an account at that company may have been hacked, and scammers send from their own, properly configured domains too. If the headers look clean but the message asks you to pay, log in, share an OTP or open an attachment, check through the company’s own app or website instead of the email.

Limitations

• The analyzer reads what the receiving servers recorded; it does not repeat the SPF, DKIM or DMARC checks, which need the original message and the DNS records at the time of delivery. The DMARC, SPF and DKIM checkers show the records as they are today.
• Alignment between domains is estimated with the Public Suffix List, as RFC 7489 did. RFC 9989 finds the organisation’s domain with DNS lookups instead; where the two disagree, the receiving server’s own DMARC result, which is shown, is the one that counts.
• Brand checks cover a short list of often-imitated names and their domains. A domain that is not on the list is not called fake, and one that imitates no brand can still be a scam.
• Header formats differ between providers, so unusual Received lines may be read only partly. Every field is listed in full under All header fields.

Privacy

Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot.