DMARC Says ‘Pass’, So Why Is Your Domain Still Getting Spoofed? The Enforcement Gap Explained

1. The Uncomfortable Truth

Your DMARC record is published. Your DNS has the right TXT entry at _dmarc.yourdomain.com. If someone checks your domain, it shows “DMARC: Present.” You might even have SPF and DKIM properly configured. Everything looks compliant.

But there's a problem: your DMARC record is doing absolutely nothing to protect your domain.

If your DMARC policy is set to p=none, you've published what amounts to a passive observer. Your DMARC record watches authentication failures happen, dutifully logs them in aggregate reports, and then steps aside to let every spoofed email through to the recipient's inbox.

It's the email security equivalent of a security camera with no guards. You can watch the burglary happen on tape, but nobody is stopping the burglar from walking in.

This is the DMARC enforcement gap, and it affects nearly half of all domains that have bothered to deploy DMARC. They did the work. They published the record. And then they stopped one step short of the configuration that actually provides protection.

2. The Numbers: A Global Enforcement Crisis

PowerDMARC's January 2026 Global DMARC Adoption Report provides the clearest picture yet of the enforcement gap. The findings are both encouraging and alarming in equal measure:

The adoption story is a success: nearly every major domain now has DMARC. This was driven in large part by Google, Yahoo, and Microsoft requiring at least p=none for bulk senders. The industry responded.

But adoption isn't enforcement. Of the domains with DMARC:

• 46% are at p=none: monitoring only, zero protection
• 15.6% are at p=quarantine: partial protection (failures go to spam)
• 33.4% are at p=reject: full protection (failures are blocked)
• About 5% have errors or unusual configurations

That means only about 1 in 3 domains with DMARC are fully protected against email spoofing. The other two-thirds are either partially protected or completely exposed, despite having a DMARC record that appears to show compliance.

Certain sectors are even worse. Healthcare organisations, educational institutions, and small-to-medium businesses consistently show lower enforcement rates, often below 25% at p=reject. These are precisely the organisations most frequently targeted by phishing campaigns.

3. What DMARC Policies Actually Mean

To understand the enforcement gap, you need to understand what each DMARC policy level actually does. Let's strip away the jargon and explain this plainly:

v=DMARC1; p=none; rua=mailto:[email protected];

v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected];

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s;

The key insight is simple: p=none is not a security policy. It's a monitoring tool. It exists so you can collect data before turning on enforcement. It was designed to be temporary, a stepping stone on the path to p=reject. But for millions of domains, it became the destination.

4. Why Everyone Gets Stuck at p=none

If p=reject is so clearly better, why do 46% of domains stay at p=none? The answer usually comes down to one of these reasons:

Fear of Breaking Legitimate Email

This is the number one reason, and it's a legitimate concern. If you move to p=reject while third-party services are still sending email on your behalf without proper SPF/DKIM alignment, those emails will be blocked. Marketing platforms, CRM systems, invoice generators, helpdesk tools: any service that sends email “from” your domain needs to be properly authenticated first.

The fear is rational. The response, staying at p=none indefinitely, is not.

Nobody Reads the Aggregate Reports

DMARC aggregate reports are XML files. They're not designed for human consumption. Many organisations publishp=none with a rua= tag, but never actually set up a system to parse and review the reports. Without the data, they can't confidently move to enforcement, so they don't.

“It's on the Roadmap”

DMARC enforcement gets deprioritised. It doesn't generate revenue. It doesn't have a visible impact (until it does, in the form of a phishing attack). It sits on the backlog behind feature releases, infrastructure upgrades, and a hundred other competing priorities.

Compliance Checkbox Syndrome

Google, Yahoo, and Microsoft require DMARC for bulk senders, but they only require p=none. Many organisations deployed DMARC specifically to meet this requirement, checked the box, and moved on. They met the letter of the law but missed the spirit entirely.

Complex Email Ecosystem

Large organisations often have dozens of services sending email: marketing automation, transactional email, customer support, HR systems, finance platforms, partner integrations. Each needs its own SPF/DKIM configuration. The complexity is real, and it makes enforcement feel risky.

5. The Real Cost of p=none

The risks of staying at p=none are no longer theoretical. Microsoft's January 2026 advisory described exactly how attackers are exploiting this gap to send phishing emails that appear to come from inside Office 365 tenants.

Here's what p=none actually costs your organisation:

• Brand damage: When attackers send phishing emails from your domain, recipients lose trust in your brand, even though you weren't compromised
• Financial fraud: Business email compromise (BEC) attacks using spoofed domains cost organisations an average of $125,000 per incident (FBI IC3 2025 report)
• Regulatory risk: Industries with data protection regulations (GDPR, HIPAA, PCI-DSS) may face scrutiny for failing to implement available email security controls
• Deliverability impact: If attackers send enough spoofed email from your domain, your domain reputation degrades, affecting your legitimate email deliverability
• Supply chain attacks: Attackers spoof your domain to target your partners, vendors, and customers, extending the blast radius beyond your organisation

6. Reading DMARC Aggregate Reports

Before you can enforce DMARC, you need to understand what your aggregate reports are telling you. These reports are the key to moving from p=none to enforcement with confidence.

What You Receive

Every receiving server that processes email from your domain sends a daily aggregate report (if you have arua= tag). These arrive as gzipped XML files. Here's an annotated example of what's inside:

<!-- Report metadata -->
<report_metadata>
  <org_name>google.com</org_name>          <!-- Who generated this report -->
  <date_range>
    <begin>1706832000</begin>              <!-- 24-hour reporting period -->
    <end>1706918400</end>
  </date_range>
</report_metadata>

<!-- Your published DMARC policy -->
<policy_published>
  <domain>yourdomain.com</domain>
  <p>none</p>                              <!-- Your current policy -->
  <pct>100</pct>
</policy_published>

<!-- Individual sending source record -->
<record>
  <row>
    <source_ip>198.51.100.1</source_ip>    <!-- IP that sent the email -->
    <count>1453</count>                     <!-- Number of emails from this IP -->
    <policy_evaluated>
      <disposition>none</disposition>       <!-- What action was taken -->
      <dkim>pass</dkim>                    <!-- DKIM result -->
      <spf>pass</spf>                      <!-- SPF result -->
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>yourdomain.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>yourdomain.com</domain>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>yourdomain.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

What to Look For

When reviewing reports, focus on these key elements:

• Source IPs: Identify every IP sending email from your domain. Cross-reference with your known email providers. Unknown IPs are either misconfigured services or spoofing attempts.
• SPF/DKIM results: Look for legitimate services that are failing authentication. These need to be fixed before enforcement.
• Alignment results: Even if SPF and DKIM pass individually, DMARC requires alignment. The authenticated domain must match the From: header domain.
• Volume: High-volume sources that fail authentication are your priority. A service sending 10,000 emails/day with failing DKIM will break at enforcement.

7. The Enforcement Roadmap

Here's the detailed, week-by-week plan for moving from p=none to p=reject. This roadmap is designed to be safe, gradual, and reversible at every stage.

8. Week 1-2: Audit Mode

If you've been at p=none for a while, you may already have weeks or months of aggregate report data. If not, start collecting it now:

v=DMARC1; p=none; rua=mailto:[email protected];

What to Do During Audit

1. Catalogue all sending sources. Review aggregate reports and list every IP address/service that sends email using your domain. Common legitimate sources include:
   • Your email provider (Google Workspace, Microsoft 365)
   • Marketing platforms (Mailchimp, HubSpot, SendGrid)
   • Transactional email (Postmark, Amazon SES)
   • CRM systems (Salesforce, Zoho)
   • Support ticketing (Zendesk, Freshdesk)
   • Billing/invoicing platforms
2. Identify authentication failures. Any legitimate service showing SPF or DKIM failure needs to be fixed. This typically means:
   • Adding the service to your SPF record
   • Configuring DKIM signing for the service
   • Ensuring the service sends with proper alignment
3. Flag unknown sources. Any sending IP you can't identify is either a misconfigured service you forgot about (ask around your organisation) or a spoofing attempt. If it's a spoofing attempt, enforcement is exactly what will stop it.
4. Set your milestone. Before moving to enforcement, you should see a DMARC pass rate of 95%+ for legitimate email in your aggregate reports. Fix the remaining failures before proceeding.

9. Week 3-4: Quarantine with pct=10

Once your audit is complete and legitimate senders are properly authenticated, it's time for your first enforcement step. This is intentionally conservative:

v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected];

This tells receiving servers: “Apply quarantine to 10% of emails that fail DMARC. Deliver the other 90% normally.”

What to Monitor

• Support tickets about missing email. If users or customers report emails going to spam, investigate immediately
• Aggregate reports. Watch for legitimate services now showing disposition=quarantine
• Sending service dashboards. Check bounce rates and delivery metrics in your email platforms

When to Roll Back

If you see legitimate email being quarantined, don't panic. You have two options:

• Fix the authentication issue (preferred): add the service to SPF, configure DKIM, or fix alignment
• Roll back to p=none temporarily while you fix it. This is safe and expected during the transition

Ramp Up Schedule

If pct=10 runs smoothly for a week with no issues, increase to pct=25, then pct=50:

# Week 3: Start conservative
v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected];

# Week 4 (if no issues): Increase
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected];

# End of Week 4: Ramp further
v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected];

10. Month 2: Ramp to pct=100 Quarantine

By month 2, you should have enough confidence to enforce quarantine on all failing email:

v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected];

At this stage, every email that fails DMARC goes to spam. This is a significant milestone: you now have active spoofing protection. Most phishing emails using your domain will land in junk folders instead of inboxes.

What to Do During This Phase

• Run for at least 2-3 weeks at pct=100 quarantine before moving to reject
• Monitor aggregate reports carefully. At this point, any legitimate service that's failing should have been caught, but edge cases can emerge (monthly newsletters, quarterly reports, etc.)
• Confirm your pass rate. Your DMARC pass rate for legitimate email should be 99%+ before moving to reject
• Communicate internally. Let your IT team, marketing department, and key stakeholders know that DMARC rejection is coming, and ask them to report any email delivery issues immediately

11. Month 3: Move to p=reject, The Finish Line

This is the moment everything has been building toward. Moving to p=reject tells every receiving server on the internet: “If someone sends an email claiming to be from my domain and it fails authentication, block it. Don't deliver it. Don't put it in spam. Reject it entirely.”

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s;

The adkim=s and aspf=s flags enforce strict alignment, meaning the DKIM signing domain and SPF envelope sender must exactly match the From: header domain (not just be a subdomain). This provides the strongest possible protection.

Post-Deployment Checklist

• ☐ Continue monitoring aggregate reports for at least 30 days after moving to reject
• ☐ Watch for legitimate email rejections. They'll show as bounces in your sending platforms
• ☐ Keep your rua= tag; aggregate reports are still valuable for ongoing monitoring
• ☐ Consider adding a ruf= tag for forensic (failure) reports on individual messages
• ☐ Update your security documentation and compliance records
• ☐ Celebrate! You've just closed one of the biggest gaps in email security 🎉

12. Common Pitfalls

Even with a careful rollout, certain scenarios can trip up DMARC enforcement. Here are the most common pitfalls and how to handle them:

Third-Party Senders Without DKIM

Some SaaS platforms send email “from” your domain but don't support custom DKIM signing. Without DKIM, these emails rely on SPF alignment alone, and if the platform sends from their own infrastructure (not included in your SPF), the email fails DMARC.

Solution: Contact the vendor and ask them to support DKIM with your domain's signing key. Most modern platforms do. If they don't, consider having them send from a subdomain with its own DMARC policy, or switch to a vendor that supports proper authentication.

Email Forwarding

When a recipient forwards your email (e.g., auto-forwarding from a university address to Gmail), SPF breaks because the forwarding server's IP isn't in your SPF record. If DKIM isn't set up or the forwarding server modifies the message (breaking the DKIM signature), the email fails DMARC at the final destination.

Solution: This is largely mitigated by ARC (Authenticated Received Chain), which major providers now support. Google, Microsoft, and Yahoo all evaluate ARC chains to preserve authentication across forwards. Ensure your DKIM is properly configured. DKIM survives most forwards as long as the message body isn't modified.

Mailing Lists

Mailing lists (e.g., Google Groups, Mailman) often rewrite the From: header or modify the message body, breaking both SPF and DKIM alignment. This is a known challenge with DMARC enforcement.

Solution: Modern mailing list software rewrites the From: header to use the list's domain (e.g., via [email protected]) and preserves the original sender in theReply-To: header. This is the recommended approach and is now standard practice for most list providers.

Legacy On-Premise Systems

Older mail servers, multifunction printers, and legacy applications that send email may not support DKIM and may not be included in your SPF record.

Solution: Route these systems through a smart host or email relay that adds DKIM signatures. Microsoft 365 and Google Workspace both support SMTP relay configurations for this purpose. Alternatively, have these systems send from a subdomain with its own authentication records.

The “Just One More Service” Trap

Organisations often hesitate because there's always “one more service” they haven't checked. This becomes a perpetual excuse to stay at p=none.

Solution: Set a deadline. If you've been at p=none for more than 3 months, you have enough data. Move to p=quarantine with pct=10 and let the enforcement surface any remaining issues. Waiting for perfection means waiting forever.

13. Frequently Asked Questions