Homograph phishing attacks in 2026

In 2017 a researcher registered аррӏе.com. Every letter in it is Cyrillic, but in most fonts it looks exactly like apple.com. Chrome fixed the display bug in April 2017. Firefox took years. The domain itself is still registered today, in October 2026. So is a similar one created in 2018, раураӏ.com.

That made me ask a simple question: who is supposed to stop these domains from being created in the first place? The answer is the registry behind each top-level domain (TLD). I spent some time going through the rules of more than 50 TLDs, the browser source code and the phishing data from the last few years.

Short version: almost every registry now blocks names that mix alphabets. Very few block names written fully in one “foreign” alphabet. And in real phishing, the problem looks quite different from what most people expect.

Three kinds of homograph domains

A homograph domain uses characters that look like other characters. Domain names can contain Unicode since the early 2000s (these are called IDNs). In DNS they are stored as punycode, a plain ASCII form that starts with xn--. So аррӏе.com is really xn--80ak6aa92e.com.

It helps to split homographs into three groups, because registries and browsers treat them very differently:

Type	Example	What it is
Mixed-script	pаypal.com	Normal Latin name with one Cyrillic “а” swapped in
Whole-script	аррӏе.com	Every letter is Cyrillic, but the result looks Latin
Latin lookalikes	gmaıl.com, bįtpay.com	Only Latin script, but with accents, a dotless ı or similar letters

The protocol itself (IDNA2008) does not forbid any of these. The RFCs say registries are expected to set their own rules (RFC 5891). So whether a homograph can exist depends on the registry.

What registries block

For generic TLDs like .com, .info or .xyz, ICANN sets the rules. Its IDN Guidelines v4.1 became mandatory for gTLD registries on 30 April 2025. Rule G15 says one label may use only one script. Rule G17 says registries should limit whole-script lookalikes, but it is only a recommendation. For country TLDs (.de, .pl, .ru…) the guidelines are only a recommendation.

In practice that gives us this picture:

Mixed-script is basically dead for new registrations. Verisign banned mixing Latin and Cyrillic in .com and .net on 21 March 2005. Old registrations like pаypal.com were left in place. That one was registered in January 2005 and now sits with MarkMonitor, a brand-protection registrar (RDAP).

Whole-script is mostly allowed. Verisign’s Cyrillic table for .com has no link between Cyrillic and Latin lookalikes (IANA IDN tables). That is why аррӏе.com exists (RDAP).

A few registries do block whole-script lookalikes. EURid bundles Latin and Greek lookalikes and only allows Cyrillic under .ею, not under .eu. The .gr registry reserves Latin lookalikes of a Greek name for its owner. Bulgaria requires every Cyrillic name to contain at least one letter that cannot be mistaken for Latin (Register.BG). Ukraine does the same for Cyrillic names in zones like .com.ua, while names directly under .ua are Latin-only (Reglament UA).

Some TLDs have no IDN at all. That includes .cz, .sk, .uk, .nl, .ru and .us. In .cz the public said no to accented domains in seven surveys in a row (the latest in 2019). In .ru, only Latin is allowed under the main TLD (cctld.ru).

Some ccTLDs open doors you might not expect. .de allows the dotless ı and ĸ. .pl allows Cyrillic and Greek under a Latin TLD. And .ai opens IDN registration on 19 October 2026 in 57 languages and scripts, Cyrillic included. So far only a registrar blog says so, not the registry itself.

The alphabet is a bigger limit than the registry

This part surprised me the most. Cyrillic can copy only some Latin letters well. The basic Russian alphabet gives you seven: a, c, e, o, p, x, y. Extra Cyrillic letters from other languages add i, j, s, h, l, d, q, w and v. That is about 16 of 26 (confusables.txt).

There is no Cyrillic copy of f, n, u or z, and the only “r” (г) looks off. For k, m and t there is only a small-caps style letter that looks wrong in a normal font. So many brands simply can’t be faked in Cyrillic:

