What the findings mean

Each check this tool makes, what it is actually looking at, and what a finding does and does not tell you.

Every finding on a result screen carries a one-line explanation and the evidence it was drawn from. This page is the longer version: what the underlying mechanism is, why attackers interact with it the way they do, and how much weight a finding deserves.

One thing to carry through all of it: these checks corroborate each other. None of them is a verdict on its own. Several are ordinary in legitimate mail and only become interesting in company.

How a message is put together

An email is two parts: a block of headers at the top, then the body. The headers are where the sender is stated, where each server that handled the message stamped its own record, and where authentication results are recorded. Your mail program hides nearly all of it and shows you a name, a subject and the body.

Almost everything this tool does reads the headers. That is why it asks for the raw source rather than a screenshot or a forward: a forward loses the original headers and replaces them with yours.

Authentication - and why a pass is not reassurance

What the three mechanisms actually check

SPF answers: is the server that delivered this message on the list of servers permitted to send for this domain? The domain's owner publishes that list.

DKIM answers: was this message cryptographically signed by someone holding a key the domain publishes, and has it been altered since? The signature names the domain that signed - that is the d= value you will see in the evidence.

DMARC ties those to the address you actually see. On its own, a passing SPF or DKIM result can belong to a completely different domain from the one in the From line - which would mean nothing to a reader. DMARC requires alignment: the domain that passed must match the domain you are shown.

What alignment means, concretely

Suppose a message shows notice@bank.example.jp in the From line and carries a DKIM signature from mailer.example.net. The signature is valid. But the domain that vouched for the message is not the domain the reader sees, so it is not aligned, and DMARC does not treat the message as authenticated for bank.example.jp.

Alignment can be strict (an exact domain match) or relaxed (the registered domain must match, so mail.bank.example.jp aligns with bank.example.jp). Working out the registered domain is the part with a caveat - see the disclosure at the bottom of this page.

Why a pass is the least interesting thing on the page

This is the single most important idea in this tool, and it is the opposite of what most people assume.

Authentication proves who owns a domain. It does not prove a message is what it claims to be. An attacker who registers bank-example-support.com owns that domain completely. They can publish SPF records for it, sign with DKIM for it, and publish a DMARC policy on it - in minutes, for the price of the domain. Every message they send then authenticates perfectly, because every statement it makes about itself is true. It is simply not the bank.

In observed phishing this is the majority case, not an edge case. Roughly half of it comes from attacker-registered domains, and the overwhelming majority of those pass DMARC. That is why this tool renders a pass as "this domain is who it claims to be" and nothing warmer, and why lookalike-domain and link analysis carry more weight here than authentication does.

A failure is still worth knowing about - it is the shape a forged sender produces. But mailing lists and forwarding services break authentication routinely and innocently, so a failure alone is not a verdict either.

ARC, for messages that were forwarded

When a mailing list rewrites a message, it breaks the original signature. ARC lets each hop record what it saw before passing the message on, so a later server can see that authentication passed earlier even though it fails now. When this tool reports an ARC chain that failed its check, it means that record could not be trusted - so what happened to the message before it reached you cannot be confirmed.

The delivery route

What a Received chain is

Every server that handles a message adds a Received line to the top of the headers: who connected, who received it, and when. Read from the bottom up, they are the message's journey. The tool shows them most recent first, with the gap between each pair on the line connecting them.

Only the later hops are trustworthy. Each server can only vouch for the connection it personally accepted. Everything below the first server your own provider controls was written by machines you have no reason to trust, and an attacker can invent as many lines as they like. That is why an odd-looking early hop is a signal rather than proof.

Timestamps that run backwards

Each hop stamps its own clock, so small disagreements are normal - clocks drift. When a later server records an earlier time than the one before it, by more than drift explains, either a clock is badly wrong or part of the route was written by hand. Fabricated headers are usually written in one go by someone not being careful about the arithmetic.

