Blog

Anti-phishing codes: a useful signal that won't check your links

Posted on Friday, July 31st, 2026 by Jeroen Derks

TL;DR: An anti-phishing code is a phrase you set once, and your exchange or bank then prints it inside every genuine email. Seeing it is a useful signal that a message is consistent with real mail from that service. But it is only a recognition signal, not proof, and it says nothing about where the links in that email actually point. Pair it with a tool that shows each link's immediate destination before you click: Reveal URLs shows the link's actual immediate URL inline and turns it red when the destination host does not match a host named in the visible link text. It shows the immediate URL; it does not follow redirects to a final landing page.

If you use crypto.com, Binance, or a similar service, you have probably been nudged to set an "anti-phishing code". It is a good habit, and this article is not an argument against it. It is an argument about what the code does and does not do, because the gap between the two is exactly where people still get caught.

What an anti-phishing code is

An anti-phishing code is a word or phrase you choose and store against your account. The service then includes it in every genuine email it sends you, so you have something specific to look for. crypto.com lets you set one for its App and Exchange (which share a single synced code) and a separate, independent one for its NFT platform. Binance includes your code in its official emails and, it says, its SMS messages. The pattern is the same everywhere: self-service, one per account, shown within the email.

Kraken takes a different and stronger route: it can PGP-sign the emails it sends you (its automated messages can carry a PGP signature). That is genuine cryptography rather than a recognition phrase, and it is the useful point of comparison for everything that follows.

What it does well

Against the classic brand-impersonation email ("your account is locked, confirm now"), the code is a fast, at-a-glance check. A genuine message carries the phrase you and the service agreed to expect; a spoofed one usually does not. A missing or wrong code is an instant red flag, before you have read a word of the body. For a control you configure once and never touch again, that is real value, and it is worth setting up.

The blind spot: it says nothing about links

Here is what the code cannot tell you: where a link points. It says nothing about the URLs in the message at all.

The code hints the email is genuine.
It never tells you where the link points.
your code blue-harbor-42 Hi, we noticed activity on your Northwind Exchange account. Please confirm your details to keep access active. → northwind-exchange.secure-login.xyz Confirm now Code checks out consistent with genuine mail Link does not the immediate host is not Northwind
The code checks out; the link does not.
An anti-phishing code speaks to the sender, never to where the link points.

It is worth being precise about the boundary. The code speaks to the question "is this from the brand?" So could an email ever reach you carrying the expected code and still link to a look-alike host? Not by an attacker rewriting a genuine email in transit; that is not how any of this works. But authenticated, trusted sending infrastructure can and does deliver malicious links. The January 2026 SendGrid compromise (which I covered in the policy article linked below) showed attackers pushing link-based phishing through a trusted platform whose mail passed authentication. That incident does not prove anyone forged a correct-code exchange email. It does, though, make the bounded hypothetical concrete: a compromised service mailing system, or an attacker who has simply copied your code from one earlier genuine email, could in principle put a message in front of you that carries the right code and the wrong link.

Set that hypothetical aside, though, and the everyday point still stands. Most phishing does not need your code at all. It needs you not to have set one, or not to check it in the moment, and it needs a link that looks like your exchange but is not.

A signal, not a secret

People often call the anti-phishing code a "shared secret", and informally that is how the feature is sold: a secret between you and the service. Technically it does not hold up. A value that is printed, in cleartext, into every genuine email is not a secret once any one of those emails has been seen. It is better described as a static, bearer-like recognition token: anyone who reads a single genuine message (a forwarded receipt, a screenshot, a breached mailbox, a compromised marketing vendor) now has your code.

A signal, not a secret One glimpse of a genuine email leaks the code Harbourline Bank [email protected] your anti-phishing code blue-harbor-42 blue-harbor-42 blue-harbor-42 blue-harbor-42 blue-harbor-42 forwarded email screenshot breached mailbox marketing vendor
A code printed in cleartext in every genuine email is a token, not a secret: one glimpse of one message leaks it.

