NuModeX MailOrigin What this tool cannot detect

What this tool cannot detect

A clean result here is not a guarantee that a message is safe. This page says exactly what is outside what the tool can see, so you can judge the result for what it is.

This tool reads one message, in your browser, with no network access. That shapes everything below. Most of these limits are not gaps waiting to be filled - they follow from the design, and the design is what lets the tool promise that your message never leaves your machine.

Read this page once. The result screen tells you what it checked and what it could not check on your particular message; this page tells you what it never checks on any message.

The one that matters most: a compromised real account

A phishing message sent from a genuinely compromised legitimate account passes every check this tool makes.

If an attacker has the password to a real employee's real mailbox, the message they send is, mechanically, a real message from that company. It is signed by the company's own mail servers. Its authentication records are the company's own and they pass, because the company published them and the message really did come from there. Its delivery route is the ordinary route. Its sender address is the person's actual address, not a lookalike. There is nothing forged in it, because nothing needed forging.

This is not a rare case. It is the most effective form of the attack, precisely because everything technical about it is correct. What gives it away is what it asks for - an unexpected payment, an unusual request for credentials, urgency from someone who is not usually urgent - and none of that is a technical signal. It is a judgement about the conversation, and you are far better placed to make it than this tool is.

If a message asks you to do something unusual with money, credentials or access, verify it through a channel you already trust - a phone number you already have, not one in the message - regardless of what this tool says.

Where a link actually goes

Links are analyzed as text. No link is ever fetched. So the tool can tell you that a link's visible text names one site while the link itself points at another, that a destination is a bare numeric address, or that a redirect parameter will forward you onward - all of which are read from the address itself. It cannot tell you what is at the other end.

That is partly about safety and partly about honesty. Fetching would be unreliable even if we did it: phishing pages routinely serve harmless content to anything that arrives looking automated, and show the real page only to a browser that arrives the way a victim would. A fetch-based verdict would be confidently wrong exactly when it mattered.

Referrer-cloaked and fingerprinted landing pages

The same defence, more precisely: many phishing pages decide what to show based on where the visitor came from, what browser they claim to be, what network they are on, or whether they have visited before. Two people opening the same link can see two different pages. Nothing that inspects a link from outside can resolve that, and this tool does not try.

Some rewritten links cannot be unwrapped

Security products rewrite links so that clicks pass through them first. Some of those wrappers encode the original address into the new one, and this tool decodes it and shows you the real destination. Others keep the original on their own servers and leave only a reference - there is nothing in the link to decode. In that case the tool says so and stops. It will not guess: a wrong destination inside a phishing check is worse than no destination.

Attachments

Attachments are never opened, read, decoded or executed - and nothing about them is shown to you at all. Not the file names, not the stated types, not the sizes. A malicious document, a macro, an archive containing a payload, a file whose name is designed to look harmless - none of it is examined, and none of it is reported.

That second half matters more than it sounds. A result that says nothing about attachments is not telling you the message had none. If you need to know what was attached, look in your mail program - this tool will not tell you, and a quiet result is not evidence either way.

This is permanent and deliberate. Opening attacker-supplied files is exactly the activity this tool is meant to help you avoid, and doing it inside a browser tab would not make it safe. Treat an attachment on a message you are investigating as unopened and unexamined, because it is.

A forwarded copy is not the original

If you forward a suspicious message to yourself, or to a colleague, and analyse the forwarded copy, you are analysing the forward. That is a different message with a different delivery history, and the difference is not cosmetic.

Forwarding prepends your own mail system's hops to the delivery chain, so the route shown here describes how the message reached you from the forwarder rather than how it reached the forwarder from the sender. It also replaces the envelope sender, which is what SPF is checked against - so an SPF result on a forwarded copy is a statement about the forwarding server, not about whoever sent the original. A DKIM signature can survive a forward, because it signs the message rather than the path, but only if nothing along the way altered a signed header or the body; many mailing lists and some clients do alter them, and the signature then fails for a message nobody tampered with.

