desktest.net
GitHub

Email Header Check Guide

A reference for the desktest.net Email Header Check. The tool takes the raw source of a suspicious email, parses the headers in your browser, and flags the signals that separate a real message from a phishing or business-email-compromise attempt. It never uploads the email, never renders the body, and shows every link defanged so you can inspect it without any risk of clicking it.

Open the Email Header Check ->

Getting the raw email source

The tool needs the raw source of the message, not the pretty rendered view. The raw source is the full text that starts with lines like Received:, From:, Authentication-Results:, and Subject:. Those header lines are where all the spoofing evidence lives.

Microsoft Outlook (new Outlook and outlook.com)

  1. Open the suspicious message (a single click to select it is enough; you do not have to fully trust it to view its source).
  2. Click the ... (More actions) menu at the top of the message, then View > View Source (older desktop Outlook: File > Properties, then copy the Internet headers box).
  3. Select all of the text and copy it.
  4. Paste it into the Email Header Check and click Analyze.

Gmail

  1. Open the message.
  2. Click the three-dot More menu at the top right of the message, then Show original.
  3. On the "Original Message" page, click Copy to clipboard (this copies the full raw source, headers and body).
  4. Paste it into the tool and click Analyze.
If you only have the headers, that is fine. The most important signals (SPF/DKIM/DMARC and the address mismatches) live in the headers. If you paste the full original, the tool can also extract and defang links from the body. Either way the message body is never rendered.

What SPF, DKIM, and DMARC mean

These three are the receiving mail server's verdict on whether the message really came from the domain it claims. The results are already written into the headers by the server that delivered the mail (usually in an Authentication-Results: line). This tool reads those results. It does not perform any DNS lookups of its own, so the answer you see is exactly what the delivering server decided.

CheckWhat it provesA "pass" means
SPFThe sending server's IP is authorised to send for the envelope domain.The mail came from a server the domain owner listed.
DKIMThe message carries a valid cryptographic signature from the signing domain and was not altered in transit.The content is intact and signed by the claimed domain.
DMARCSPF or DKIM passed and the passing domain lines up (aligns) with the visible From domain.The From address you see is really authorised by that domain.

Common result words and how the tool colours them:

DMARC is the one that matters most for spoofing. A message can pass SPF and DKIM for some unrelated domain and still be forging your bank. DMARC is what ties the authentication back to the From address you actually see, which is why a DMARC that is anything other than pass on a message claiming to be a big brand is such a strong red flag.

Reading the spoofing indicators

Beyond the authentication results, the tool compares the addresses in the headers and flags classic forgery patterns. Each indicator is labelled High, Medium, or Low.

From vs Return-Path (envelope) mismatch

The From is what you see; the Return-Path (envelope sender) is where bounces go and is what SPF is actually checked against. Legitimate bulk senders (newsletters, ticketing systems) routinely differ here, so on its own this is a Medium signal. Combined with a failing SPF or DMARC it becomes meaningful.

From vs Reply-To mismatch

This is the classic business-email-compromise tell. The mail is dressed up to look like it is from your CEO or a known vendor, but the Reply-To quietly points at an address the attacker controls, so your reply never reaches the real person. The tool flags this High when the reply domain does not line up with the From domain.

Display-name and lookalike impersonation

The From display name says "PayPal Security" or "Microsoft 365" but the actual address is at some unrelated domain. The tool carries a small table of well-known brands and flags High when a message presents as one of them but is not sent from that brand's real domain. It also flags when the display name literally contains a domain that differs from the sending domain.

DMARC did not pass while presenting as a brand

Real mail from PayPal, Microsoft, banks, and the like publishes and passes DMARC. When a message looks like one of those brands but DMARC is anything other than pass, that combination is one of the strongest forgery signals there is, so the tool flags it High.

A clean pass is not a promise of safety. Passing SPF, DKIM, and DMARC proves the message really came from the domain it claims. It does not prove the request inside is legitimate: a genuinely malicious sender, or a real account that has been compromised, still passes authentication. If the message makes an unusual request (a new bank account, an urgent wire, a password reset you did not start), verify it through a channel you already trust regardless of the verdict.

Why links are shown defanged

Every URL and email address the tool pulls out of the message is defanged before it is displayed: http becomes hxxp, each . becomes [.], and @ becomes [at]. So https://login.paypa1.com/verify is shown as hxxps://login[.]paypa1[.]com/verify. Defanged text is inert: it cannot be clicked, your browser will not auto-link it, and nothing about displaying it reaches out to the attacker's server.

This is why inspecting a suspicious email here is safer than opening it in your mail client:

Read the defanged links carefully. Phishing relies on lookalike domains: paypa1[.]com (a digit one), micros0ft[.]com (a zero), or a real brand buried in a subdomain of an unrelated site such as paypal[.]com[.]secure-login[.]ru. The registrable domain is the last two labels before the country/TLD, so in that last example the real destination is secure-login[.]ru, not PayPal.

For IT admins

This tool is a fast triage step you can hand to front-desk and help-desk staff. When someone forwards you "is this real?", have them paste the original into the page and read you the verdict and the indicators, or use Copy Diagnostic Report to paste a plain-text summary (links already defanged) into your ticket. Because it runs entirely client-side, there is no data-handling or retention concern in routing suspected phishing through it.

What it deliberately does not do:

Because the whole thing is one static page with no third-party scripts, no analytics, and no network calls, it works from an air-gapped or heavily filtered workstation as long as the page itself loaded. There is nothing to allow-list for the analysis to run.

Behind the scenes

The parser unfolds RFC 5322 continuation lines (a header value can wrap across several indented lines) and splits the message at the first blank line so the body is separated from the headers. It then pulls out From, Reply-To, Return-Path, To, Subject, Date, Message-ID, and every Received: hop. Received headers are prepended by each server the mail passes through, so the tool reverses them to show the path origin-first and reports the originating server and IP from the earliest hop.

Address comparison uses the registrable (organizational) domain, so mail.paypal.com and paypal.com are treated as the same organisation while paypal.com and paypa1.com are not. A small set of multi-label public suffixes (co.uk, com.au, and similar) is handled so those are compared correctly.

Everything above happens with plain JavaScript string operations on the text you pasted. There is no fetch, no XMLHttpRequest, no WebSocket, and no remote image in the tool's code. The strict Content-Security-Policy on the page (default-src 'none' with no connect-src) means the browser would block any network request even if one were somehow attempted. View the page source to confirm.

Elsewhere on the web: