Lookalike Domains and Homoglyphs: Spotting Spoofed Senders

Most phishing does not need to fool a mail filter. It needs to fool a person reading a sender name and a domain in a hurry. Lookalike domains exploit that: a domain that differs from a trusted one by a letter, a character, a word or a suffix can pass a glance. Homoglyphs take this further by using characters that look identical to Latin letters.

Common techniques

The table below uses example.com as the trusted domain. None of the lookalikes are real registrations you should use.

How homoglyphs work

Domain names in Unicode are encoded for DNS using IDNA, which converts a name with non-ASCII characters into an ASCII form beginning with xn--. A domain that visually spells example.com but contains a Cyrillic letter is a different domain, and its ASCII form starts with that prefix. Many browsers and mail clients display the decoded Unicode name, which is why the trick works. Some show the encoded form when a domain mixes scripts, but you should not rely on the display.

You can check the ASCII form of a suspicious name with a standard library:

python3 -c 'print("exаmple.com".encode("idna").decode())'

The output starts with xn-- because the second character is not a Latin letter. A name that was entirely ASCII would print unchanged.

Check the headers, not the display name

The From display name is free text. Anyone can write "Example Billing" in it. The authentication results and the domains in the headers are more reliable. A suspicious message often looks like this:

From: Example Billing <billing@example-billing.net>
Reply-To: accounts@example-pay.net
Authentication-Results: mx.example.net; spf=softfail smtp.mailfrom=example-billing.net; dmarc=fail header.from=example-billing.net

Three things stand out: the sending domain is not the one the sender claims, the Reply-To points somewhere else, and authentication does not pass for the sending domain. Legitimate senders that publish a DMARC policy for their own domain make spoofing of that exact domain harder, but they cannot stop a separate lookalike domain they do not own. That is why the lookalike itself needs checking.

Practical checks

• Compare the domain letter by letter against a known good address, especially for payment, login and password-reset requests.
• Look at the Reply-To and Return-Path. A mismatch with the From domain is a strong warning sign.
• Do not click links to verify. Type the known domain yourself or use a bookmark, and check the request through a second channel.
• Use a password manager for logins. Autofill matches the stored domain, so a lookalike site will not be filled in. A missing autofill is a useful signal. See password managers and email.
• Read the authentication results in your mail client's headers view when a message asks for money or credentials.

If you run a domain

Publish a DMARC policy, begin with monitoring, and move toward enforcement once legitimate senders are aligned. The SPF, DKIM and DMARC explainer covers the basics. For brand protection, watch newly registered domains and certificate transparency logs for names that resemble yours, and file takedown requests with the registrar when a lookalike is used for abuse. Registrar lock and two-factor authentication on your own domain account prevent the more serious case, in which an attacker changes your records.

Lookalikes are a moving target, and no single check catches every one. Combine a habit of checking the domain with the authentication results and a second channel for anything involving money or credentials. For how to report abuse of a domain hosted on ITProMail, contact the support team.

Related reading

• Five tells of a modern phishing email
• OAuth Consent Phishing: Reviewing Which Apps Can Read Your Mail
• QR Code Phishing in Email: How It Works and How to Respond