Gmail Shows Lookalike Unicode Domains That Slip Past Chrome

Every letter in аррӏө.com is Cyrillic. In most fonts it reads as apple.com with a slightly odd final letter. Ian Muscat and Leanne Briffa of Have I Been Squatted published the work on October 3, 2026, and registered 20 such domains to prove the point.

The browser half of the story is a pair of edge cases in Chromium's lookalike rules. The email half is simpler and worse: Gmail does not apply those rules at all.

Key Takeaways

• Have I Been Squatted registered 20 lookalike domains, such as аррӏө.com and oƙta.com, that Chrome 154 displays in Unicode instead of the Punycode form it uses for suspected spoofs.
• Cyrillic ө (U+04E9) is missing from Chromium's 29 character Cyrillic lookalike list, and Latin ƙ keeps its hook through Chromium's skeleton comparison, so both characters break the checks.
• Gmail showed all 20 internationalized test senders in Unicode, including accented names like googlé.com that Chrome itself would show as Punycode, while Outlook Web showed all 20 as raw xn-- labels.
• The October 2026 .com zone held 154,567 internationalized names that resemble an existing ASCII .com name, forming 161,894 lookalike pairs, though the researchers say a pair is not proof of a typosquat.
• Neither the research post nor The Register's coverage includes a response from Google or Microsoft.

What Did the Researchers Find?

They found two characters that let a lookalike domain display as clean Unicode in Chromium browsers, the engine behind Chrome and Edge. The Have I Been Squatted research post names them:

• ө (Cyrillic barred o): a letter used in Kazakh, Mongolian and Tatar. It stands in for e in аррӏө.com and in 14 other Cyrillic names, including lookalikes of openai.com, skype.com and shell.com.
• ƙ (Latin k with hook): it powers the other five, among them oƙta.com, niƙe.com and vƙ.com.

The names are real registrations owned by the researchers and host demo pages. Under the hood, аррӏө.com is xn--80a6aa68c8d.com, its Punycode form, also called the A-label. Browsers are supposed to fall back to that ugly string when a name looks built to deceive. Chrome 154 did not.

How Does Chrome Decide Between Unicode and Punycode?

Chrome runs a domain through two stages, and a name must pass both to appear in Unicode. Chromium's IDN display policy describes the checks; the research walks through each one with аррӏө.com as the test case.

Stage one: the whole script rule

After Xudong Zheng registered an all Cyrillic аррӏе.com in April 2017, Chromium added a whole script confusable check. If every letter in a Cyrillic label sits on a list of characters that resemble Latin ones, Chrome shows Punycode. The list now holds 29 characters; Chromium added м on September 11, 2026, after Chrome 155 had branched.

The rule is all or nothing. One Cyrillic character off the list, which the authors call a breaker, switches it off for the whole label. ө is off the list. The researchers counted 64 lowercase Cyrillic characters that clear Chromium's allowed set and miss the lookalike list, and named three usable breakers today: ү, ө and ї. Chrome 148, released in May 2026, rejected two older breakers, ҏ and ӿ, after Unicode 17 marked them uncommon.

Stage two: the skeleton comparison

Chrome then reduces the hostname to a skeleton using the confusable mappings in Unicode Technical Standard 39 and compares it with 8,462 bundled popular domains, 836 of them in a top bucket. Accents are stripped first, so ókta.com reduces to okta.com and gets caught.

A hook is not an accent. ƙ is stored as one character, so diacritic stripping has nothing to remove; the later mapping turns it into k plus a combining mark that stays in the skeleton. ө behaves the same way, becoming o plus a bar. The skeleton of аррӏө.com ends up two code points away from apple, so no match.

Why Didn't Chrome Show a Warning on Navigation?

Chrome's navigation warnings only look for exact skeleton matches or names one edit away, and they skip short targets entirely. A separate check can show a full page interstitial or a Safety Tip bubble, but according to the research it:

• Looks for near matches of one edit or one swap of neighboring characters, and аррӏө.com is two edits from apple.
• Skips the near match step for targets shorter than five characters, so oƙta.com gets no near match check at all.
• Compares against sites the user visits often, which means a new user with little history gets less protection.

Result: both names load with no warning, the researchers write, "even for daily users of the real site." Anyone who has read our coverage of invisible Unicode characters hiding phishing lures will recognize the pattern: Unicode gives attackers characters that defenders' tables never listed.

Why Email Users Should Care: Gmail Skips the Check Entirely

Chromium's rules only judge the hostname in the address bar. A webmail page that has already decoded a sender's domain hands the browser plain text, and the browser checks nothing. So the researchers tested two webmail clients with 20 internationalized senders and two ASCII controls:

