How do lookalike domains bypass DMARC?

When DMARC can and cannot help

DMARC helps when the attacker places a domain you own in the visible From address. A policy such as p=reject asks receiving systems to reject messages that fail DMARC for that protected domain. The receiver still makes the final delivery decision under its local policy, as RFC 9989's DMARC policy model describes.

DMARC does not help when the sender changes the visible From domain to an attacker-owned lookalike. The following decision rule keeps the distinction clear:

• If the malicious message uses billing@example.com, inspect DMARC enforcement and the message's authentication evidence for example.com.
• If the message uses billing@example-support.com, your example.com policy does not govern it. Preserve the evidence for reporting and use your organization's lookalike-domain response process.
• If the displayed sender name looks legitimate but the address differs, inspect the complete From address. Display names are not the domain DMARC evaluates.

Do not move a domain to a stricter DMARC policy based only on a public DNS result. Validate legitimate production mail paths before changing policy, because an unaligned sender can fail after enforcement.

A worked lookalike-domain example

Assume that example.com publishes a DMARC policy and an attacker registers example-support.com. These records are illustrative only. Do not copy them into DNS. Each domain owner publishes and controls records only for its own domain.

From: Billing Team <notice@example-support.com>
Authentication-Results: receiver.example;
  dkim=pass header.d=example-support.com;
  dmarc=pass header.from=example-support.com

The example message can pass DMARC because the DKIM signing domain and visible From domain are both example-support.com. The receiver does not test whether that domain resembles example.com, because visual similarity is not a DMARC alignment rule.

A similar header result for example.com would answer a different question: whether the message authenticated as example.com under that domain's DMARC policy. It would not establish why a recipient trusted a display name or whether a separate lookalike domain was malicious.

What to do with the evidence you have

If you only have a suspicious address, copy the full visible From domain and compare it with the domain your organization owns. Do not rely on the display name or a cropped screenshot.

If you have the original message, preserve the raw headers and inspect the receiver's Authentication-Results fields. Compare header.from with the passing SPF or DKIM identifier. This separates direct spoofing from authenticated mail sent through a lookalike domain.

If the message uses your real domain, check the published policy with the Palisade DMARC checker. Compare the DNS result with the real message header and with the sending systems your team has approved. A public DNS lookup confirms the current published record. It cannot prove that the suspicious message followed your production path, explain a receiver's private decision, or show every sender that may later fail alignment.

If the message uses a lookalike, preserve the domain, message headers, URLs, timestamps, and any recipient reports for your security team and the relevant abuse-reporting or takedown process. DMARC aggregate reports can help identify mail using your own domain, but they do not inventory every independently registered lookalike domain.

An unauthorized aggregate-report destination can also complicate DMARC reporting. See why DMARC says an rua or ruf domain is not authorized if the reporting address itself is the problem.

Check the DMARC policy on the real domain

When a suspicious message appears to use your exact domain, inspect the real domain's published DMARC record before deciding whether a policy gap exists. Then compare it with raw message headers from the affected path.

Start with Palisade

Palisade autonomously analyzes DMARC aggregate-report data, identifies sending sources and alignment issues, and proposes a next policy step for human review. It does not control an attacker-owned lookalike domain, perform a takedown, or guarantee that every future message will authenticate.