Email Spoofing vs Lookalike Domains: Why DMARC Stops One but Not the Other

An organisation can reach DMARC p=reject, stop every message forged in its own domain, and still lose a six-figure payment to an email from a domain one letter different from its own. Exact-domain spoofing and lookalike domains look the same to the person reading the message, but they are different attacks, and the controls that stop one do almost nothing against the other. This guide compares them side by side: how each works, why DMARC covers one and not the other, which controls stop which, how they appear in business email compromise (BEC), what signals detect them, and how to build a layered plan. It is written for email administrators, security operations teams and fraud owners. Configuration detail lives in the DMARC, SPF and DKIM Guide, the Display Name and Exact Domain Spoofing Guide and the Typosquatting and Lookalike Domains Guide; this page is about telling the two problems apart and funding the right controls for each.

Key takeaways

• DMARC protects a name, not a resemblance: RFC 9989 states that DMARC directly combats only specific forms of exact-domain spoofing and does not address visually similar domain names or display names.
• A lookalike domain can pass authentication: the attacker owns it, so it can publish valid SPF, DKIM and even DMARC records, and receivers will see a fully authenticated message.
• Exact-domain spoofing is a problem you can largely close: DMARC at p=reject on every domain you own, including non-sending ones, removes it for receivers that enforce DMARC.
• Lookalikes are a problem you manage, not close: you cannot register every variant, so the work is detection (registrations, certificates, inbound mail), user and process friction, and takedown.
• The payment process is the last control for both: out-of-band verification of bank detail changes stops the loss whichever technique the attacker used.

The short answer

Exact-domain spoofing puts your real domain in the visible From address of a message you did not send. DMARC, with SPF and DKIM aligned, lets receiving servers detect and reject that. A lookalike (cousin) domain is a different domain the attacker registered, such as a swapped letter, an extra hyphen or a different top-level domain, so it is not your domain and your DMARC record never applies. Defending against it needs inbound impersonation detection, domain monitoring, takedown, warnings for unfamiliar senders and verification of payment requests. Display name spoofing, where only the human-readable name is faked, sits outside DMARC too.

Exact-domain spoofing: threat model, mechanics and controls

Threat model. The attacker wants the strongest possible trust signal: your real domain in the From line. Targets are your own staff (a fake message from the chief executive), your customers (fake invoices or password resets) and your suppliers. The attacker does not need access to your systems, only a mail server willing to send the message.

Mechanics in words. Email has two sender identities. The envelope sender (RFC5321.MailFrom) is what SPF checks, and the header From (RFC5322.From) is what the recipient sees. Without DMARC, an attacker can pass SPF for their own envelope domain while putting your domain in the visible From. DMARC closes this gap by requiring that a passing SPF or DKIM result is aligned with the visible From domain, either exactly (strict) or within the same organisational domain (relaxed), and by publishing your policy for messages that fail.

Failure modes.

• Stuck at p=none: reports arrive, nothing is blocked, and the domain remains spoofable for years.
• Non-sending domains forgotten: parked and legacy domains with no DMARC record are spoofed instead of the main one.
• Subdomain gaps: a subdomain policy (sp=) left at none, or subdomains with their own permissive records.
• Receivers that do not enforce: some receiving systems ignore DMARC or override it, so enforcement is not universal.
• Your own inbound gateway overrides: allow lists and bypass rules that let spoofed messages of your own domain reach staff.

Controls. Inventory every domain you own; publish SPF, DKIM and DMARC for sending domains and move to p=reject; publish a null SPF record (v=spf1 -all) and DMARC p=reject for non-sending domains; set sp=reject; monitor aggregate reports for unauthorised sources. On the receiving side, make sure your own email platform honours DMARC and rejects or quarantines inbound mail that spoofs your domains. The DMARCbis Changes Guide covers what RFC 9989 changed from RFC 7489.

Lookalike domains: threat model, mechanics and controls

Threat model. The attacker accepts a weaker trust signal in exchange for full control. Most recipients read the display name and glance at the domain, especially on mobile, so a close variant is often enough. The FBI's IC3 BEC advisory tells recipients to check for misspelled domains in links and to verify sender addresses, particularly on mobile devices, because the visible address may not match the claimed sender.

Mechanics in words. The attacker registers a domain (ATT&CK T1583.001 Acquire Infrastructure: Domains), configures mail, and often publishes SPF, DKIM and DMARC so the message authenticates cleanly. Common variant types:

