Lookalike and cousin domains

25 May 2026 · 11 min read

You have done the hard work. Your domain is at p=reject, SPF is clean, DKIM signs every message, and exact-domain spoofing is dead. Then a customer forwards you a phishing email that looks exactly like your brand, with your logo, your tone, your signature, and a payment link. You check the From: address and it reads support@acme-billing.com, or accounts@acmе.com with a Cyrillic letter hiding in plain sight. Your DMARC record never had a chance, because the message never claimed to be from your domain in the first place.

This is the uncomfortable truth about lookalike and cousin domains: they are not a hole in your authentication, they are an attack that deliberately goes around it. Understanding exactly why DMARC cannot stop them, and what genuinely can, is the difference between a false sense of security and a real defensive plan. This guide walks through how attackers register confusable domains, the precise reason your DMARC policy is powerless against them, and the layered defences that actually work.

If you have not yet locked down your own domain, do that first: an unprotected exact domain is a far cheaper target than a lookalike. Start with what is DMARC and confirm your posture with the DMARC checker. This article is about the threat that remains after you have done that.

What "lookalike" and "cousin" actually mean

The terms get used loosely, so it helps to separate the two families. Both impersonate your brand using a domain the attacker controls, but they fool the human eye in different ways.

A lookalike domain (sometimes called a homoglyph or homograph domain) relies on characters that look like yours but are not. The classic technique is to register a name that is visually almost identical when read quickly:

• Substituting visually similar Latin characters: rn in place of m (so ac-modern.com becomes acrnodern.com), 1 for l, 0 for o, vv for w.
• Using internationalised domain names (IDNs), where non-Latin scripts contain glyphs that render identically to Latin letters. A Cyrillic "а" (U+0430) is pixel-for-pixel the same as a Latin "a" (U+0061) in most fonts, so аcme.com and acme.com are different domains that look the same.
• Combining marks and lookalikes from Greek, Armenian and other scripts to reproduce a target string the eye reads as your brand.

A cousin domain does not bother with trickery at the character level. It registers a plausible, readable, different name that a recipient will trust because it sounds like something your organisation would own:

• Adding a believable word: acme-support.com, acme-billing.net, secure-acme.com, acmepayments.com.
• Swapping the top-level domain: you own acme.com, they register acme.co, acme.net, acme.org, acme.io or a country code like acme.com.co.
• Hyphenating or merging your existing words: acme-invoices.com when your real domain is acmeinvoices.com, or vice versa.

The difference matters for defence. Lookalikes can often be caught by software that normalises and compares character sets. Cousin domains are valid, ordinary names that no automated lookalike scan will flag as confusable, because to a computer acme-billing.com shares no suspicious glyphs with acme.com. They rely entirely on human trust in a familiar-sounding string.

You can see the lookalike family generated for your own brand using the lookalike domain checker, which enumerates the common homoglyph and typo permutations of a domain so you can see what an attacker would register.

Why DMARC on your domain cannot stop them

This is the core of the article, and it is worth being precise, because the reasoning is often hand-waved.

DMARC makes a single, narrow promise. It lets a receiving mail server check whether a message's visible From: domain is authorised and aligned with the SPF or DKIM result, and it tells the receiver what to do when it is not. Crucially, the domain in that policy lookup is the attacker's domain, not yours.

Walk through what happens when a fraudster sends from support@acme-billing.com:

1. The receiving server reads the From: header and extracts the domain: acme-billing.com.
2. It looks up the DMARC record at _dmarc.acme-billing.com. That is the attacker's DNS, not yours.
3. If the attacker has set up authentication for their own domain (which is trivial, it is their domain), SPF and DKIM pass and align with acme-billing.com.
4. DMARC therefore passes. The receiver delivers the message, possibly with the green ticks that signal a trustworthy, authenticated sender.

Your domain, acme.com, was never consulted. Your p=reject policy lives at _dmarc.acme.com and is only ever read when a message claims to be from acme.com. A message from a different domain never triggers it. DMARC is a per-domain policy that protects the exact name it is published under, and nothing else.

This is the single most misunderstood point about email authentication, so let it land clearly: DMARC stops people pretending to be you. It does nothing about people pretending to be near you. The whole protocol is built around the visible From: domain, and a cousin or lookalike domain is a real, different From: domain that the attacker owns and can authenticate perfectly. If anything, a competent attacker will configure SPF, DKIM and DMARC on their lookalike domain so the message sails through with full authentication and looks more legitimate than a sloppy real sender.

For the deeper mechanics of why alignment is tied to the From domain, see DMARC alignment explained and what is DMARC. The same logic explains why BIMI, which displays your brand logo only on authenticated mail from your domain, also cannot help here: the lookalike is not your domain, so it never qualifies for your logo. That is a small silver lining, covered in what is BIMI: a verified logo on the real domain gives recipients one more contrast against the impostor.

A common false hope: subdomains and sp

People sometimes ask whether a tight subdomain policy helps. It does not, for the same reason. Your subdomain policy (sp=) governs anything.acme.com. A lookalike like acme-secure.com is not a subdomain of your domain at all, it is an unrelated registration. Subdomain policy is still worth getting right to stop attackers abusing your unused subdomains, which is a separate and real risk covered in the DMARC subdomain policy, but it has no bearing on cousin domains.

How attackers actually use these domains

Registering the domain is step one. The attack value comes from how it is used, and knowing the playbook tells you what to watch for.

Direct phishing of your customers. The most common use. The attacker sends invoices, password resets, delivery notices or "account suspended" warnings from the lookalike, banking on recipients trusting a familiar-looking sender. Because the domain authenticates cleanly, spam filters give it less friction than a clumsy spoof.

Business email compromise and supplier fraud. Cousin domains are the engine of invoice redirection fraud. An attacker registers a domain one character off from a supplier's, inserts themselves into an email thread, and asks for "updated bank details". The reply-to and From look right at a glance, and money moves before anyone scrutinises the spelling. This is frequently aimed at your finance team using a supplier's lookalike, and at your suppliers using your lookalike.

Credential harvesting websites. The domain hosts a pixel-perfect copy of your login page. Email is the delivery vehicle, but the payload is the web link. This is why URL-level defences matter as much as email ones; you can sanity-check a suspicious link with the phishing URL checker.

Reputation warming and dormancy. Sophisticated actors register lookalikes months in advance, let them age, sometimes send benign traffic to build a clean reputation, then activate them for a campaign. A domain registered yesterday is suspicious; one registered eighteen months ago looks established. This is exactly why monitoring for new registrations is necessary but not sufficient.

Display-name spoofing as a cheaper cousin. Worth a mention because it is adjacent: many attacks do not register any lookalike at all. They set the display name to "Acme Billing" while the actual address is some throwaway user5821@gmail.com. Most mail clients show only the display name. This is technically not a domain attack, but it preys on the same human shortcut, and it is even cheaper than registering a domain. The defence overlaps, so keep it in scope.

How to defend: a layered plan

There is no single switch for this, because the attacker is operating on infrastructure you do not control. Defence is a stack of overlapping measures, each closing part of the gap.

1. Lock down your own domain first

This sounds contradictory given everything above, but it is the foundation. If your real domain is spoofable, attackers will not bother with the cost and effort of a lookalike, they will just spoof you directly, which is free. Reaching p=reject removes the cheapest attack and forces adversaries onto lookalike domains, which are more expensive, more detectable, and leave a registration paper trail.

• Get to enforcement: DMARC policy: none, quarantine or reject.
• Verify SPF, DKIM and DMARC together at /tools, starting with the DMARC checker, the SPF checker and the DKIM checker.
• Add a verified BIMI logo so your genuine mail carries a visual marker the lookalike cannot reproduce.

This is the part DMARC Engine automates end to end: the DMARC product takes a domain from p=none to p=reject with no email outage, which is precisely how you eliminate the cheap direct-spoof option and push attackers into the open.

2. Defensively register the obvious variants

For a modest annual cost, register the highest-risk permutations of your own brand before an attacker does, and point them at nothing (no MX, an explicit null SPF, and a p=reject DMARC record so they cannot be used to send). Prioritise:

• Common typos and character swaps a human would not notice.
• The handful of alternative TLDs your customers might assume you own (.com, .co, .net, your country code).
• Hyphenated forms with words like support, billing, secure, pay, login.