So a forwarded copy can look worse than the original, and it can look better. Export the raw source of the message as it arrived, rather than forwarding it and exporting that.

What this tool deliberately does not do

Other header tools do several things this one does not, and in every case the reason is the same: none of them is possible without sending a request, and this tool sends none after the page loads. That is a design decision with consequences, not a list of features waiting to be built.

If you need those, a hosted analyser will do them - and will receive the message in order to do them. Mail headers carry internal hostnames, private address ranges, the name and version of your gateway, and the addresses of everyone the message reached. That is the trade being made in either direction, and it is worth making deliberately.

Everything that is not this message

Text messages, chat and phone calls

Smishing (phishing over SMS), messaging-app phishing and voice phishing are entirely outside this tool. It reads email source. A screenshot of a text message contains none of the structure it analyzes.

QR codes

A QR code in an email is an image, and images are not decoded here. The whole point of putting the address in a picture is that it stops being text - which defeats link analysis in this tool and in mail filters generally, and moves the click to a phone that is usually less protected than a laptop. If a message asks you to scan something, treat the code as an unexamined link.

Business email compromise, in its quiet form

A short message from a plausible address asking for an invoice to be paid to a new account number may contain no links, no attachments, no lookalike domain and no authentication failure. There is nothing structural to find. If it comes from a compromised real account, see the first section. If it comes from a domain registered last week, this tool cannot tell you that either - it has no way to look up when a domain was registered, and it does not try. What it can tell you is whether the domain resembles one you know, which is a different question and only helps when the attacker chose a lookalike rather than something plain.

Detecting these needs analysis of what the message says - urgency, financial instruction, a change of banking details - which is a language-dependent judgement. It is deliberately not in this version: it needs native authoring per language to be any good, and a bad version of it produces false accusations against ordinary business mail.

Attack techniques that live outside the message

These are current and effective, and every one of them is designed so that the email itself looks unremarkable. The message is a delivery mechanism; the attack happens somewhere this tool cannot see.

ClickFix

The message leads to a page that shows a fake error - a failed CAPTCHA, a document that will not load - and instructs the visitor to fix it by copying a line of text and running it themselves, usually in a terminal or a Run dialog. The victim installs the malware by hand. There is no attachment and no download to inspect, and the email may contain nothing worse than a link to a page that, when this tool looks at the address, is just an address.

No legitimate website will ever ask you to copy a command and run it to view a document or prove you are human. If a page asks for that, close it.

Device-code phishing

The attacker starts a real sign-in on a real identity provider and sends you the short code it produces, with a plausible reason to enter it. You authenticate genuinely, on the genuine site, and the approval lands on the attacker's session. Nothing about it is counterfeit - the domain is real, the login page is real, the certificate is real - so there is nothing in the message for domain or link analysis to catch.

Never enter a sign-in code that arrived from someone else. A code is for a device in front of you, started by you.

Adversary-in-the-middle sign-in pages

A proxy sits between you and the real login page, passes your credentials through, and captures the session cookie the provider issues afterwards. Because it forwards the real challenge, it survives most multi-factor methods. The link in the email points at the proxy, so if the proxy's domain is a lookalike this tool may flag it - but if it is a plain unremarkable domain, there is nothing structural to see.

The defence is not detection: it is reaching login pages through your own bookmarks rather than through links, and using phishing-resistant sign-in (passkeys or hardware keys) where it is offered.

Limits of the checks that do run

Which part of a domain counts as "the registered domain"

Judging whether an authentication result belongs to the sender you can see means knowing where the registered domain ends - that example.co.jp is a registered domain while co.jp is not. The current email standard works this out with a live DNS lookup. This tool cannot do that, because it makes no network requests at all, so it uses the Public Suffix List instead.

The two usually agree. Where they differ, the result shown here may be slightly stricter or slightly looser than what a receiving mail server would have computed. This is disclosed on every result that uses it - including results with no headers at all, because link analysis compares registered domains too.