A long unexplained gap

More than a day between two hops. Mail queues and retries genuinely cause this, so it is reported as something to notice rather than something to act on. It is worth a look because it can also mean a message was composed earlier and injected later, or that a header block was copied from a real message.

A private address in a public journey

Some address ranges only work inside a private network and cannot be reached from the internet. One appearing partway through a public journey usually means the line was copied or invented, because the connection it describes could not have happened.

Sent from an unnamed cloud server

Organisations that send their own mail normally give their mail servers names they chose. A first hop whose name was generated automatically by a hosting provider means the sender is using rented capacity without configuring it - which is ordinary for some small senders and is also the cheapest way to send from an address nobody recognises. Reported as a detail, never as a verdict, and never solely because of who the host is.

A note a receiving server left

Sometimes a server that handled the message recorded its own doubt about who was connecting to it - commonly that the connecting address has no reverse name, which is disproportionately true of bulk senders. When you see this, it is that server's note, quoted as written. This tool does no lookups of its own; it is reporting what is already in the message.

Who the message says it is from

The name and the address are set separately

A sender is a display name plus an address, and they are independent fields - the sender writes both. Most mail programs, especially on phones, show only the name. So a message can display Account Security Team while the address underneath is something else entirely, with nothing forged at all. This is why the tool shows you the pair on every message, not only on suspicious ones.

A second address hidden in the name

A particular version of the same trick: an email address written inside the display name. Your mail program shows the name, so you read one address while the message came from another.

Characters that reverse how text reads

Unicode includes control characters that exist so Arabic and Hebrew display correctly in mixed text. Placed in a name or a filename, they make text read backwards on screen while the underlying characters are unchanged - which is how a file called .exe can appear to end in .jpg. This tool never applies them: it shows them as visible labels like <U+202E> so you can see where they are.

Invisible characters

Characters that occupy no space at all, placed inside a name or address. They make a name that looks identical to a familiar one fail to match it, which defeats filters and mail rules that match on the plain text.

Lookalike domains

This and link structure are the checks that carry the most weight here, because unlike authentication they are hard for an attacker to satisfy honestly.

Mixing alphabets inside one name

Domain names can contain characters from most of the world's writing systems, and several letters are drawn identically across them - Latin a and Cyrillic а, Latin o and Greek omicron. Substituting one into an otherwise ordinary name produces a domain that is visually identical and technically different, available to register because nobody else has it.

Mixing writing systems is not itself suspicious, and this tool does not treat it as such. Japanese mixes three scripts in ordinary words; Japanese, Korean and Chinese domains are normal. The check uses the Unicode rules for which combinations genuinely occur together, and flags the combinations that do not - Latin with Cyrillic or Greek inside a single label.

Punycode is not a warning sign

Non-ASCII domains are transmitted in an encoded form beginning xn--. This is how every legitimate Japanese, Korean, Chinese and Russian domain is written on the wire. Seeing it means nothing on its own, and this tool never flags it as suspicious. What it does is show the decoded and encoded forms side by side, so that if characters have been substituted, the difference is visible rather than merely present.

One or two characters away from a real domain

A letter swapped, added or removed. rn in place of m; a zero in place of the letter o. These are hard to tell apart at reading size and trivially registrable. This comparison needs a list of real brand domains to compare against, which is not in this build yet - see the limitations page.

Domain endings that appear disproportionately in abuse

Some endings are cheap and lightly checked, and appear in phishing far more often than in ordinary mail. Plenty of legitimate sites use them too, so this contributes to a picture and settles nothing by itself.

The list is deliberately short, and an ending's absence from it means nothing. It holds only endings we can point to a published source for, measured across more than one source and more than one period. That is a small number - currently three. Far more endings are used in phishing than appear on it, and most phishing uses ordinary endings like .com anyway. Read a result that says nothing about the domain ending as the tool having no comment, not as approval.

Links

The text says one thing and the link goes elsewhere

