$2.77 billion. That’s what the FBI reported as losses due to Business Email Compromise in 2024 alone, according to the annual IC3 report. A fraction of these attacks succeeded even though the targeted organizations had DMARC in place. This is not a paradox: DMARC only protects against one specific form of spoofing, and the attackers know this. Understanding its exact limitations (those documented by RFC 7489 itself) is the condition to avoid overestimating its actual coverage.
What DMARC does (and nothing else)
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a protocol that relies on SPF and DKIM to give instructions to recipient mail servers: reject, quarantine, or deliver emails whose domain identity cannot be verified. With a p=reject policy, any message whose header From does not match an authorized SPF or DKIM source is blocked. This protection is real. But its perimeter strictly limits to exact domain spoofing. RFC 7489 states plainly: “DMARC does not address the use of visually similar domain names or the abuse of human-readable display names.” Five common attack vectors thus remain out of reach.
Display name spoofing completely evades it
An email with a header showing “Amazon Customer Service <phishing@n0treal.com>” passes DMARC without any issue. DMARC only verifies the technical domain of the sender, not the name displayed in the email client. The attacker retains a sender name identical to a trusted brand while using their own domain, properly authenticated. For the end user, the “From:” line displays exactly what the attacker decided to put there. This vector requires no compromised infrastructure and bypasses all DMARC checks by definition: the technical domain is not spoofed, it is simply unrelated to the displayed name.
Similar domains are not addressed
DMARC protects example.com. It says nothing about examp1e.com, example-support.com, or example.fr. These so-called “cousin” domains (typosquatting, lookalike domains) can publish their own valid DMARC record, with SPF and DKIM correctly configured, and send perfectly authenticated emails from a domain that looks indistinguishably similar to a legitimate organization’s domain. The issue is documented by PowerDMARC: these domains “frequently bypass the scope of DMARC” because the protocol has no control over what it does not manage. Monitoring registered cousin domains involves other categories of tools: brand monitoring, DNS watch, recently issued SSL certificate analysis.
A compromised account passes DMARC without alert
If an attacker gains access to a legitimate email account via credential stuffing, initial phishing, or data breach, all outgoing messages pass SPF, DKIM, and DMARC normally. The message comes from the correct domain, signed with the right DKIM key, from an authorized IP. DMARC does not distinguish between a legitimate employee and an attacker who has stolen their credentials. This is precisely the modus operandi of BEC (Business Email Compromise): the $2.77 billion in losses recorded by the FBI in 2024 involve attacks where the victims’ email infrastructure was often properly configured. DMARC saw nothing because there was technically nothing to see.
Email forwarding can break authentication
When a message goes through an intermediate service (company alias, mailing list like Mailman or Listserv, automatic forwarding), SPF almost systematically fails: the relay IP is not listed in the original domain’s SPF record. If the mailing list modifies the body of the message (footer added, disclaimer inserted), DKIM can also fail. Perfectly legitimate emails end up being rejected or quarantined. According to dmarcian, 21% of observed DMARC failures in aggregate reports are due to this DKIM breaking by content modification. The standard solution is ARC (Authenticated Received Chain), but it requires explicit configuration on the relay side. The majority of mailing lists have not yet implemented it.
Subdomains can remain blind spots
A DMARC record published on example.com does not automatically protect all its subdomains. By default, mail.example.com or newsletter.example.com inherits the parent domain’s policy unless a specific DMARC record exists for the subdomain, in which case the latter prevails, even if it’s set to p=none. A forgotten subdomain configured in monitoring voids the p=reject protection of the main domain for that scope. Valimail indicates that over 80% of domains do not have a stringent DMARC policy; among those that do, the coherence between the main domain and subdomains is rarely systematically verified. Unused “parking” domains also remain available spoofing surfaces.
DMARC in a realistic strategy
These five limitations do not make DMARC useless. In November 2025, Gmail began rejecting non-compliant bulk emails, and Valimail estimates that DMARC enforcement eliminated 265 billion unauthenticated messages in 2024. It’s a necessary foundation. But it’s only a foundation. Realistic coverage also requires: a solution capable of analyzing display names and detecting cousin domains, protection against account compromise (mandatory MFA, behavioral anomaly detection), ARC configuration for legitimate forwarding streams, and regular audits of subdomains, including those considered “inactive.” DMARC closes one door. Before considering the job done, you have to count the others.
