How to Detect Punycode Lookalike Domains Bypassing Visual Inspection

Lookalike domains have become one of the quietest threats in email security. Attackers register domains that visually mimic a trusted brand, then use them in phishing campaigns designed to slip past both human eyes and basic filters. The tactic relies on the fact that most people scan URLs rather than read them letter by letter, so even a small substitution can go unnoticed.

In Australia, this problem is amplified by the widespread use of country-code domains like .com.au alongside global .com addresses. A staff member at a Sydney accounting firm, for example, might receive an email from "xero.com" when the real sender is operating from "xerо.com" using a Cyrillic "о" instead of a Latin "o." The Australian Cyber Security Centre has repeatedly warned that business email compromise remains one of the most reported cybercrime categories, and homograph-style lookalikes are a regular feature of those incidents.

Punycode is the technical bridge that makes these deceptions possible. It is a way of encoding Internationalised Domain Names so that browsers can resolve characters from non-Latin scripts, but the same system allows attackers to mix scripts in ways that look identical to a legitimate domain. When a browser renders a punycode string, it displays the Unicode characters rather than the raw ASCII, which is where the visual trickery lives.

Understanding how this works is the first step toward defending against it. The sections below walk through the mechanics, the visual tells, the tools that can help, and the habits that Australian security teams can build to catch these domains before they cause harm.

The Mechanics of Punycode in Phishing Campaigns

Punycode was designed with good intentions. It allows domain names to include characters from scripts such as Cyrillic, Greek, or Devanagari, supporting global internet access for non-English-speaking communities. The encoding converts those Unicode characters into an ASCII-compatible format starting with "xn--" so that the underlying domain system can handle them.

Attackers abuse this system by registering domains that combine Latin and non-Latin characters. To a human reader, "аpple.com" using a Cyrillic "а" looks identical to "apple.com." The browser happily displays the Unicode version, and the user sees what they expect to see. The punycode behind the scenes might be something like "xn--pple-43d.com," but that raw string is hidden unless someone inspects the source.

The result is a domain that passes casual inspection, bypasses some filters that only check the ASCII version, and lands in an inbox with a familiar-looking sender name. It is a technique that has been used against banks, logistics providers, and government services, and it shows no signs of slowing down.

Spotting the Unicode Switch in Suspicious URLs

Visual inspection is not useless, but it requires a more deliberate approach. The first habit to build is copying the domain from the email header rather than reading it off the display name. In most email clients, hovering over a link reveals the actual destination, and right-clicking to copy it gives you the raw string to examine.

When you have the raw string, look for the "xn--" prefix. This signals that the domain uses punycode encoding, which is uncommon for mainstream consumer brands. Legitimate Australian businesses operating under a .com.au or .com address will almost never use internationalised characters in their primary domain, so seeing "xn--" should be a red flag worth investigating.

Another tell is mixed-script rendering. If a domain claims to be a major Australian retailer but resolves to a string containing characters from multiple Unicode blocks, it is almost certainly a homograph attack. Tools that render the punycode string in its raw form, rather than the Unicode display, can confirm what is actually being requested.

Tools and Techniques for Technical Verification

For security teams, manual inspection is not scalable. Platforms that aggregate domain reputation data make it easier to spot newly registered lookalikes, and integrating those checks into existing workflows reduces the burden on end users. For automated screening, sender scoring tools can classify unknown inbound mail based on signals beyond the visible domain. These systems look at registration age, hosting infrastructure, and historical sending patterns to assign a trust score that helps mail servers decide whether to deliver, quarantine, or reject a message.

For developers and integrators, the same scoring logic is available through APIs, allowing custom checks to be built into internal portals, ticketing systems, or CRM tools. This is particularly useful for organisations in Melbourne or Brisbane that handle high volumes of supplier emails and want to flag suspect senders before staff interact with them.

Building Verification Habits for Australian Teams

Training is most effective when it reflects the threats people actually face. Australian workers are accustomed to seeing .com.au addresses from local banks, telcos, and utilities, so a lookalike using a foreign TLD or a punycode string should feel immediately out of place. Running short, scenario-based exercises using real homograph examples helps build that intuition, and structured phishing awareness training anchored in reputation data tends to stick better than abstract policy documents.

Reporting channels matter as well. The Australian Competition and Consumer Commission's Scamwatch service encourages individuals and businesses to forward suspicious emails, and internal reporting should be just as frictionless. If staff can flag a suspect message in two clicks, they are far more likely to do it than if the process involves forms or lengthy explanations.

Finally, organisations should review their own domain portfolio for lookalike registrations. Defensive registration of common homograph variants under the .com.au space is a standard practice for Australian enterprises, and it prevents attackers from acquiring the obvious spoofs in the first place.

Responding When a Punycode Domain Reaches Your Inbox

Speed matters once a punycode lookalike is identified. The first step is to block the sender at the mail gateway and add the domain to internal watchlists. From there, the message should be preserved as evidence, including full headers, and shared with the platform's abuse team or with Scamwatch if there is evidence of consumer targeting.

Communication is the next priority. Affected staff need to know what happened, what data may have been exposed, and what to watch for in follow-up attempts. Attackers often reuse a successful infrastructure, so a second wave using a slightly different punycode variant is common.

For ongoing protection, review the terms governing how the platform handles reported domains and data retention by checking the legal disclosures for any tooling you rely on. Clear policies on data handling make it easier to justify automated checks to compliance teams and to demonstrate due diligence if an incident is ever reviewed by regulators or auditors.