Brand comparison covers the most-impersonated brands, not all of them

Comparing a sender domain against the real domains of commonly impersonated brands needs a hand-curated list of those brands and all of their legitimate domains. That list is now in this build: 52 brands and 159 domains, curated by hand from six months of Council of Anti-Phishing Japan reporting, with every domain verified against the brand's own published page.

It is not a list of every brand. Japan has well over a hundred banks; this list carries eight. The same is true of securities firms, insurers, regional utilities and card issuers - the set being impersonated rotates every month, and a list that chased the tail would be stale the month after it was written. Those omissions are decisions, and they are written down.

So: a message impersonating a brand that is not on the list gets no lookalike comparison at all. Not a weaker one - none. The three checks below simply have nothing to compare against, exactly as they had nothing to compare against for every brand before the list existed. A brand's absence from the list is not a judgement that mail claiming to come from it is genuine.

Nor is it a list of safe senders. Matching a listed domain means only that the sender is not a lookalike of that brand; it suppresses nothing and makes no result cleaner. That distinction is load-bearing, because four of the brands on the list - an event ticketing company, a courier, a social network and a bank - publish warnings that their own domains are being used in the attacks against them.

Three checks depend on the list, not one. Each compares a sender domain against a brand's real one, so each needs the real one to be present:

A fourth follows from those: a link hosted on a well-known service is only raised when the message also appears to impersonate a brand, so it too is limited to the brands the list carries.

Checks that do not need the list still run on every message, whatever brand it claims to be: alphabets mixed within one domain name, link structure, sender identity, routing and encoding.

A defect that was here, and is now fixed

A domain that uses non-Latin letters can travel in a message in two forms: the letters themselves, or an all-ASCII encoding of them that begins with xn--. The two are the same domain. The second form is the ordinary one, because not every mail server can carry the first.

Until 15 September 2026 this tool could only read the first form. The code that turns xn-- back into letters did not work, and two checks read the result of it - the one that notices two alphabets mixed inside one name, and the one that notices a name written entirely in another alphabet. So the same lookalike domain was reported as strong signs of phishing when it arrived one way, and as nothing found when it arrived the other way. The second way is the common one.

It also meant the decoded form was never shown. A homoglyph is invisible unless you can see both forms side by side, and the tool was showing only the xn-- string.

Both are fixed. The encoding a domain arrives in no longer changes the result, and that is now held by a test rather than by care: a matched pair of messages, identical except for the encoding, must produce the same verdict.

Lookalike names are only checked where the sender claims to be someone

The lookalike checks read the From, Sender, Reply-To and Return-Path addresses. They do not read the addresses that links point at.

So a message sent from an ordinary, correctly authenticated address, whose links point at a lookalike domain, is not caught by those checks. It is caught when the visible text of a link names one site and the link goes to another, which is a separate check and does run. It is not caught when the link text is something like Sign in and the address is only in the link itself.

Widening the lookalike checks to link addresses is a deliberate later change rather than an oversight. Applied carelessly it would accuse ordinary mail: a message legitimately links to many addresses that have nothing to do with its sender, and a name-similarity test across all of them produces accusations against real companies. The plan is recorded in the specification, and it depends on the brand list above.

Reputation, age and history

Nothing here knows whether a domain was registered yesterday, whether it appears on any blocklist, or whether anyone has reported it. All of that needs a lookup, and lookups are what this tool does not do.

Messages it cannot read

Outlook .msg files are a Microsoft container format rather than mail, and are not parsed - the tool recognises them and tells you how to get a readable copy instead. A few text encodings that browsers deliberately refuse to decode cannot be read here either; where that happens the result says so rather than showing you something wrong.

What a clean result actually means

It means: of the checks this tool was able to run on what you gave it, none found a high-risk signal. That is genuinely useful and it is not the same as "this message is safe". Every result shows which areas were checked and which were not, for exactly this reason.

This tool is a decision aid. It is not a guarantee, a filter, or a substitute for your own judgement about what a message is asking you to do.