Skip to content

Lookalike domains: detecting cousin-domain phishing

Typo and homoglyph domains pass authentication for themselves. Monitor new registrations, register obvious variants and train people to check senders.

Koltrix Team4 min read
A magnifying glass on a white table
Photo by Markus Winkler on Unsplash
On this page(8 sections)
  1. Kinds of lookalike domains
  2. Homoglyphs and internationalized domain names
  3. Why authentication cannot stop them
  4. Reduce supply: defensive registration
  5. Detect: monitor new registrations and certificates
  6. Respond: what to do when you find one
  7. Help people and filters notice
  8. Checklist
  9. Key takeaways

Once your DMARC policy is at p=reject, attackers can no longer send as example.com. So they register examp1e.com, publish their own perfect SPF, DKIM and DMARC records, and send from there.

The mail authenticates, because it really is from the domain it claims. Your job shifts from authentication to detection.

Kinds of lookalike domains

Lookalike, or cousin, domains come in a handful of patterns:

Pattern Example for example.com
Character substitution examp1e.com, exarnple.com (rn for m)
Omission or repetition exmple.com, exaample.com
Transposition exmaple.com
Added words example-billing.com, example-support.net, secure-example.com
Different TLD example.co, example.io, example.email
Subdomain tricks example.com.account-verify.example.net
Homoglyphs (IDN) Characters from other scripts that look identical to Latin letters

The subdomain trick is easy to miss: the domain that matters is the registrable part at the end, example.net in that case, not the familiar words at the beginning.

Homoglyphs and internationalized domain names

Internationalized domain names allow non-ASCII characters, encoded in DNS as "punycode" strings beginning with xn--. Some characters in Cyrillic or Greek look identical to Latin letters in many fonts. A domain using a Cyrillic "а" in place of a Latin "a" can be visually indistinguishable from yours.

Browsers have rules for when to display the punycode form instead of the Unicode form, which reduces this risk on the web. Email clients vary more. Security tools that normalize and compare domains are the practical defense.

Why authentication cannot stop them

SPF, DKIM and DMARC answer "is this message really from the domain in the From address?" For a lookalike domain, the answer is yes. The attacker controls examp1e.com and has every right to authenticate it. Some attackers deliberately set up strong authentication so their mail looks more trustworthy to filters.

That leaves three lines of defense: reduce the supply of convincing lookalikes, detect the ones that appear, and help people and filters notice them.

Reduce supply: defensive registration

Register the most obvious variants yourself:

  • Common typos of your primary domain.
  • Your name with the most relevant country-code and generic TLDs for your market.
  • Hyphenated or suffixed versions an attacker would most likely choose, such as your name plus "billing," "support" or "login."

You cannot register everything; the combinations are effectively unlimited. Focus on the handful that would be most convincing in a phishing email to your customers or finance team.

Every domain you register defensively should then be locked down for email: a null MX record, v=spf1 -all, and a DMARC policy of p=reject. Otherwise you have bought a domain that attackers can spoof instead of register.

Detect: monitor new registrations and certificates

Two public data sources reveal new lookalikes, often before they are used:

  • Newly registered domain feeds. Several commercial and some free services publish lists of newly registered domains. Matching them against variations of your name catches many lookalikes within a day of registration.
  • Certificate Transparency logs. Publicly trusted TLS certificates are logged in public CT logs. Attackers who set up a phishing website on a lookalike domain usually obtain a certificate, which appears in the logs. Monitoring CT for names similar to yours is effective and inexpensive.

Detection is about fuzzy matching. A simple approach generates candidate variants of your domain and compares new registrations against them, plus a similarity score such as edit distance for things your generator did not anticipate.

def variants(name: str, tld: str = "com") -> set[str]:
    out = set()
    for i in range(len(name)):
        out.add(name[:i] + name[i + 1:] + "." + tld)              # omission
        out.add(name[:i] + name[i] * 2 + name[i + 1:] + "." + tld)  # repetition
        if i < len(name) - 1:                                      # transposition
            out.add(name[:i] + name[i + 1] + name[i] + name[i + 2:] + "." + tld)
    swaps = {"l": "1", "o": "0", "m": "rn", "i": "l"}
    for a, b in swaps.items():
        if a in name:
            out.add(name.replace(a, b) + "." + tld)
    out.discard(name + "." + tld)
    return out

Open source tools exist that do this far more thoroughly, including homoglyph and IDN variants. The value is in running them continuously, not once.

Respond: what to do when you find one

  1. Collect evidence. DNS records, WHOIS data, screenshots of any website, and examples of mail if you have them.
  2. Check whether it is active. Does it have MX records? A website? An SPF record suggests it is set up to send.
  3. Warn internally. Add the domain to inbound block or tagging rules on your own mail system so employees are protected immediately.
  4. Report abuse. Registrars and hosting providers have abuse contacts and often act on clear phishing evidence. Some registries and dispute processes handle trademark-based complaints; that is a matter for your legal team.
  5. Warn customers if needed. If the domain is targeting customers, a short notice describing what genuine mail from you looks like helps.

Help people and filters notice

  • Inbound filtering rules can flag or quarantine messages from domains within a small edit distance of yours, or from very recently registered domains. Treat this as a tagging rule first and tune false positives.
  • External sender banners remind staff that a message came from outside, which is exactly the clue a lookalike tries to hide.
  • Training with concrete examples shows staff how examp1e.com looks in their actual mail client, on desktop and on mobile.
  • Payment verification processes stop the most damaging outcome even when the email itself is convincing.

Checklist

  • Defensively register the most convincing variants and lock them down with null MX, -all and p=reject.
  • Monitor newly registered domains and Certificate Transparency logs for lookalikes.
  • Add discovered lookalikes to inbound blocking or tagging rules.
  • Report active phishing domains to registrars and hosts.
  • Flag inbound mail from very new or near-match domains.
  • Require out-of-band verification for payment and banking changes.

Key takeaways

  • Lookalike domains authenticate legitimately, so SPF, DKIM and DMARC cannot stop them.
  • Defensive registration reduces the most convincing options; lock those domains down for email.
  • Certificate Transparency and new-registration monitoring catch many lookalikes early.
  • Internal filtering, banners and payment controls protect people when detection misses one.

Start with Koltrix

Your domain, one inbox, and an API that sends.

A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.

SharePost on XLinkedIn