Your DMARC policy is useless.

Right now, someone could send an email that looks exactly like it's from ceo@yourcompany.com. It would pass through spam filters. Land in your employee's inbox. Ask them to wire $50,000 to a "new vendor."

This isn't hypothetical. $2.77 billion was stolen through BEC attacks in 2024 alone. Google and Facebook lost $122 million to a single spoofed vendor. Toyota lost $37 million. Ubiquiti lost $46.7 million. In every case, the attack relied on domain impersonation that proper DMARC enforcement would have prevented.

These cases aren't outliers. They're the norm.

In 2024, Business Email Compromise (BEC) attacks cost organizations $2.77 billion in reported losses, according to the FBI's Internet Crime Report. Approximately 60% of these attacks involve domain impersonation—exactly the kind of spoofing that DMARC enforcement prevents.

Yet a February 2025 analysis of 73.1 million domains by Red Sift found that only 5.2% have p=reject—the only policy that actually stops spoofed emails. The rest?

Even among sophisticated organizations, the gaps are alarming. 88% of Fortune 500 companies have DMARC records—but only 73.6% actually enforce them. In financial services, the most-targeted industry, just 43% enforce their policies. Among SEC-regulated firms, only 24.4% have full enforcement.

And it's not just missing policies. Research shows 7.64% of DMARC records have syntax errors that break protection entirely. 60% of US government domains have SPF configuration errors. Having a DMARC record isn't the same as having protection—and most organizations don't know the difference.

The gap between "having DMARC" and "enforcing DMARC" has persisted for years because there was no penalty for inaction. That's changing.

PCI DSS 4.0, which took effect March 31, 2025, makes DMARC mandatory for anyone processing payment cards. Requirement 5.4.1 specifically mandates "automated mechanisms to detect and protect against phishing"—and non-compliance fines run $5,000 to $100,000 per month.

Google and Yahoo now require SPF, DKIM, and DMARC for bulk senders (5,000+ daily emails). Non-compliant emails already face temporary errors; starting November 2025, they'll be permanently rejected. This single requirement drove 500,000+ new DMARC records in early 2024 and reduced unauthenticated Gmail traffic by 65%.

Government agencies are even further ahead. CISA's BOD 18-01 requires all US federal agencies to implement p=reject. The UK, Australia, Canada, Denmark, and New Zealand have similar mandates. And the results are stark: in countries with mandatory DMARC, phishing success rates dropped from 69% to 14%. Meanwhile, the Netherlands—without mandates—saw vulnerability increase to 97%.

The market is moving. The question is whether you'll be ahead of the compliance deadline or scrambling to catch up.

In May 2024, the FBI, NSA, and State Department issued a joint advisory about North Korea's Kimsuky APT group. Their finding: Kimsuky systematically scans for domains with weak DMARC policies, then uses them to conduct spearphishing campaigns against US government officials, think tanks, academics, and journalists.

The attack is straightforward. They query DNS for your DMARC record. If it returns p=none, they know the domain owner won't request enforcement of authentication failures—increasing their chances of successful delivery. The advisory included actual email headers from these attacks:

The email failed every authentication check—SPF, DKIM, and DMARC—but was delivered anyway because the policy was set to p=none. The advisory explicitly states that upgrading to p=reject would have prevented these attacks entirely.

The US Treasury sanctioned Kimsuky in November 2023, but technical exploitation continues because organizations still haven't enforced their policies. Your p=none isn't just a configuration choice—it's an invitation.

Beyond the p=none problem, dozens of technical misconfigurations silently break email authentication—even for organizations that think they're protected.

SPF's 10-lookup limit is the most common killer. Every include: statement in your SPF record triggers a DNS lookup. Exceed 10, and SPF returns a PermError—authentication fails completely. Add enough third-party services (Google Workspace, Salesforce, HubSpot, Zendesk) and you'll hit it without realizing.

Subdomain gaps are equally dangerous. If you protect yourcompany.com but explicitly set sp=none (missing sp= inherits from p=), attackers simply spoof hr.yourcompany.com or billing.yourcompany.com instead. The March 2022 SEC domain spoofing case demonstrated a related problem: attackers couldn't spoof sec.gov directly (it has p=reject), so they spoofed an unprotected government email delivery service domain instead—impersonating the SEC through the third-party intermediary.

Weak DKIM keys (1024-bit or less) are vulnerable to cryptographic attacks. ManageMyHealth was running 1024-bit keys when they were breached. The minimum should be 2048-bit—which AWS SES and most modern providers use by default.

And missing reporting tags mean you have no visibility into failures. Without rua= in your DMARC record, you'll never know how many authentication failures are happening—or whether legitimate emails are being blocked.