Where DMARC breaks down: forwarding, cousin domains, display names

DMARC is effective, but it has real limitations worth understanding before treating p=reject as the end of email spoofing. Three gaps matter in practice: forwarded mail fails authentication through no fault of anyone, lookalike domains sit entirely outside DMARC's reach, and the display name a recipient actually reads is never validated at all. Each needs its own defense.

Forwarded mail

When mail is forwarded through an intermediary (mailing lists, university aliases, corporate forwarding rules), SPF breaks because the forwarding server's IP is not in the original sender's SPF record. If the forwarder also modifies the message's body or signed headers (adding a footer, for example), then DKIM breaks too. When both fail, DMARC fails, and a p=reject policy causes legitimate forwarded mail to be rejected.

ARC (Authenticated Received Chain) was designed to deal with this. ARC lets intermediate servers record the original authentication results so downstream receivers can evaluate those recorded results. ARC helps, but adoption is uneven, and not all receivers trust ARC results. Mailing lists mitigate separately by rewriting the From: header to their own domain, which preserves deliverability at the cost of the original sender identity.

Cousin domain spoofing

DMARC protects yourdomain.com, but it does nothing about yourdoma1n.com or yourdomain-support.com. Attackers who cannot spoof an exact domain will register lookalike domains instead, and each lookalike passes its own SPF, DKIM, and DMARC perfectly, because the attacker controls it. As exact-domain spoofing gets locked down across the industry, this is precisely where phishing has migrated.

DMARC has no mechanism for this. It is a different problem requiring different tools: defensive registration of the obvious variants, brand monitoring services that watch new domain registrations, takedown processes for active abuse, and BIMI as a positive signal that helps recipients recognize the genuine sender. None of that lives in your DMARC record, and a security review that stops at p=reject has covered only the exact-match half of the impersonation problem.

Display name spoofing

DMARC validates the From: header domain, not the display name. An attacker can send mail from attacker@evil.com with the display name set to "Jane Smith, CEO," and DMARC will not flag it, because the domain evil.com passes its own DMARC check. On mobile clients that show only the display name, this is all an attacker needs, and it is the cheapest impersonation technique available.

This is a social engineering attack that sits outside DMARC's scope. Defenses live elsewhere: receiver-side impersonation detection (many business filtering stacks flag display names matching internal executives), user training that treats display names as decoration, and organizational processes that never authorize payments or credentials over email alone.

What DMARC still is

None of these gaps argues against deployment. DMARC at enforcement removes the exact-domain spoofing vector entirely, which is the vector with your actual name on it, and the reporting loop delivers visibility nothing else provides. The honest framing: DMARC is a necessary layer with a well-defined scope, deployed via the staged rollout, and complemented by ARC awareness, lookalike monitoring, and anti-impersonation controls for everything outside that scope.