Use the lookalike domain checker to enumerate the candidate set, then make a judgement call on which to buy. You cannot register every permutation (the homoglyph space is effectively infinite once IDNs are included), so spend on the ones a real recipient would plausibly trust, not on exotic combinations no one would ever read as your brand.

For any defensive domain you do own, publish a null-sending posture so it can never be turned against you:

; SPF: this domain sends no mail
acme-billing.com.  IN  TXT  "v=spf1 -all"

; DMARC: reject everything, no exceptions
_dmarc.acme-billing.com.  IN  TXT  "v=DMARC1; p=reject;"

The mechanics of locking a non-sending domain are the same as for a parked domain: see DMARC for domains that do not send mail.

3. Monitor for new registrations and live abuse

You cannot block what you cannot see. Set up ongoing watch on:

• Newly registered domains that are confusable with yours. Registration and certificate-transparency feeds surface these within hours. A WHOIS lookup on a suspect domain (try the WHOIS domain lookup) tells you registration date, registrar and, where available, contact details for an abuse report.
• TLS certificates issued for lookalike names. Every public certificate is logged to certificate transparency, so an attacker who stands up an HTTPS phishing site leaves a public record of the hostname almost immediately.
• Your own DMARC reports. This is the subtle one. DMARC aggregate reports for your domain will not show traffic from a cousin domain, because that traffic is not using your domain. But reports are still your early-warning system for direct spoofing attempts that precede or accompany a lookalike campaign, and for changes in your own sending. Read DMARC RUA and RUF reports and analyse them with the DMARC report analyzer.

Continuous monitoring with change alerts is exactly what /monitor provides for your authentication posture, so a regression on your real domain (which would re-open the cheap attack) gets flagged the moment it happens.

4. Make the human the last, informed line

Because cousin domains authenticate cleanly, technology will let some through. The final layer is the recipient, on both sides of your business.

• Train finance and operations teams that bank-detail changes always require out-of-band verification: a phone call to a known number, never a number in the email. This single habit defeats most invoice-redirection fraud regardless of how convincing the domain looks.
• Teach people to read the full address, not the display name, and to be suspicious of any TLD or hyphenation that differs from the one they have used before.
• Encourage customers to report suspicious mail to a published address (abuse@ or security@ on your real domain), giving you the intelligence to file takedowns.

5. Take down what you find

When you confirm an active lookalike, act fast:

• Report to the registrar and hosting provider with evidence (the phishing email, screenshots, the URL). Most have an abuse process and will suspend clear phishing domains.
• Report the URL to browser safe-browsing programmes (Google Safe Browsing, Microsoft SmartScreen) so the page is flagged in the major browsers, which blunts the attack even before the domain is removed.
• For persistent or high-value abuse, escalate to a brand-protection or domain-takedown service, or pursue UDRP action where there is clear trademark infringement.

Speed matters more than perfection. A phishing site taken down in two hours does a fraction of the damage of one that runs for two days.

Putting it together

Lookalike and cousin domains are not a flaw in DMARC; they are the predictable next move once DMARC has closed the door on spoofing your real domain. DMARC protects the exact name it is published under, and an attacker who registers a different name they fully control can authenticate it perfectly, which is why your p=reject policy never even gets consulted. Accepting that clearly is what lets you stop looking for a DMARC setting that does not exist and start building the defence that does work.

That defence is layered: lock your own domain to enforcement so direct spoofing is off the table, defensively register the most believable variants, monitor registrations and certificate logs so new threats surface early, keep reading your DMARC reports for changes on the domain you do control, and put out-of-band verification habits in front of the people who move money. No single layer is complete, but together they make your brand an expensive, noisy, short-lived target instead of an easy one.

The practical first step is the one that pays for everything else: make your real domain unspoofable, because an attacker who cannot impersonate you directly has to expose themselves on the open registration market to impersonate you at all. Check where your domain stands today with the DMARC checker, map your lookalike exposure with the lookalike domain checker, and if you would rather have the journey to p=reject and the ongoing monitoring with change alerts handled for you, that is exactly what the DMARC product and continuous monitoring are built to do.