why does DMARC not stop lookalike domains

DMARC checks whether the domain in the From header authorised or signed the message, and a lookalike domain authorises and signs its own mail. The policy of the domain being imitated is never consulted, because that domain is not the one in the header.

can a lookalike domain pass SPF DKIM and DMARC

Yes, and it normally does. The registrant controls the DNS of the lookalike, so they publish an SPF record, a DKIM key at their own selector and a DMARC record, and the message aligns perfectly as itself.

does p=reject protect my customers from lookalike domains

It protects them from mail that forges your exact domain, which is a real and cheap attack. It does nothing about a separately registered name; RFC 7489 says explicitly that DMARC does not address cousin domains.

will DMARC aggregate reports show mail sent from a lookalike domain

No. Reports are generated for the domain in the From header and sent to whoever published that domain's DMARC record. Mail from a lookalike produces reports for the lookalike, delivered to its registrant.

what does an Authentication-Results header show for a lookalike domain

Passes, with the lookalike named in every property: spf=pass with smtp.mailfrom on the lookalike, dkim=pass with header.d on the lookalike, and dmarc=pass with header.from on the lookalike. Read the domain after each result.

TECHNICAL

Why DMARC Does Not Stop Lookalike Domains (or SPF, or DKIM)

A message can pass every authentication check and still come from a stranger. Illustrative lookalikes in this guide use the reserved .test ending, so that no real registration is named.

by Typosquatting.ai Research17 September 2026updated 23 September 202611 min read

SPF, DKIM and DMARC are mechanisms that let a receiving mail server check whether a message really came from the domain it claims, which is a different question from whether that domain deserves to be trusted.

This guide covers what each mechanism checks, what DMARC alignment protects, why mail from a lookalike domain passes cleanly, a worked pair of headers, the lookalike types that pass, where display-name spoofing fits, and what closes the remaining gap.

What does each mechanism actually check?

The three are usually named together, which obscures how little they have in common. They check different things, using different parts of the message, and only one of them is tied to what the reader is shown.

Mechanism	Published as	What it checks
SPF, RFC 7208	A TXT record on the sending domain, beginning v=spf1	Whether the server that connected is one the domain authorised to send for it. It checks the envelope sender from the SMTP conversation, not the address in the message header.
DKIM, RFC 6376	A public key in a TXT record at a named selector under _domainkey	Whether a signature over selected headers and the body verifies against that key, and therefore that the signing domain takes responsibility for the message.
DMARC, RFC 7489	A TXT record at _dmarc on the domain	Whether an SPF or DKIM pass belongs to the same domain as the address in the From header, and what the domain owner wants done when neither does.

What does alignment mean?

Alignment is the whole of DMARC. The policy record asks a receiving server to compare the domain in the From header, the one displayed to the reader, against the domain that produced a passing SPF or DKIM result. If either matches, the message is aligned and DMARC passes. If neither matches, the published policy decides what happens next: none, quarantine, or reject.

Two things follow. Alignment is a comparison between a message's own two identities, not between the message and anything the recipient knows. And it is scoped to a single name: the record at _dmarc on the domain in the From header, with optional separate treatment of that domain's subdomains.

So the question DMARC answers is precise and narrow. Did the domain written in the From header authorise or sign this message. It is a good question, carefully specified and widely implemented. It is simply not the question the reader is asking.

Why does mail from a lookalike domain pass?

Because it is telling the truth. A lookalike domain is a real domain. Whoever registered it controls it, controls its DNS, and can publish whatever they like on it.

So they publish a valid SPF record for the servers they genuinely send from, publish a DKIM public key at a selector on their own domain and sign with the private key, and publish a DMARC record, at p=reject if they wish, because nobody is forging their name. The receiving server performs all three checks, and all three pass. The From header matches the signing domain and the envelope sender. The message is perfectly aligned.

Nothing has gone wrong. The message really is from the domain it says it is from. That domain simply happens to be one the reader has never dealt with, and cannot distinguish at a glance from one they have. The specification is candid about this: RFC 7489 says DMARC does not address the use of visually similar domain names, which it calls cousin domains, or abuse of the display name.

