does DMARC stop lookalike domains

No. DMARC compares the From domain of a message against the domain that passed SPF or DKIM, and a lookalike passes as itself. RFC 7489 says plainly that it does not address visually similar cousin domains.

how can I tell if an email was spoofed or sent from a lookalike domain

Open the full headers and find the Authentication-Results line added by your own mail server. A spoofed message shows failures against the real domain. Mail from a lookalike shows passes against a domain that is almost the one you expected.

what does spf=pass mean if the email is still fake

It means the server that sent the message was authorised by the domain in the envelope sender, and nothing more. If that domain is a lookalike, the pass is truthful and irrelevant, because the domain is not the one you trust.

why would an attacker register a domain instead of just spoofing

A registered domain can receive replies, hold a conversation, obtain a certificate and pass authentication. Forgery is cheaper but is closed by a rejection policy, so registration is what remains once a target has done its DMARC work.

THE BASICS

Email Spoofing vs Lookalike Domain: Forged or Registered?

The address in a From header is written by whoever sent the message. Whether the domain in it was forged or bought is the first thing worth knowing. 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 202612 min read

Email spoofing is a message whose From header names a domain the sender does not control, while a lookalike domain is a registered name that resembles the real one and sends genuine mail from itself.

This guide covers forging a header versus registering a name, which address a recipient sees, how to tell the two apart from an Authentication-Results header, a side-by-side comparison, the forms impersonation takes, and what the evidence cannot prove.

What is the difference between email spoofing and a lookalike domain?

Both make a message look as though it came from somewhere it did not, and both get called domain spoofing in casual use. They are different mechanisms, they fail to different defences, and they call for different work.

Email spoofing is forgery. A sender writes a domain they do not control into the From header and sends the message anyway. The mail protocols permit this: the header is composed by the sender, and the original design checked nothing against the machine doing the sending. This is the version SPF, DKIM and DMARC were built to answer, and on a domain with a published rejection policy they answer it well.

A lookalike domain is registration. Someone buys a name that resembles the real one and sends genuine mail from it. Nothing is forged: the message really did come from the domain in the From header, and every check a receiving server performs is asking about the wrong name. This is the version that survives the authentication work, and the DMARC specification says so itself: RFC 7489 states that it does not address the use of visually similar domain names, which it calls cousin domains, or abuse of the display name. Both rely on the same human fact. An email address is recognised rather than read.

Which address does a recipient actually see?

An email carries more than one sender address, and they are set in different places by different parties. RFC 5321 defines the SMTP conversation between mail servers, where the envelope sender is given in the MAIL FROM command. RFC 5322 defines the message itself, the headers and body that the envelope carries. A mail client shows the header From, and on a small screen often only the display phrase in front of it. That surface is what an impersonation has to satisfy.

Field	Where it is set	What the reader sees
Envelope sender (MAIL FROM)	The SMTP conversation, defined in RFC 5321	Normally nothing. It is used for routing and for bounces.
Header From	The message itself, defined in RFC 5322	The name and address presented as the sender.
Display name	The optional phrase in front of the address in the From header	Often the only part a mobile client shows.
Reply-To	The message header, set by the sender	Nothing, until the reader presses reply and the answer goes elsewhere.
Return-Path	Added by the receiving server from the envelope sender	Nothing, unless the reader opens the full headers.

How to tell which one you are looking at

The receiving server has already answered the question and wrote the answer into the message. RFC 8601 defines the Authentication-Results header field: the server that performed the checks adds a line naming itself, followed by statements of the form method=result with supporting properties. Open the full headers and find the line added by your own server.

In a forged message the checks run against the real domain, which never authorised the sending server, so they fail. In a message from a lookalike they run against the lookalike, which authorised its own servers and signed with its own key, so they pass. The difference is not whether the message passed. It is which domain it passed as.

The two headers below use example.org as the receiving server, example.com as the domain being impersonated, and examp1e.test, a digit one in place of the letter L, as the lookalike.