Failure modes.

• Assuming DMARC covers it: leadership hears "we are at p=reject" and stops funding anything else.
• Defensive registration as the whole strategy: you cannot register every permutation across every top-level domain, and combo domains are effectively unlimited.
• Monitoring without action: a feed of newly registered lookalikes that nobody triages or blocks.
• Partner and supplier lookalikes ignored: attackers impersonate your suppliers to you as often as they impersonate you to customers.
• Takedown as the only response: takedown takes days or weeks; inbound blocking should happen within hours of detection.

Controls. Inbound impersonation detection for your own and key partners' domains; blocking of newly observed lookalikes at the gateway; monitoring of new registrations and Certificate Transparency logs; defensive registration of the highest-risk variants; registrar and hosting abuse reports; formal dispute processes where needed; external sender and first contact warnings; and payment verification. The Domain Portfolio and Lookalike Domain Management Guide covers defensive registration strategy.

Which controls stop which attack

The last column matters because a genuine but compromised supplier mailbox defeats every authentication and lookalike control. Only process controls and anomaly detection on the request itself work there. See the Email Identity and BEC Guide.

Platform settings for inbound protection

Platforms are listed alphabetically. Both describe controls for spoofing of your domain, lookalike domains and impersonated people; these are customer-side settings that need to be switched on and given an action.

Google Workspace. The Gmail advanced phishing and malware protection settings under Apps, Google Workspace, Gmail, Safety include "Protect against domain spoofing based on similar domain names", "Protect against spoofing of employee names", "Protect against inbound emails spoofing your domain", "Protect against any unauthenticated emails" and "Protect Groups from inbound emails spoofing your domain". Each offers keep in inbox with a warning (the documented default), move to spam, or quarantine. Unauthenticated messages show a question mark beside the sender name.

Microsoft 365. Anti-phishing policies include spoof intelligence, "Honor DMARC record policy when the message is detected as spoof" and the first contact safety tip for all cloud mailboxes. Defender for Office 365 policies add "Enable domains to protect" (up to 50 custom domains per policy, checked for lookalikes including different top-level domains and homoglyphs), "Enable users to protect" (up to 350 users per policy) and mailbox intelligence. The documented default action for impersonation detections is "Don't apply any action", so choose a quarantine or junk action explicitly. Microsoft notes that a domain can be treated as impersonation even when it is registered and has valid authentication records.

Availability: Google lists these protections under its advanced phishing and malware settings; Microsoft lists impersonation protection and mailbox intelligence as Defender for Office 365 features, with spoof intelligence, DMARC honouring and first contact tips available to all cloud mailboxes. Confirm against your edition.

BEC scenarios

Scenario 1: spoofed chief executive to finance. A message claiming to be from the chief executive at your real domain asks for an urgent transfer. With DMARC at p=reject and inbound DMARC enforcement, the message is rejected. If the attacker instead uses a free webmail account with the chief executive's name as display name, DMARC is irrelevant; display name impersonation detection, an external sender tag and the payment approval rule are what stop it.

Scenario 2: supplier lookalike asking for new bank details. The attacker registers a domain one character away from a real supplier, copies an earlier invoice thread and sends "updated remittance details". The domain passes SPF, DKIM and DMARC. Controls that work: supplier domains added to domain impersonation protection, a first contact warning because finance has never received mail from that domain, and a callback to a number already on file before any bank detail change. See the Payment Fraud Guide.

Scenario 3: your brand used against your customers. A combo domain such as example-billing.com sends invoices to your customers. Your gateway never sees the messages. Controls: registration and certificate monitoring for your brand keywords, rapid abuse reports to the registrar and hosting provider, a dispute filing where the domain persists, and customer communications on how you will and will not ask for payment. The Brand Impersonation and Lookalike Domain Takedown Playbook covers the response steps.

Detection signals

Certificate Transparency is specified in RFC 9162 (Experimental, obsoleting RFC 6962): public, append-only logs of issued TLS certificates that anyone can monitor. See the Certificate Transparency Monitoring Guide for Web Teams.

Takedown and dispute

For a lookalike in active abuse, the fastest route is usually an abuse report to the registrar and hosting provider with evidence (headers, screenshots, the impersonated mark). Where a domain is registered in bad faith but not yet clearly abusive, WIPO's Uniform Domain-Name Dispute-Resolution Policy (UDRP) applies to all generic top-level domains and to country code domains that have adopted it or a variant. The complainant must show rights in the trademark, that the registrant has no rights in the domain, and that it was registered and used in bad faith. Treat dispute processes as cleanup, not as an incident response control.

