Methodology, sources and tests

How an analysis works

1. Find the header block. The paste is split at blank lines and the block with the most recognisable header fields is used, so a whole message source, a Gmail "Show original" page copied with its summary table, or an mbox file all work. Input is capped at 1,000,000 characters and 3,000 fields.
2. Unfold folded lines (a line break followed by a space or tab is removed, RFC 5322 §2.2.3) and decode encoded-words in names and subjects (RFC 2047: B and Q encodings, any charset the browser knows).
3. Parse each field with small hand-written scanners that understand quoted strings and nested comments (RFC 5322 §3.2.2): addresses, dates (including the obsolete forms of §4.3: two-digit years, named zones like EST and PDT), Received clauses (from, by, with, id, for and the date after the last semicolon, RFC 5321 §4.4), Authentication-Results (RFC 8601), ARC (RFC 8617), Received-SPF (RFC 7208 §9.1) and DKIM-Signature tags (RFC 6376 §3.5). Every scanner is linear: no regular expression can backtrack over a long field.
4. Route. Received fields are read bottom-up, every timestamp is converted to UTC, and the gap between consecutive hops is computed. Gaps of 5 minutes or more are highlighted, an hour or more in red; a hop that seems to go back in time by more than 2 minutes is labelled clock skew. The last hop where the sending and receiving hosts belong to different organisations is marked as where your provider took the message in: its IP address was observed by the receiving server, unlike anything below it.
5. Authentication. Only the topmost Authentication-Results field's server (the authserv-id) is treated as your provider; fields from other servers lower down are listed separately, because a sender can write anything there (RFC 8601 §5). Microsoft 365 writes its field without a server name; when such a field is on top it is used too.
6. Alignment. The From domain is compared with the domain SPF checked (smtp.mailfrom, else Received-SPF's envelope-from, else Return-Path) and each DKIM signing domain (header.d). Relaxed alignment means the same organisational domain, strict means identical (RFC 9989 §3.2.10).
7. Red flags and verdict from the rules below.

What it can't do

• No network. The page's security policy (connect-src 'self') only lets it load its own files, and the analyser makes no requests at all. So it can't look up SPF, DKIM or DMARC records or verify signatures itself. It reports what the receiving server recorded at delivery time, which is the evidence that matters: records can change afterwards.
• Organisational domains are approximate. DMARC (RFC 9989 §4.10) now finds the organisational domain with a DNS "tree walk"; without DNS, MailDingo uses the Public Suffix List, as the original DMARC specification (RFC 7489 §3.2) did. For ordinary domains the answer is identical.
• It can't see strict-mode or policy records. Alignment is shown in relaxed mode with a note; a domain may require strict alignment.
• Headers below your provider's can be forged. The tool says which parts were written by whom, but it can't prove the lower Received lines are true.
• A compromised real account passes everything. No header analysis can detect a genuine mailbox used by an intruder.

Red-flag rules

Verdict: any high flag gives Suspicious. Otherwise a DMARC pass (or, with no DMARC result, an aligned SPF or DKIM pass) and no medium flags gives Looks genuine; with medium flags, Check carefully. No authentication data at all gives Can't tell.

Look-alike detection

Domains are decoded from punycode, then each character is mapped through the Unicode confusables data (Unicode Technical Standard #39, version 18.0.0), keeping the 1,787 mappings whose target is one to three ASCII letters or digits, plus Unicode compatibility decomposition (so fullwidth ｅ becomes e). This is a simplified skeleton: real UTS #39 also maps multi-character sequences and non-Latin targets. On top of that, the common ASCII swaps rn→m, vv→w, cl→d, 0→o, 1→l and 5→s are folded. Mixed-script detection checks Latin, Cyrillic, Greek, Armenian, Cherokee, Han, Arabic and Hebrew per label (UTS #39 §5.1, simplified).

Sending-service rules

A host, DKIM signing domain, Return-Path or Message-ID domain that equals or ends in one of these domains names the service. It's a static, documented table, not a guess: a name not on it is simply not identified.

Test results for this build

Every weekly build runs the test suite under Node.js v20.19.2 against the exact mailcheck.js file your browser downloads. If any test fails, the build stops and the previous version of the site stays online. Run on 2026-11-01.

Hostile input

Each case must be parsed and rendered in under 3 seconds without throwing, and the output must contain no unescaped markup. Times from this build:

Plain-English explanations, checked against the RFCs

Each one-line explanation the analyser shows was written from, and checked by hand against, the section that defines the result. The list of result codes is read from IANA's registry every week; the build fails if a registered code for these methods has no explanation.

Sources and licences

• IETF RFCs (rfc-editor.org): the facts in every guide, cited by section. Text is our own.
• Public Suffix List, version 2026-10-31_14-17-28_UTC, Mozilla Public License 2.0. Served unmodified in content (reformatted as JSON) at /static/data/psl.json; original at publicsuffix.org; licence text.
• Unicode confusables.txt, version 18.0.0, Unicode License v3 (permits commercial use with the notice). A filtered subset is served at /static/data/confusables.json; licence and copyright notice.
• IANA Email Authentication Parameters registry, updated 2026-05-22, dedicated to the public domain (CC0 1.0) by IANA and the IETF Trust.
• Data last refreshed: psl 2026-11-01, confusables 2026-11-01, iana 2026-11-01.
• Example messages are invented and use reserved names (RFC 2606, RFC 6761) and documentation addresses (RFC 5737, RFC 3849). Real provider hostnames appear only to show what their headers look like.
• Mail-client menu paths in the "find the headers" guides were checked against each vendor's own help pages where available; where a vendor doesn't document a step, the guide says so.
• The dingo and all illustrations are original drawings made for this site.