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.
• 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.
• Safewhen 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 content classification by meaning. We don't try to decide whether the email's contentis suspicious — only whether it carries trigger words for our cap rule. That's deliberate: a content-meaning model would need to phone home to a server, breaking the privacy promise.
• No reputation lookups.We don't query VirusTotal, urlscan, abuse.ch, or anything else with the contents of your email. The benefits aren't worth the leak.
• No tracking. No analytics, no cookies, no logs. The site is a static page served from a CDN.

How we test ourselves

The engine is a port of an internal triage tool that has been calibrated against a curated set of real phishing samples and ground-truth analyst verdicts. We carry that fixture set forward as a regression check whenever the engine changes. If you find a sample where we get the wrong answer, email it (as a saved file, never just the body) to hello@messageloupe.com and we'll add it to the test set.