In an HTML message, the text you see and the address you would go to are separate. Making them disagree is the single most reliable sign of phishing there is, and it is invisible unless you hover over the link or read the source. The tool shows both, stacked, so the comparison is one downward glance.

No link in this tool is ever clickable. Addresses are shown as inert text you can copy. Putting a live phishing link inside a phishing analyzer would be indefensible.

An @ before the real destination

Everything before an @ in a web address is ignored by the browser. https://www.bank.example.jp@evil.example/ goes to evil.example. The familiar part is there to make the link begin convincingly.

Links that carry instructions rather than an address

Some link schemes do not lead to a page at all: they carry code for the browser to run, or a whole document encoded inside the link. Ordinary mail does not contain these.

A numeric address instead of a name

A destination with no domain name behind it. Organisations put their name on their sites, and a bare address cannot be checked against anything.

Redirects and encoded parameters

A link that carries a second address inside it and forwards you onward: the part you would read belongs to one site, the place you arrive is chosen by whoever wrote the link. Encoded chunks in the query string are common in ordinary tracking links and are also how an address or an instruction is hidden from a quick glance - reported, not accused.

Links rewritten by a security product

Mail providers and filtering services replace links with their own so clicks pass through them. Where the original address is encoded inside the new one, this tool decodes it and shows you the real destination - judge that, not the wrapper. Where the service keeps the original on its own servers and leaves only a reference, there is nothing to decode, and the tool says so instead of guessing.

A payload hosted on a service everyone trusts

Anyone can put a page on a well-known document or storage service and borrow its reputation. The hosting provider is never a signal by itself - a link to a legitimate service in a legitimate message is a link to a legitimate service. This is raised only when the message also appears to be impersonating someone, and even then it is a moderate signal.

It is limited to the brands on the list. Deciding that a message impersonates a brand needs that list, so this check can only be raised for a brand the list carries - 52 of them. A message impersonating a brand that is not on the list, hosted on the very same service, is not raised here at all. See what this tool cannot detect.

Text encoding

The declared encoding disagrees with the content

A message says how its text should be read. When the label disagrees with the actual bytes, everything still displays - which is the point. A filter that reads the message the way the label says sees different text from what you see, and a message can be built so that the version the filter reads is innocuous.

An obsolete encoding

One encoding in particular was withdrawn from web standards and is no longer decoded by browsers. It survives almost entirely as a way of writing text that security filters do not decode.

Characters that imitate ordinary letters

Mathematical, circled and decorated character forms read as normal words to a person and are different characters underneath - which is how a word gets past a filter matching on the plain spelling.

Severity, and why there is no score

Findings carry one of four severities - Malicious, Suspicious, Informational, or No issues found - and each is assigned by the rule that produced it, not calculated. The headline is the most severe finding present.

There is no numeric score, and one is not being withheld. None exists. A number would suggest a precision this analysis does not have and would invite a threshold - "under 30 is fine" - which is exactly the reasoning that gets people phished by the message that scored 28. Four named severities and a sentence you can repeat to a colleague are more honest about what is actually known.

Nothing is ever green, and no result says a message is safe. A clean result means the checks that ran found nothing high-risk; the coverage note on every result tells you which ones ran.

A disclosed approximation: the registered domain

Alignment depends on knowing where a registered domain ends - example.co.jp is one, co.jp is not. The current DMARC standard determines this with a live sequence of DNS lookups.

This tool makes no network requests of any kind, so it cannot do those lookups. It uses the Public Suffix List instead - a maintained list of domain endings under which people register names - and derives the registered domain from that.

The two approaches usually agree. Where they differ, the alignment result shown here may be stricter or looser than what a receiving mail server would compute. This is an approximation, and it is disclosed on every result that relies on it rather than being left for you to find out. It is a deliberate trade: the alternative is a tool that sends your message's domains to a DNS resolver, and then "your message never leaves your machine" would stop being true.