How do lookalike domains bypass DMARC?

Lookalike domains bypass DMARC because DMARC only validates the domain in a message's From address against records you publish for that exact domain. A lookalike — a separate registration such as examp1e.com or example-support.com — is not your domain, so DMARC on example.com never applies to it. The attacker can even publish their own SPF, DKIM, and DMARC on the lookalike and pass authentication cleanly. DMARC stops others from forging your domain; it was never designed to stop a different domain that merely resembles it.

At a glance

Quick takeaways

• DMARC authenticates the exact domain in the RFC 5322 From header, not domains that look similar.
• A lookalike (or "cousin") domain is registered and controlled by the attacker, so it can pass its own SPF, DKIM, and DMARC.
• Enforcing DMARC at p=reject on your domain does nothing to a message sent from a different domain.
• Defenses are layered: brand indicators, domain monitoring, takedowns, and recipient awareness — not DMARC alone.
• Reject-policy DMARC on every domain and subdomain you own still matters, because it closes the exact-domain spoofing path.

What is a lookalike domain?

A lookalike domain is a separate domain an attacker registers to impersonate a brand by resembling its real domain. They fall into a few common shapes:

• Typosquats: a plausible misspelling, such as gooogle.com or micrsoft.com.
• Homoglyphs: characters that look identical but are not, such as a digit 1 for a lowercase l, or Unicode letters from another script that render like Latin ones.
• Combosquats: the real brand plus an extra word, such as example-billing.com or secure-example.net.
• Alternate TLDs: the same name on a different top-level domain, such as example.co or example.io when the brand uses example.com.

To a recipient skimming a phone screen, any of these can pass for the real sender. That visual similarity is the entire attack — and it happens in the display of the From address, which is a layer above where DMARC operates.

Why does DMARC not stop them?

DMARC (RFC 7489) works by checking the domain in the message's From header against the authentication you publish in DNS. It requires that a message either pass SPF or DKIM and that the passing identifier align with the From domain. Crucially, the receiving server looks up the DMARC policy for the domain in the From address — whatever that domain happens to be.

That is the whole reason lookalikes slip through. When a message arrives From example-support.com, the receiver fetches the DMARC record for example-support.com, not for your example.com. Your policy is never consulted, because your domain is not in the From field. Two consequences follow:

1. Your enforcement is irrelevant to their domain. Setting p=reject on example.com protects example.com. It places no constraint on any other registration.
2. The attacker can be "compliant" too. Because they control the lookalike, they can publish valid SPF and DKIM and even a p=reject DMARC record on it. Their phishing mail then passes DMARC — for their own domain. Authentication confirms the message genuinely came from the lookalike; it says nothing about whether the domain is trustworthy.

This is the same scoping limit behind a broader question we cover separately: why phishing emails can pass SPF and DKIM. Authentication proves who sent it, not whether you should trust them.

What DMARC actually protects

It is worth being precise, because DMARC is still essential — it just solves a different problem. DMARC stops exact-domain spoofing: an attacker putting your real domain in the From address to make mail look like it came from you. Without DMARC enforcement, anyone can forge billing@example.com and many receivers will deliver it. With p=reject and aligned authentication, those forgeries are refused.

So the honest framing is a division of labor:

• Exact-domain impersonation (From: you@example.com, forged): DMARC at enforcement stops this.
• Lookalike-domain impersonation (From: you@examp1e.com, attacker-owned): DMARC cannot see this; other controls handle it.

Because the two overlap in the user's mind but not in the mechanism, the first defensive step is still to get every domain you own to enforcement. For the fundamentals, see what DMARC is; the newer DMARCbis (RFC 9989) standard refines how organizational domains and subdomains are resolved, but it does not change the fact that DMARC only covers domains you publish records for.

How do you actually defend against lookalike domains?

Because no single record can cover an unbounded set of registrations an attacker might buy, lookalike defense is layered. Combine these:

• Enforce DMARC on everything you own. Publish p=reject (or at least quarantine) on your primary domain, and set a subdomain policy so unused subdomains are covered too. This removes the easiest option — spoofing you directly — and forces attackers to the harder, more detectable lookalike route.
• Monitor for newly registered lookalikes. Watch for typosquats, homoglyphs, combosquats, and alternate TLDs of your brand as they are registered, so you learn about secure-example.net before your customers do.
• Take down active impostors. When a lookalike is used for phishing, report it to the registrar and hosting provider. Our guide on taking down lookalike domains walks through the process.
• Register the obvious variants defensively. Buying the closest typos and common alternate TLDs denies them to attackers — though you cannot register every permutation, so treat this as reducing risk, not eliminating it.
• Adopt brand indicators where supported. With DMARC at enforcement, BIMI can display your verified logo on authenticated mail in supporting mailboxes, giving recipients a positive signal that a lookalike cannot reproduce.
• Train recipients to check the full address. The attack lives in a display that looks right at a glance. Teaching people to expand and read the actual From domain closes the gap that DMARC structurally cannot.

Common issues with lookalike-domain defense

I set DMARC to p=reject but I am still getting impersonated

That is expected if the impersonation uses a lookalike rather than your exact domain. Enforcement protects your domain; it cannot reach a different registration. Confirm which domain the malicious mail is actually From — if it is not yours, shift effort to monitoring and takedowns rather than re-checking your DMARC record.

Can I block a lookalike with an SPF or DKIM record?

No. SPF and DKIM are records you publish for domains you control. You have no authority over an attacker's domain, and the attacker will simply publish their own passing records. These controls secure your sending; they are not a tool to disqualify someone else's domain.

How would I even know a lookalike exists?

Domain monitoring is how. New impersonation domains are registered constantly, and the useful window is between registration and first use. Watching brand-adjacent registrations — and reading DMARC aggregate reports for clues about impersonation attempts against your real domain — gives you lead time to act.

Does BIMI stop lookalike domains?

Not directly. BIMI shows a verified logo on authenticated mail from your domain, so it strengthens the signal for legitimate mail and makes a bare lookalike look comparatively less trustworthy. But it decorates your genuine mail rather than blocking anyone else's domain.

How Palisade helps

Lookalike defense starts from a position of strength only when your own domains are fully locked down, and that is the layer Palisade automates: getting SPF, DKIM, and DMARC deployed and moving your domains to enforcement, then reading the aggregate reports so exact-domain spoofing is closed and impersonation attempts are visible. That does not register or take down a cousin domain for you, but it removes the easy attack and clarifies where the remaining risk actually sits. Start by checking your domain's posture with the Email Security Score.

Related reading

• Why do phishing emails pass SPF and DKIM checks?
• How can I take down lookalike domains targeting my business?
• What is DMARC?