That is what shapes its limits:

  • It can be phished itself. A fake "confirm your anti-phishing code" page harvests the very token that would make future phishing mail look legitimate to you.
  • It depends on you checking, every time. That is the exact habit urgency is engineered to break.
  • It only helps if you set it up first, and most people never do.
  • It multiplies across providers. Every provider maintains its own code, and some keep more than one: crypto.com uses a single code for its App and Exchange, but a separate, independent one for NFT. To keep the signal meaningful you want a different phrase for each independent code, because reusing one means a single leaked email weakens them all. That leaves you a growing set of static phrases to remember across every provider, which can encourage reuse or make codes easier to forget, and a signal you don't keep up quietly stops being one.
  • It is channel-limited: email, plus SMS for Binance, but nothing for phone calls, chat apps, or push notifications.
  • It carries no cryptographic guarantee. Unlike DKIM (a per-message cryptographic signature over a sending domain), DMARC (a policy that checks SPF and DKIM are aligned with the visible From domain), or BIMI (a DMARC-gated brand-logo indicator), the code proves nothing mathematically. And none of those three vouch for the body of a message or where its links lead, either.
Your anti-phishing codes one per provider, some more than one Northwind Exchange App / Exchange tidal-copper-92 quartz-lantern Aster Bank Login e-mails meadow-orbit-41 Vela Wallet Transfers meadow-orbit-41 reused from Aster Bank Orca NFT Marketplace / Drops amber-fjord-07 nimbus-echo-3 Halcyon Pay Payments forgotten? Cirrus Trade ?
Each provider keeps its own code, some keep more than one, so the set grows until you reuse or forget them.

Two questions, two layers

Reading email safely really comes down to two separate questions:

  1. Does this message look genuine? The anti-phishing code speaks to this weakly. DKIM and DMARC add real domain-authentication evidence (a signed sending domain, and a From domain checked for alignment), but only when your mail system actually verifies and surfaces the result, and even then they attest to the domain, not to the message's content or intent.
  2. What is this link's immediate destination? Nothing above answers this.

That second question is where links get clicked and credentials get lost, and it is the one an anti-phishing code was never built to answer. The two controls are complementary, not substitutes: the code gives you a hint about the sender, and a link-revealing tool shows you the destination. Better still, a link-revealing tool keeps working precisely when the code fails you: on a message that carries the right code but points somewhere wrong.

Two questions, two layers The code checks who sent the email. It never checks where the link goes. QUESTION 1 What the code signals Does this look like genuine mail? From Northwind Exchange [email protected] Looks like genuine mail (weak signal) anti-phishing code DKIM / DMARC (domain auth) Confirms the envelope. Says nothing about the link inside. QUESTION 2 What it never checks Where does the link actually go? Link text Verify your account Real host the link destination Authentication is blind here. This is where the attack hides. → northwind-exchange.secure-login.xyz Reveal URLs answers Question 2: it shows the link'simmediate destination before you click Separate questions
Two separate questions, two separate tools: the code speaks to the sender; a link-revealing tool shows the link's immediate destination.

See the link before you click

Reveal URLs is the practical answer to that second question. It is free and open source (AGPL). For every link, it shows the actual immediate destination (the real URL) printed inline above the link, and turns it red the moment that destination's host does not match a host named in the visible link text. No hover and no long-press: the mismatch is there by default. It shows the immediate URL and does not follow redirects to a final landing page, and it does not verify senders or authentication; that is the other layer's job.

It is available now for Chrome, Edge, Firefox, Thunderbird, and Outlook, with the Outlook mobile version and the Gmail add-in still to come and Safari coming soon.

An anti-phishing code is worth setting: it is free, and a missing one is a useful warning. Just do not ask it to do a job it cannot. It tells you an email looks genuine; it never shows you where a link points. To see each link's immediate destination, see Reveal URLs: spot phishing links before you click, and for the wider argument that email clients should always show the URL, see Email link phishing: why your email app should always show the URL.

Want help hardening email or web security for your organisation, or building a tool like Reveal URLs? Feel free to get in touch.