Where identity fits

Both attacks are identity impersonation: the attacker borrows the identity of a person, a supplier or your organisation. The defences that hold up are the ones that verify identity through a second channel rather than trusting the From line. Automated senders matter too: invoicing systems, ticketing tools and marketing platforms send as your domain, and each one is a non-human sender that needs its own authorised SPF include or DKIM key, an owner and a review date. Unowned senders are why many organisations stall at p=none. The Email Identity and BEC Guide covers the identity side in depth.

Building a layered control plan

1. Inventory domains and senders: every owned domain, every system that sends as each one, and an owner for each sender.
2. Close exact-domain spoofing: move sending domains from p=none to p=quarantine to p=reject as reports show legitimate sources aligned; lock down non-sending domains at once. Roll back one step if legitimate mail fails, fix the source, then move forward.
3. Turn on inbound protection: enforce DMARC for inbound mail, enable domain and user impersonation detection for your domains, key suppliers and executives, start with a junk or warning action for two weeks, review false positives, then quarantine.
4. Add warnings: external sender tagging and first contact tips, tuned so they are not ignored.
5. Start lookalike monitoring: registration and certificate monitoring for your brand and top suppliers, with a named triage owner and a block-at-gateway step within one working day.
6. Register defensively where it pays: the most likely typos and the country code domains of your main markets, not every permutation.
7. Set up takedown: registrar contacts, an evidence template and a decision rule for when to file a dispute.
8. Harden the payment process: callback to a known number for any bank detail change, dual approval above a threshold, no exceptions for urgency. See the Business Email Compromise Awareness for Finance Teams Guide.

Detection and measurement

• DMARC enforcement coverage: percentage of owned domains (sending and non-sending) at p=reject.
• Aligned legitimate volume: share of your own outbound mail passing aligned DMARC, which should approach all of it before enforcement.
• Lookalike time to block: hours from detection of a new lookalike to blocking at your gateway.
• Takedown time: days from report to domain suspension or transfer.
• Impersonation detections and false positive rate per month, by protected user and domain.
• Payment verification compliance: share of bank detail changes with a recorded callback.

Framework mapping

Common failure patterns

• Treating DMARC p=reject as BEC protection: it removes one technique and leaves lookalikes, display names and compromised suppliers untouched.
• Protecting only your own name: supplier and partner domains are not in impersonation protection, so supplier lookalikes reach finance unchallenged.
• Leaving impersonation actions at their defaults: detection is on but the message is delivered without action.
• Warning fatigue: every external message carries the same banner, and staff stop reading it.
• Monitoring feeds with no owner: lookalikes are detected, logged and used a week later.
• Urgency exceptions in payment approval: the callback rule is waived for "the chief executive", which is the exact pretext attackers use.

Practitioner checklist

• Inventory all owned domains and every system that sends as them, with owners.
• Reach DMARC p=reject on sending domains and lock down non-sending domains with a null SPF record and p=reject.
• Confirm your platform honours DMARC for inbound mail and remove bypass rules for your own domains.
• Enable domain and user impersonation detection for your domains, key suppliers and executives, with an explicit action.
• Turn on external sender and first contact warnings and review their wording.
• Monitor registrations and Certificate Transparency logs for your brand and top suppliers, with a named triage owner.
• Block newly detected lookalikes at the gateway within one working day.
• Keep a takedown kit: registrar contacts, evidence template and dispute decision rule.
• Enforce callback verification and dual approval for bank detail changes, without urgency exceptions.

Standards and references

• IETF: RFC 9989, Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• IETF: RFC 9162, Certificate Transparency Version 2.0
• NCSC: Email security and anti-spoofing
• FBI IC3: Business Email Compromise, The $55 Billion Scam
• WIPO: Domain Name Dispute Resolution (UDRP)
• Google Workspace Admin Help: Advanced phishing and malware protection
• Microsoft Learn: Anti-phishing policies in Microsoft 365
• MITRE ATT&CK: T1583.001 Acquire Infrastructure: Domains

Related NHI Mgmt Group resources: Display Name and Exact Domain Spoofing Guide, DMARC, SPF and DKIM Guide, Typosquatting and Lookalike Domains Guide, Top 10 Email Security Threats.