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.
The scale of the problem
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?
82%
No DMARC at all — completely unprotected
9.7%
p=none — monitoring only
3.1%
p=quarantine — partial protection
5.2%
p=reject — actual protection
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.
Regulators are finally forcing the issue
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.
See what happens when a spoofed email arrives
Theory is one thing. Watching it happen is another. Toggle between DMARC policies below and see exactly which emails get blocked, quarantined, or delivered straight to your inbox.
DMARC Policy Simulator
How email authentication actually works
SPF, DKIM, and DMARC are three separate protocols that work together—but each has limitations, and they only matter when you actually enforce the result. Here's how the chain works:
SPF (Sender Policy Framework)
Specifies which mail servers are authorized to send email for your domain.
v=spf1 include:_spf.google.com include:amazonses.com ~all
The problem: Only checks envelope sender (Return-Path), not the From: header users see. Breaks with forwarding.
Real-world email security incidents
These aren't hypothetical scenarios. Each involved BEC attacks where weak or missing DMARC enabled domain spoofing—and proper enforcement would have prevented them. Click each incident for details.
Click any incident to expand details
State-sponsored attackers actively hunt for p=none
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.
Check your domain right now
Enter any domain below and see what policy it's running. You might be surprised—many organizations think they have protection when they're actually running p=none or have no DMARC record at all.
Check Your Domain
Real-time DNS analysis powered by Wraps Email Tools.
The technical debt that breaks protection
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.
The path from p=none to p=reject
Moving to enforcement isn't instant—but it's not the months-long project people assume. The process is bounded: identify your legitimate email senders, verify they're properly authenticated, then ramp up enforcement. Most organizations can complete this in 2-4 weeks.
The Path to p=reject
1
Start with monitoring
v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com
Deploy p=none to receive reports without affecting delivery. See who's sending as your domain.
2
Fix legitimate senders
v=spf1 include:_spf.google.com include:amazonses.com -all
Add all legitimate services to SPF. Configure DKIM for each sender. This typically takes 2-4 weeks.
3
Move to quarantine
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourcompany.com
Start quarantining failures at 25%, then 50%, then 100%. Monitor for legitimate mail going to spam.
4
Enforce with reject
v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com; fo=1
Full protection. Spoofed emails are rejected before reaching any inbox. You're now in the 5.2%.
Tip: If you're using AWS SES, Wraps CLI automatically configures SPF, DKIM, and DMARC when you deploy your email infrastructure. Check your current setup with our free domain analyzer.
The ROI is clear. Average data breach costs hit $4.88 million in 2024. DMARC implementation costs as little as $8-50/month. Forrester estimates large enterprises save $2.4 million annually with proper enforcement. The ManageMyHealth case shows what happens when you don't act: a data breach becomes an ongoing phishing campaign against your own users.