Authentication answers did this domain send it. It does not answer should you trust this domain. A domain's policy governs its own name and, at the owner's option, its subdomains; it does not reach a name somebody else registered. A domain registered this morning can be authenticated as thoroughly as one that has sent mail for twenty years, and what separates them lives in public records outside the mail path.

A worked example: the same checks, two different answers

RFC 8601 defines the Authentication-Results header that a receiving server adds to record what it found. The two lines below are what a server at example.org would write for a forged message claiming to be example.com and for a genuine message from examp1e.test, a lookalike with a digit one in place of the letter L.

Forged, example.com in the From header: Authentication-Results: mx.example.org; spf=fail smtp.mailfrom=invoices@example.com; dkim=none; dmarc=fail header.from=example.com
Genuine, examp1e.test in the From header: Authentication-Results: mx.example.org; spf=pass smtp.mailfrom=invoices@examp1e.test; dkim=pass header.d=examp1e.test; dmarc=pass header.from=examp1e.test
What differs: Only the domain in each property. The first line says example.com did not authorise this server and did not sign this message. The second says examp1e.test did both. Both statements are true, and neither says anything about whether the reader should trust the sender.

A rejection policy on example.com decides the fate of the first message and is never consulted for the second, because DMARC looks up the policy of the domain in the From header, and that domain is examp1e.test.

Which lookalike types pass authentication?

All of them, provided the sender configured the domain. The type only changes how the name is likely to be read. The table uses example.com as the impersonated name and example.org standing in for a public hosting platform.

Type	Example	Why it reads as genuine
Transposition	exmaple.test	Two adjacent letters swapped inside a familiar shape
Homoglyph	examp1e.test	A digit or a lookalike letter in place of the original
Brand plus word	example-billing.test	Reads as a department rather than another organisation
Ending swap	example.net	Reads as a regional or shortened site
Brand as a subdomain	example.example.org	The brand sits left, the registrable name sits right, where nobody looks
Added or dropped letter	exampple.test	Survives a glance because the word shape is intact

What does a rejection policy actually stop?

None of this is an argument against DMARC. A rejection policy closes a real and cheap attack, and leaving it open means an impersonator never has to spend money at all. The point is to be exact about where the boundary runs.

Technique	What the receiving server sees	Stopped by DMARC at p=reject
Exact-domain spoofing	Your domain in the From header, sent from infrastructure you never authorised, with no aligned signature	Yes. This is precisely what the mechanism was designed for.
Spoofing a subdomain of your domain	A name under your domain in the From header	Yes, where a subdomain policy is published or inherited.
Sending from a lookalike domain	A different registered domain in the From header, aligned and signed with its own key	No. It passes its own checks, and your policy is never consulted.
Display-name spoofing	A familiar name in front of an unrelated but properly authenticated address	No. The display name is not authenticated by anything.
A compromised mailbox at a genuine supplier	Genuine mail from a genuine domain, sent by somebody who should not be sending it	No. Nothing is spoofed.

How does display-name spoofing slip past?

The From header holds an optional display phrase in front of the address, and RFC 5322 places no constraint on what that phrase contains. It can hold a person's name, a brand, a job title, or a second email address written out in full so that a client shows something that looks like an address and is not one.

Nothing ties it to anything real. DKIM usually covers the From header, so a signature proves the display name was not altered after signing. It proves nothing about whether the sender was entitled to use that name, because the signature is made by the sender.

The exposure is worst on small screens, where clients show the display name and keep the address behind a tap. Display-name rules therefore belong at the gateway rather than in DNS. A rule that flags an external message whose display name matches an internal person is crude, and it catches a case no authentication mechanism was ever going to catch.

What do the aggregate reports show, and what do they miss?

A DMARC record can ask receiving servers to send periodic aggregate reports, and those are the most useful operational output of deploying it. Reaching enforcement without reading them is guesswork.