Brand	Full Cyrillic copy?	Why
apple, paypal	Yes (аррӏе, раураӏ)	Needs the rare letter ӏ for “l”
slsp (Slovenska sporitelna)	Yes (ѕӏѕр)	Needs ѕ and ӏ
o2	Yes	Only needs Russian о
google, csob, kb, binance, ledger	Only a poor copy	Letters like g, b, k, m, t look off
seznam, alza, amazon	No	No Cyrillic “z”
microsoft, facebook, netflix	No	No Cyrillic “f”
revolut, vub	No	No Cyrillic “u”

This table is my own analysis based on the Unicode data. There is one more catch. The good fakes need the letter ӏ (U+04CF). Verisign allows it in .com. Many cheaper registries don’t: the Cyrillic tables used for .online, .site or .bond leave it out. Without it, you can’t write “l”, and most of the list above falls apart.

Popular tools also miss this. dnstwist’s Cyrillic mode has no mapping for f, n, r, u or z, so for a name like “seznam” it returns nothing.

What the victim actually sees

The registry decides what can exist. The app decides what the victim sees. If the app shows xn--80ak6aa92e.com instead of аррӏе.com, the trick is gone.

Browsers are better than registries now. Chrome shows an all-Cyrillic lookalike name as punycode, except under .bg, .by, .kz, .ru, .su, .ua, .uz and TLDs written in Cyrillic (.рф, .укр and so on). On top of that, a name that looks like one of about 8,500 popular domains is shown as punycode, and a lookalike of a top-500 site or a site you visit often gets a full-page warning (Chromium source). Firefox now has a very similar Cyrillic rule with the same TLD exceptions, but no popular-site check. Safari shows Cyrillic only under a fixed list of Cyrillic TLDs like .рф, never under .ru or .ua. None of them stop Latin lookalikes well, unless Chrome matches a popular site.

There is a fresh crack. In October 2026 researchers from Have I Been Squatted reported that swapping in a Cyrillic letter Chrome doesn’t check, like ө for “e”, makes аррӏө.com show as Unicode with no warning. I checked the current source and those letters really are missing from the list. Still, this comes from one research team and no vendor has responded yet.

Outside the browser, the TLD stops mattering. In the same October 2026 research, Gmail web showed all 20 test domains in Unicode, while Outlook Web showed all of them as xn--. Older tests found Unicode links in Instagram, Teams, Viber and iMessage, while Signal and Discord were safe. And SPF, DKIM and DMARC don’t help: a homograph domain with its own records passes them, and the DMARC standard says plainly that it does not deal with lookalike “cousin” domains (RFC 7489).

Which TLDs make it easiest

I scored each TLD from 0 to 3 on seven things: how many brands live there, what the registry allows, how apps display it, price and registrar support, identity checks, abuse rates and real-world use. Then I made two rankings, because faking a brand and just hosting a phishing page are different jobs. Scores with weak sources are my estimate.

Ranking A: faking the brand’s own domain

#	TLD	Score (max 27)	Why
1	.com	22.0	Full Cyrillic set incl. ӏ, accents allowed, ~$9, no checks, where most brands live
2	.pl	10.7	Cyrillic and Greek under a Latin TLD, relevant for Polish brands
3	.de	10.0	Dotless ı and ĸ allowed, relevant for German brands
4	.net	6.7	Same rules as .com, fewer brands
5	.ai	6.0	Cyrillic from 19 Oct 2026, but ~$160 for the two-year minimum
6	.org, .app/.dev	5.7	Wide script support, few brands
7	.io	5.0	Wide script support, pricey

.com is not first because its rules are the worst. It is first because the full Cyrillic set, cheap prices and the brands themselves are all in one place. In the studies I found, 52% of homographs were in .com, and 320 of 337 homographs that later ended up on blocklists were .com.

