Methodology

The signals we read

Every email carries a set of routing headers that travel with it from the sender's mail server to yours. They're invisible by default but preserved in the file you save. We read them locally in your browser and evaluate four broad categories:

• Authentication: SPF (whether the sending server is authorized for the sender domain), DKIM (whether the message body and key headers are cryptographically signed), and DMARC (whether the sender domain has a published policy and the message complies with it).
• Sender alignment: whether the visible From: address matches the technical Return-Path, the DKIM signing domain, and the authentication-results domain.
• Routing: the chain of servers (Received: headers) that handled the message, working backwards to find the originating IP, including stepping past known security gateways so the real upstream sender is identified.
• MX records: for non-webmail senders, your browser may ask Google Public DNS which provider handles mail for the visible sender domain. We compare that inbound provider with the service that delivered the message.
• Domain age: for non-webmail senders, your browser may ask public RDAP when the visible sender domain was registered. New domains are treated as advisory unless they appear with sensitive business-action language and weak authentication.
• Links: the URLs in the message body, checked for visible/actual mismatches, raw IP hosts, punycode-encoded lookalikes, .cm typosquats, and known shorteners.

How we get to a verdict

We don't score-and-threshold; we apply a small set of rules that mirror how an analyst triages a phish:

• Danger if any of the high-confidence failures fire: DMARC fails, SPF fails, the sender clearly looks spoofed, or a link uses an anchor-vs-href mismatch, raw IP host, or punycode.
• Caution for ambiguous or partial signals: SPF soft-fail, DKIM fail, missing authentication, a return-path mismatch on a non-ESP message, suspicious shortener links, or no source IP at all.
• Safe when every category checks out and there's no money or credential content present.

The money & credential cap

If the message body mentions money, banking changes, wires, gift cards, credentials, or login info, we never let the verdict rise above "Caution: verify by phone." Even a perfectly-authenticated email can be malicious if an attacker has compromised a real account at a real vendor. Header analysis is structurally blind to that case. The cap is our way of being honest about that blind spot.

The forwarded-message guard

Regular forwarding replaces the original headers with the forwarder's own, which destroys the evidence we need. If we detect a forward (by subject prefix, by a forward-separator block in the body, or by a Received chain that looks like a Sent-Items export), we short-circuit with a request to use "Save Original" or "Show Original" instead. We'd rather refuse to answer than answer wrong on a forwarded phish.

What we deliberately don't do

• No spam scoring or sender-reputation blocking. We answer "is this email pretending to be something it isn't?", not "is this email welcome?" Those are different questions, and your email provider's spam filter (imperfect though it is) already handles the second one. Cold sales outreach, real newsletters you forgot subscribing to, recruiter cold-emails: those are "authentic but unwelcome," and we'll correctly call them legitimate because they are.
• No general-purpose AI content model. We use explicit, local rules for payment, credential, job, invoice, account-change, and fraud-report language. We do not send the message to a remote language model to interpret its meaning. That would break the privacy promise.
• No reputation lookups. We don't query VirusTotal, urlscan, abuse.ch, or anything else with the contents of your email. Optional DNS and RDAP lookups send only the sender domain for MX records and registration age, not the message, headers, links, or verdict.
• No tracking. No analytics, no cookies, no application logs of email content. The site is served from a CDN, with one domain-only RDAP endpoint.

Standards and fraud guidance

Authentication parsing follows the published specifications for SPF, DKIM, DMARC, and Authentication-Results. The recommendation to verify suspicious requests through a known channel matches CISA guidance.

For payment-redirection and text-only scams, read the BEC and wire-fraud email guide.

How we test ourselves

The rule engine ships with a regression suite: synthetic fixtures and selected representative messages that exercise each verdict path (authentication failures, brand and role impersonation, link flags, the money/credential cap, the job-offer-plus-document-request pair, the forwarded-message guard, and known-good ESP-routed mail). The tests run on every change to make sure refactors don't silently move a verdict from "danger" to "caution" on a scenario we've already documented. These cases prove the engine still produces the documented verdict for each rule path. The full known-fake corpus remains private and is checked separately.

If you find a real-world email where we get the wrong answer, email the saved file (never just the body, since the headers are the evidence) to [email protected] and we'll turn it into a fixture.