Forged header, real domain in From: Authentication-Results: mx.example.org; spf=fail smtp.mailfrom=accounts@example.com; dkim=none; dmarc=fail header.from=example.com
Registered lookalike in From: Authentication-Results: mx.example.org; spf=pass smtp.mailfrom=accounts@examp1e.test; dkim=pass header.d=examp1e.test; dmarc=pass header.from=examp1e.test
Reading the first: SPF failed for example.com, there was no signature, and DMARC failed for example.com. Somebody used the real name without permission. If example.com publishes p=reject, most receivers refuse this before anyone sees it.
Reading the second: Every check passed, and every property names examp1e.test. The message is exactly what it claims to be: mail from a domain you have never dealt with. Nothing published by example.com was consulted.

Read the property after each result, not the result alone. A dmarc=pass with header.from=examp1e.test is a truthful statement about the wrong domain. Copy the address out as text and compare it character by character.

Forgery and registration side by side

The two techniques differ on almost every axis that matters to a defender: what they cost the sender, what stops them, what they leave in the public record, and how long they last.

Question	Forgery (spoofed header)	Registration (lookalike domain)
What it costs the sender	Nothing. A From header is text.	A registration fee and a public record.
What DMARC at p=reject does	Rejects it, if the impersonated domain publishes the policy.	Nothing. The lookalike's own policy is consulted, and it passes.
What Authentication-Results shows	spf=fail or dkim=none against the real domain, dmarc=fail	spf=pass, dkim=pass and dmarc=pass against the lookalike
What the public record shows	Nothing new. No name was registered.	A creation date, a registrar, nameservers, often MX and a certificate.
Whether a reply reaches the sender	Rarely. Replies and bounces go to the real domain.	Yes. The lookalike receives mail, so a conversation can run.
How long it lasts	Until the impersonated domain reaches enforcement.	Until the name is suspended, transferred or allowed to lapse.
Who can act on it	The impersonated domain's owner, by publishing policy.	The registrar, the host, browser and mail programmes, a dispute panel.

What forms does sender impersonation take?

The techniques differ in what they forge, what they register, and what they need the reader to miss. Ordered by how much control the sender has over the domain:

Exact-domain spoofing. The real domain in the From header, sent from unrelated infrastructure. Cheap, and closed by a published rejection policy.
Display-name spoofing. The phrase in front of the address reads as a familiar person or brand, while the address behind it is unrelated and may be authenticated perfectly well by its own domain.
A registered lookalike domain. A variation the sender owns, sending real mail that nothing in the message contradicts.
Prefix and subdomain constructions. The familiar word appears as a label under a domain somebody else owns, so the brand is in front of the reader while the registrable name sits further right.
Reply-To redirection. The From address is left untouched and RFC 5322 lets the reply be routed quietly to a different mailbox. Many clients never show the destination.
A compromised mailbox at a genuine supplier. Nothing is spoofed at all, which is exactly why authentication has nothing to say about it.

Why does a lookalike domain work on a reader?

Reading a domain name is a recognition task, not a comparison. People take in the shape of a familiar word and move on, which is why a transposed pair of letters in the middle of a long name survives a glance, and why a character borrowed from another script can survive a careful one. A brand joined to a word such as billing or invoices reads as a department; the same name under a different ending reads as a regional site.

Context does the rest. The dangerous version is rarely a single message with a link in it; it is a conversation. A domain that can receive mail can hold a thread until the request that matters, a change to bank details or an invoice reissued against a new account, arrives with the address already familiar.

What does a sender gain by registering rather than forging?

Registration costs money and leaves a public record, so it is worth asking what it buys. The answer is durability.

Mail from a domain they own is authenticated by their own records, so it passes the checks a receiving server performs.
The domain can receive mail, so a reply reaches them and a conversation can continue.
Certificates can be issued for it, so a link leads to a page over HTTPS with no browser warning.
It survives the closure of any single sending account, because the identity is the domain rather than the mailbox.
It can be aged: registered quietly, left dormant for weeks, and used once a recent registration has stopped being a useful signal.
It can carry a supporting cast: a web page, addresses that look like departments, and a signature block that matches.