Ranking B: a lookalike page where the TLD doesn’t matter

#	TLD	Score (max 33)	Why
1	.cc, .info, .xyz/.icu/.bond	26	Cheap, IDN on sale, high abuse rates
2	.com, .online/.site/.store	25	Cheap, Cyrillic sold by Namecheap for about $1 in the first year
3	.top	24	About $1, one of the most abused gTLDs
4	.net	23	Same rules as .com

Abuse rates for these TLDs come from Cybercrime Info Center: .bond had 552 phishing domains per 10,000, .icu 548, .top 298, while .com had 19. Keep in mind that most of that abuse is plain ASCII, not IDN.

What about .ru, .su and .рф? Browsers treat them best for an attacker, because Cyrillic shows as Unicode there. But .ru has no IDN, and since 1 September 2026 all three need identity checks through the Russian state portal. For a Czech or Slovak brand they also make no sense: nobody expects their bank on .su.

Wooden blocks spelling the word phishing arranged on a table — Photo by Markus Winkler on Unsplash

How common is this in real phishing?

Not very. Interisle counted 2,655 IDN phishing domains in its 2025 report, which is 0.17% of all phishing domains they saw. ICANN data published in February 2026 shows that of the IDNs on abuse blocklists in Q3 2025, 70% used Latin script and only 1.4% Cyrillic. Attackers mostly use combosquatting instead, like brand-login-secure.com. Infoblox found it about 100 times more often than typosquatting.

The homograph cases that did happen mostly look like this: .com plus an accent.

bravė.com, teleģram.com, lědgėr.com in one 2021 RedLine stealer campaign, with bravė.com confirmed as a Google ad
ķeepass.info in Google Ads pushing FakeBat, 2023
A fake Coinbase sender with a dotless ı, 2025

The newer tricks avoid registry rules completely. Since late 2024, more than 600 domains have used the Japanese character ん, which looks like a slash, often inside a subdomain: account.booking.comんdetailんrestric-access... (Netcraft). Others put lookalike characters in the sender’s display name and subject line, not just in the domain.

I found no homograph campaign against a Czech or Slovak brand. Recent local phishing, like the fake Czech National Bank site in February 2026, used plain ASCII domains.

A red padlock lying on a black computer keyboard — Photo by FlyD on Unsplash

What to do with this

If you run phishing simulations:

The most realistic option is a .com name with an accent or a dotless ı, for a brand that is not on Chrome’s popular-sites list. That is what real attackers use.
Whole-script Cyrillic works mainly outside the browser: as a Gmail sender, as link text in an email or PDF, or in chat apps. Once the user clicks, the browser will usually show punycode.
Most companies here use Microsoft 365. Outlook Web shows IDN domains as xn--, which looks suspicious. Test the client your target actually uses before you pick a technique.
Get written permission that covers registering lookalike domains, and use your client’s brand. After the test, hand the domains over to the client or let them expire.

If you defend:

Search your DNS logs for xn--. It is cheap and SANS recommends it.
Watch Certificate Transparency logs for punycode versions of your brand. Free certificates mean attackers get HTTPS too.
Don’t rely only on dnstwist. Generate candidates from the Unicode skeleton data and from the registry tables on IANA.
Flag or quarantine email from xn-- sender domains. A DMARC pass means nothing here.
In Firefox and Thunderbird, set network.IDN_show_punycode to true if your users don’t need IDNs.
If you register defensive domains, focus on .com first. For most Czech and Slovak brands, that means accented versions, not Cyrillic ones.

Bottom line

The question “which TLD blocks homographs” is only half of the story. A homograph works only if three things line up: the registry allows it, the alphabet can spell it, and the victim’s app shows it in Unicode. Today that happens most often in .com with a simple accent, not with exotic Cyrillic on a cheap TLD. For Czech and Slovak companies, .cz and .sk being IDN-free protects the local TLD, but a lookalike of your brand will simply live in .com instead.