# How do lookalike domains bypass DMARC?

> Lookalike domains bypass DMARC because DMARC only checks domains you own. A cousin domain is a separate registration that passes its own authentication.

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.

## 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)](https://datatracker.ietf.org/doc/html/rfc7489) 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](/learning/why-do-phishing-emails-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](/learning/what-is-dmarc); the newer [DMARCbis (RFC 9989) standard](/learning/what-is-dmarcbis-rfc-9989-dmarc-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](/learning/how-can-i-take-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](/learning/what-is-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](/tools/email-security-score).

## Frequently asked questions

### Is a lookalike domain the same as a spoofed domain?

No. A spoofed message forges your real domain in the From address; DMARC at enforcement blocks that. A lookalike is a genuinely different domain the attacker owns and authenticates, which is why DMARC does not apply to it.

### If attackers can just use lookalikes, is DMARC still worth it?

Yes. DMARC closes the cheapest, most direct attack — impersonating your exact domain — and it is a hard requirement for bulk senders to Gmail and Yahoo. Removing the easy path forces attackers into the noisier, more detectable lookalike route.

### Can email filters catch lookalike domains on their own?

Some receiving filters flag newly registered or brand-adjacent domains, and that helps, but coverage is inconsistent and attackers adapt. You cannot rely on the receiver's filter as your only defense, which is why monitoring and takedowns matter.

## Related reading

- [Why do phishing emails pass SPF and DKIM checks?](/learning/why-do-phishing-emails-pass-spf-and-dkim)
- [How can I take down lookalike domains targeting my business?](/learning/how-can-i-take-down-lookalike-domains)
- [What is DMARC?](/learning/what-is-dmarc)