• Gmail on the web showed all 20 in Unicode. That included test@аррӏө.com, Zheng's original аррӏе.com, which Chrome has shown as Punycode since 2017, and five accented names on Chrome's bundled list: googlé.com, amazoñ.com, nètflix.com, coínbase.com and bìnance.com. The A-label appeared only in the separate mailed-by field, "which is not the address a reader checks."
• Outlook Web showed all 20 as A-labels, including harmless names like café.com and zürich.com.

The authors' verdict: "Gmail decoded everything, and Outlook Web decoded nothing." Neither client checked for lookalikes. Outlook's approach exposes this attack, but it also turns every legitimate international sender into an xn-- string.

Here is the part most coverage misses. In 2014 Google said Gmail would reject email with suspicious letter combinations, using the Unicode Consortium's Highly Restricted specification. Highly Restrictive is the same level Chromium uses to block mixed script labels, and the research shows аррӏө.com clears it because it mixes nothing: every letter is Cyrillic. A filter built on that standard is aimed at a different trick. One caveat matters, though. The test messages were imported into mailboxes through each provider's API, so the researchers did not measure spam filtering, sender reputation or link scanning on real delivery.

Authentication will not save you either. The researchers note that SPF, DKIM and DMARC "all pass for a lookalike the attacker owns." Those checks prove a message came from the domain it names, not that the domain is the one you think. We saw the mirror image in the iCloud spoofing flaw that passed SPF, DKIM and DMARC; a homograph sender does not even need a flaw.

How Many Lookalike Domains Already Exist?

About 154,567 internationalized .com names already resemble an existing ASCII .com name. Using the October 2026 .com zone file from ICANN's Centralized Zone Data Service, the researchers counted:

• 167,226,216 delegated .com names, 733,509 of them internationalized
• 154,567 internationalized names that map back to a registered ASCII name, forming 161,894 pairs across 133,953 distinct ASCII names
• 102,592 exact matches that Chromium would display in Unicode, all but 42 of them Latin

Put another way, internationalized names are under half a percent of .com, but roughly one in five of them (154,567 of 733,509) looks like someone else's ASCII domain. The authors stress that a pair "is a potential imitation, not a confirmed typosquat"; defensive registrations and multilingual sites are in the count. The Register's report on the research makes the same point. Phishing crews already buy domains by the thousand, as the 4,300 fake FIFA 2026 sites showed; a breaker character just makes each one harder to spot.

How Can Gmail Users Check a Sender's Real Domain?

Look at the encoded form, not the rendered name, and let software that matches exact domains do the judging. Steps that work today:

1. Expand the message details. In the research captures, Gmail's From line and expanded details showed аррӏө.com in Unicode, and only the mailed-by line showed the A-label. An xn-- there on mail from a brand that writes in English is a red flag.
2. Use Show original for anything that asks for a login or payment. Gmail's full header view (More, then Show original) prints the raw headers, and the research test messages carried the sender domain as an A-label in the From header.
3. Do not trust the address bar alone. аррӏө.com showed in Unicode with a valid certificate. If an email sends you to sign in, close it and open the site from a bookmark or by typing the name.
4. Treat a silent password manager as a warning. Chrome's autofill help page says its password manager "matches passwords with the websites they are meant for, and not sites that look similar." If it offers nothing on a site you use daily, stop.
5. Move important accounts to passkeys or a hardware key. The W3C WebAuthn standard scopes a credential so it "can only be accessed by origins belonging to that Relying Party." As the researchers put it, a passkey registered on apple.com "will not answer a login page on xn--80a6aa68c8d.com, whatever the address bar shows."

For Workspace and mail admins

• Turn on Protect against domain spoofing based on similar domain names in Gmail's safety settings. Its default action is to keep the email in the inbox with a warning; consider spam or quarantine. It only covers lookalikes of your own domains.
• Tag inbound mail from xn-- sender domains and keep external sender banners on, as the researchers recommend.
• Log, banner or block xn-- names in DNS and proxy logs outside an allowlist. The encoded name cannot be hidden by any display choice.
• Register the hooked and barred spellings of your own brand, especially names of four characters or fewer, which get no near match protection in Chrome.

Have Google or Microsoft Responded?

Not publicly. Neither the October 3 post nor The Register's October 10 article quotes Google or Microsoft, and the post does not say whether the findings were reported to either company before publication. Chromium's IDN policy notes that certain IDN spoofs qualify for Chrome's Vulnerability Reward Program.

The recent fixes have been one character at a time. Chrome 148 removed two breakers in May, and м joined the Cyrillic list in September but missed Chrome 155. Each patch closes one character, while the research counts 64 lowercase Cyrillic characters that still clear the allowed set and miss the list. The bigger gap is in the inbox. Until Gmail applies the same lookalike logic to sender domains that Chrome applies to the address bar, the safest habit is the boring one: never sign in from a link in an email.