The blind spot is structural. Reports are generated against the domain in the From header, so you receive reports about your own name. Mail sent from a lookalike domain generates reports for the lookalike domain, delivered to whoever published its DMARC record. If that is an impersonator, they receive their own reports, and you receive nothing, because as far as the mail system is concerned you were not involved.

The same limitation runs through the rest of the mail stack. MTA-STS, defined in RFC 8461, lets a domain state that mail sent to it must use authenticated TLS, which protects the transport between servers. It is worth publishing, and it says nothing about who a sender is. None of these mechanisms were designed to answer a question about a name that is not yours.

The sending sources that used your domain in the From header, identified by the connecting address.
How many messages each source sent, and how many produced an aligned SPF or DKIM result.
Which mechanism passed and which failed, and therefore where a service of your own is unauthenticated.
What the receiving server did with the failures, judged against your policy.
Nothing whatsoever about any other domain, including one registered to resemble yours.

What actually closes the gap?

The gap is not closed by a mail mechanism, because it is not really a mail problem. It is a naming problem that surfaces in mail, and it is answered by knowing which names exist.

That is the job this checker does: it generates candidates from about twenty pattern families across about 180 endings, resolves them over DNS, and reads registry RDAP, certificate transparency logs and passive urlscan.io search without ever connecting to a suspect site. On the Pro plan every finding is re-checked daily and the certificate logs are searched every 30 minutes.

Finish the authentication work regardless. Publish SPF, sign with DKIM, and move DMARC to enforcement on every domain you own, including parked ones. This removes the cheap attack and forces an impersonator to spend money and leave a public record.
Discover the variations that exist. Generate candidates mechanically across the pattern families, the endings and the hosting platforms, then resolve every one over DNS.
Watch for mail configuration on those variations. MX records and a published sender policy on a lookalike mean somebody has done the work required to send from it, which is a reason to review it sooner.
Re-check continuously rather than occasionally. A name that was dormant last month and publishes MX records this week has changed in the direction that matters.
Give the gateway the rules authentication cannot express: mark external mail, flag recently registered sender domains, and flag a display name matching an internal person on an external address.
Remove the payoff. Confirm changes to payment details out of band, on a number you already held, so that a convincing message is never sufficient on its own.

What an authentication result cannot tell you

A passing SPF, DKIM or DMARC result tells you that a domain is responsible for a message. It tells you nothing about who registered that domain, when, why, or what they intend to do with it. A failing result is just as narrow: the most frequent cause of a DMARC failure on a well-known domain is a legitimate service that was never configured properly, not an attack.

Nor can authentication records be read as a verdict on a lookalike. A variation that publishes SPF, DKIM and DMARC has been configured by somebody who intends to send mail from it, and that is the whole of what the record establishes. Resellers, regional offices, agencies and unrelated businesses with similar names configure mail for entirely ordinary reasons. Reading a DMARC record is a DNS lookup, not a conversation with a mail server.

Similarity, and even a complete and correct mail configuration, is a reason to look sooner. It is never proof of intent.

Common questions

why does DMARC not stop lookalike domains: DMARC checks whether the domain in the From header authorised or signed the message, and a lookalike domain authorises and signs its own mail. The policy of the domain being imitated is never consulted, because that domain is not the one in the header.
can a lookalike domain pass SPF DKIM and DMARC: Yes, and it normally does. The registrant controls the DNS of the lookalike, so they publish an SPF record, a DKIM key at their own selector and a DMARC record, and the message aligns perfectly as itself.
does p=reject protect my customers from lookalike domains: It protects them from mail that forges your exact domain, which is a real and cheap attack. It does nothing about a separately registered name; RFC 7489 says explicitly that DMARC does not address cousin domains.
will DMARC aggregate reports show mail sent from a lookalike domain: No. Reports are generated for the domain in the From header and sent to whoever published that domain's DMARC record. Mail from a lookalike produces reports for the lookalike, delivered to its registrant.
what does an Authentication-Results header show for a lookalike domain: Passes, with the lookalike named in every property: spf=pass with smtp.mailfrom on the lookalike, dkim=pass with header.d on the lookalike, and dmarc=pass with header.from on the lookalike. Read the domain after each result.