What shows in the public record before the mail arrives?

Sending mail from a domain requires preparation, and the preparation is public. None of the signals below involves touching the domain in question. Each is a record read at a distance: a registry lookup, a DNS query, a transparency log search, or a passive observation made earlier.

The registration itself. RDAP returns a creation date, and a name created weeks ago behaves differently from one unused for years.
A certificate. Certificate transparency logs frequently move first, because a certificate is issued when someone prepares to serve a page.
Nameservers with no address. A delegated name with nothing published on it has been bought and set up and not yet used.
MX records. Mail routing is a deliberate configuration, not a side effect of registration.
TXT records carrying a sender policy. A variation publishing its own v=spf1 record has been configured by somebody who intends to send from it.

What should an organisation do about it?

The work divides into what you publish, what you know about, and what you decide in advance. Only the first of those is a mail task.

On the second, a checker such as this one generates the variations from about twenty pattern families across about 180 endings, resolves them over DNS and never connects to a suspect site; the evidence comes from registry RDAP, DNS over HTTPS, certificate transparency logs and passive urlscan.io search, and on the Pro plan findings are re-checked daily with the certificate logs searched every 30 minutes.

Publish and enforce mail authentication on every domain you own, including the ones that never send. It does not stop a lookalike, but it closes the exact-domain case, and leaving it open means competing against a cheaper attack.
Keep an inventory of the names you already hold, defensive registrations included, because a large part of a first check is usually your own portfolio.
Treat mail records on a variation as a reason to review it sooner, never as a verdict.
Make the finance process independent of email. A change to payment details confirmed on a number you already held removes the payoff whether or not anybody noticed the domain.
Mark external mail and newly registered sender domains at the gateway, and decide who confirms ownership, who preserves evidence and who contacts the registrar before you have a real finding.

What the evidence cannot establish

Every signal described here is circumstantial. A registered variation with mail records is a domain configured to send and receive mail. It is not a phishing campaign, and calling it one before anybody has seen a message is a claim the record does not support. Resellers, regional offices, agencies, forwarding services and unrelated businesses with similar names all publish mail records, and so do brands protecting themselves.

The records also say nothing about the message. Reading an MX record is a DNS lookup, an enquiry to a resolver about what a name publishes, not contact with the mail server named in the answer. And it is a snapshot: DNS answers change without notice, so a finding worth acting on is worth preserving with its date. Similarity is a reason to look sooner. It is never proof of intent, which is why every rule behind every label applied here is published.

Common questions

what is the difference between email spoofing and a lookalike domain: Email spoofing forges the real domain into the From header of a message sent from somewhere else, and it fails SPF, DKIM and DMARC on a domain that publishes them. A lookalike domain is a separately registered name that resembles the real one and sends genuine mail from itself, so it passes every check as itself.
does DMARC stop lookalike domains: No. DMARC compares the From domain of a message against the domain that passed SPF or DKIM, and a lookalike passes as itself. RFC 7489 says plainly that it does not address visually similar cousin domains.
how can I tell if an email was spoofed or sent from a lookalike domain: Open the full headers and find the Authentication-Results line added by your own mail server. A spoofed message shows failures against the real domain. Mail from a lookalike shows passes against a domain that is almost the one you expected.
what does spf=pass mean if the email is still fake: It means the server that sent the message was authorised by the domain in the envelope sender, and nothing more. If that domain is a lookalike, the pass is truthful and irrelevant, because the domain is not the one you trust.
why would an attacker register a domain instead of just spoofing: A registered domain can receive replies, hold a conversation, obtain a certificate and pass authentication. Forgery is cheaper but is closed by a rejection policy, so registration is what remains once a target has done its DMARC work.