DMARC Reject: What It Does, What Breaks, and How to Get There
Someone spoofs your CEO's email address, sends a phishing link to your biggest client, and the message lands in their inbox - sent from your domain. You find out when the client's IT team calls, furious. This happens every day, because 84% of domains used in email "From" addresses don't have a DMARC record at all. Among domains that do have valid records, 68% sit on p=none - monitoring spoofing but doing absolutely nothing to stop it.
The fix is p=reject. Getting there without breaking legitimate email is the hard part.
The Short Version
- p=reject is the only DMARC policy that actually stops spoofed mail.
p=nonemonitors.p=quarantinesuggests spam-foldering. Neither prevents delivery. - Don't flip the switch overnight. A staged rollout -
p=nonetop=quarantinetop=reject, ramped withpct=- takes 8-12 weeks done right. - You're ready when unauthenticated traffic stays below 1% for 30 consecutive days.
Three fears come up every time: Will I break legitimate email? Probably some - forwarding and mailing lists are the usual casualties. How do I know when I'm ready? Your aggregate reports tell you. What do Gmail and Microsoft actually do? They reject at SMTP. Exact error codes below.
Understanding DMARC Policy Levels
DMARC - Domain-based Message Authentication, Reporting, and Conformance - is defined in [RFC 7489](https://datatracker.ietf.org/doc/html/rfc7489). You publish a DNS TXT record telling receiving mail servers how to handle messages that fail SPF and DKIM alignment checks for your domain. The three policy levels:
p=none- Do nothing. Just send reports. Purely observational - you get visibility into who sends on behalf of your domain without affecting delivery.p=quarantine- Treat failures as suspicious. Usually means the spam folder, though interpretation varies by provider.p=reject- Refuse the message at SMTP. Don't deliver it at all. This is the only level that prevents spoofed mail from reaching recipients.
Here's what a reject record looks like:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; fo=1
One nuance most guides skip: DMARC is advisory. You're publishing a preference, not issuing a command. Receivers decide whether to honor it. Gmail, for instance, may override a reject policy for forwarded mail using ARC signals. In practice, major providers honor reject policies for direct mail - but the spec doesn't mandate it.
The adoption numbers are bleak. Only about 8% of domains have a valid DMARC record. Separately, 7.64% of published records are invalid, with roughly 94% of those errors caused by missing or incorrect v=DMARC1 tags. By the math, about 2.6% of domains have a valid DMARC record and an enforcement policy. The rest are unprotected, monitoring-only, or misconfigured.
Why Enforcement Matters in 2026
The mailbox providers forced the issue.
February 2024: Google and Yahoo begin enforcing authentication for bulk senders (5,000+ messages/day). SPF, DKIM, and a DMARC record become mandatory - though the minimum is p=none.
April 2024: Google escalates from temporary errors to outright rejections for non-compliant bulk traffic.
May 2025: Microsoft shifts from routing non-compliant high-volume mail to Junk to rejecting it at SMTP entirely. Same 5,000/day threshold, covering Outlook.com, Hotmail, and Live.
Google's spam complaint rate guidance adds another layer: keep complaints below 0.10% in Postmaster Tools, and never hit 0.30%.
Beyond deliverability, compliance frameworks are catching up. Organizations subject to HIPAA, PCI-DSS, or GDPR increasingly treat a reject enforcement policy as a baseline security control - not a nice-to-have.
Look, p=none technically meets the minimum requirement today, but it does nothing to protect your domain from impersonation. The biggest risk isn't moving to enforcement too fast - it's never getting there. Every week you stay on p=none, anyone can send email as you.
How Providers Handle p=reject
When a receiving server gets a message that fails DMARC and your policy says p=reject, here's what comes back:
| Provider | SMTP Error Code | Meaning |
|---|---|---|
| Gmail | 550 5.7.26 | DMARC authentication failed |
| Gmail | 550 5.7.25 | PTR/rDNS mismatch |
| Gmail | 550 5.7.29 | TLS requirement failure |
| Microsoft | 550 5.7.15 | Access denied - does not meet required authentication level |
Gmail's 550 5.7.26 is the one you'll see most often - the direct DMARC failure code. Microsoft's 550 5.7.15 is broader, covering authentication failures generally. Threads on r/sysadmin are full of admins troubleshooting this code after Microsoft's May 2025 enforcement kicked in.
One operational detail worth knowing: not all receivers implement reject the same way. Some refuse the message at SMTP time (the intended behavior), while others accept it and silently drop it. The difference matters - SMTP-time refusal generates a bounce notification to the sending server, while accept-then-drop creates a silent failure. You'll see both in the wild.
You're locking down your domain with p=reject so spoofed mail can't reach inboxes. But enforcement only works if the emails you send pass authentication. Prospeo's 98% email accuracy comes from proprietary 5-step verification - including catch-all handling, spam-trap removal, and honeypot filtering - so your outbound never triggers the DMARC failures you just spent weeks eliminating.
Don't let bad data undo your DMARC enforcement work.
What Breaks When You Move to Reject
Email Forwarding
Forwarding is the most common casualty. When someone forwards your email through their server, SPF fails - the forwarder's IP isn't in your SPF record. DKIM usually survives, unless the forwarder modifies headers or content.
Since DMARC requires either SPF or DKIM to pass and align, strong DKIM provides resilience. But when both break, your message gets rejected. SRS (Sender Rewriting Scheme) and ARC help, though ARC receiver adoption remains inconsistent.
Mailing Lists
Lists modify messages - footers, subject tags, header rewrites. That breaks DKIM. SPF fails because the list server sends from its own IP. With a reject policy, the message gets dropped.
The consensus on r/EmailSecurity mirrors what we've seen: ARC was supposed to fix this, but real-world adoption stays patchy. Subscribe to lists with a personal address, or confirm the list operator supports ARC before you enforce reject.
Third-Party Senders
Every SaaS platform that sends email on your behalf - Salesforce, Marketo, Mailchimp, HubSpot - is a potential alignment failure. These platforms pass SPF for their domain, not yours. Unless you've configured DKIM signing with your domain's keys and ensured alignment, DMARC fails.
In our experience, the third-party sender audit is where 80% of rollouts stall. The SPF 10-DNS-lookup limit makes it worse - each include: directive consumes lookups, and a company using five or six platforms can easily exceed the limit, causing a permerror that fails DMARC entirely. We've seen companies with 14 includes in a single SPF record, blissfully unaware that everything past the tenth was being ignored.
How to Roll Out DMARC Reject Safely
This isn't just a DNS change. Treat it as a cross-functional project involving IT, marketing, and sales ops. Someone needs to own the rollout, and every team that sends email needs to be in the loop.
Inventory Your Sending Sources
A typical 50-200 person company has 8-15 distinct sending sources. Most companies undercount by 30-50%. Catalog your mailbox provider, marketing automation, transactional email service, CRM, support/ticketing, HR/recruiting, monitoring/alerting, and ERP/finance platforms. Miss one, and you'll find out when that system's emails start bouncing.
While you're auditing, check for duplicate DMARC records - having more than one for the same domain terminates policy discovery per RFC 7489. About 5% of invalid DMARC records are caused by this exact mistake.
Start with p=none and Read Reports
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; fo=1; ri=86400
Publishing the record and ignoring the rua data is like installing a security camera and never checking the footage. Use a DMARC report reader or dmarcian to parse the XML. You're looking for legitimate senders that fail authentication - those are the ones you need to fix before tightening policy. Make sure all DKIM keys are 2048-bit. If you need to validate your signing setup, follow a quick checklist to verify DKIM is working.
Ramp Through Quarantine with pct=
Don't jump straight to full enforcement. The pct= tag applies the policy to a percentage of failing messages:
| Weeks | Policy | pct= |
|---|---|---|
| 1-2 | quarantine | 10 |
| 3-4 | quarantine | 25 |
| 5-6 | quarantine | 50 |
| 7-8 | quarantine | 100 |
| 9-10 | reject | 25 |
| 11-12 | reject | 100 |
At each stage, check your aggregate reports. If unauthenticated traffic spikes, pause and fix the source before ramping further. This gradual approach prevents the sudden breakage that gives enforcement policies a bad reputation.
When You're Ready
The readiness threshold: less than 1% unauthenticated traffic, sustained for 30 consecutive days. That's not a formal standard - it's an operational heuristic that works well in practice.
Two quick wins while you're ramping. First, harden parked and unused domains immediately with p=reject, plus v=spf1 -all and a null MX record to eliminate any sending capability. Attackers love spoofing domains you've forgotten about. Second, use the sp= tag to set subdomain policy independently - your marketing subdomain might need a different timeline than your primary domain.
DMARC Reject and Outbound Email
Here's where authentication and data quality intersect. You can have perfect DMARC, SPF, and DKIM - every message authenticated, every record aligned - and still destroy your sending reputation by emailing invalid addresses.
We've seen SDR teams running cold email campaigns with 15% bounce rates. Every bounce signals to mailbox providers that you aren't maintaining your lists, triggering the same reputation damage DMARC is designed to prevent. Authentication tells Gmail your email is really from you. Clean data tells Gmail you're a responsible sender. Prospeo's 5-step email verification catches bad addresses before they hit your sending infrastructure - 98% accuracy, catch-all handling, spam-trap removal - so your authenticated mail actually reaches real inboxes. If you're troubleshooting bounces, start with bounce rates and then work backward into list hygiene and sending practices.
Third-party sender audits stall 80% of DMARC reject rollouts. Bounce rates from unverified contact data make it worse - every hard bounce damages the sender reputation you're trying to protect. Prospeo delivers verified emails refreshed every 7 days, not the 6-week-old data that spikes bounces and flags your domain. At $0.01 per email, clean data costs less than one deliverability crisis.
Protect the domain reputation you fought to build. Start with clean data.
DMARCbis Changes Coming in 2026
The DMARC spec is getting an overhaul. DMARCbis - the successor to RFC 7489 - had its main docs submitted for publication in April 2025, with the failure reporting doc submitted in November 2025. It's expected to land as a Proposed Standard in early 2026.
Key changes:
pct=tag removed entirely. Replaced by a binaryt=testing flag. Operational experience showedpct=was rarely used at anything except 0 or 100. If you're mid-rollout usingpct=, finish before the spec change takes effect.- New
np=tag for non-existent subdomain policy, andpsd=tag for public suffix domain policy. - DNS Tree Walk replaces the Public Suffix List for determining organizational domains.
- DMARCbis discourages p=reject when mailing list usage is likely - acknowledging that the forwarding/list problem remains unsolved.
Let's be honest: the forwarding and mailing list problems aren't going away. DMARCbis acknowledges them without solving them. But the direction is clear - stricter authentication, simpler policy flags, and continued pressure toward enforcement.
If you're also trying to protect performance on the sending side, pair enforcement with an email deliverability guide and a plan to improve sender reputation as you ramp.
FAQ
Does p=reject guarantee spoofed mail is blocked?
No. DMARC is advisory - receivers decide enforcement. Gmail may override p=reject for forwarded mail using ARC. For direct spoofed mail, major providers honor reject consistently, but the spec doesn't mandate it.
What's the difference between quarantine and reject?
Quarantine suggests spam-foldering; reject refuses the message at SMTP - it never reaches any folder. Quarantine is inconsistently interpreted across providers, while reject is definitive. Use quarantine as a stepping stone, but only reject actually stops spoofed mail.
Can I go straight from p=none to p=reject?
Technically yes, but you'll almost certainly break legitimate email. The safe path is staged: none to quarantine to reject, ramped with pct= over 8-12 weeks. Skip the ramp only for parked domains with no legitimate sending.
Will p=reject break mailing list subscriptions?
Often yes. Lists modify messages, breaking DKIM, and SPF fails because the list server sends from its own IP. Use a personal address for list subscriptions, or confirm the list operator supports ARC before enforcing reject on your primary domain.
How does DMARC reject affect cold email deliverability?
It protects your domain from spoofing, which strengthens sender reputation over time. But authentication alone isn't enough - sending to invalid addresses still damages your sender score. Pair a reject policy with real-time email verification to keep bounce rates under control so your authenticated mail actually lands.