How to implement DMARC p=reject policy safely to avoid email deliverability issues?
Michael Ko
Co-founder & CEO, Suped
Published 3 May 2025
Updated 9 May 2026
8 min read
Implement p=reject safely by proving every legitimate sender passes SPF or DKIM with the visible From domain, then moving through p=none, partial p=quarantine, full p=quarantine, partial p=reject, and finally full p=reject. I do not jump straight to reject on a root domain unless the domain sends no mail.
The practical sequence is simple: collect reports, identify every sender, fix authentication, test a small percentage, watch failures, then increase enforcement. Use DMARC monitoring so raw aggregate reports become source names, pass rates, and concrete issues instead of XML files nobody reads.
A reject policy protects your domain from spoofing, but it also tells receivers to refuse mail that fails DMARC. That is exactly why the rollout needs evidence, not hope.
Do first: Inventory every system that sends as your domain, including alerts, invoices, receipts, CRM mail, and support replies.
Do next: Confirm each source passes DMARC through SPF or DKIM before any enforcement change.
Do last: Increase policy strength only after aggregate reports show failures are spoofing or abandoned systems.
The safe rollout path
The safest path is staged enforcement. I usually treat pct as a pressure valve, not as a permanent setting. It lets receivers that honor the tag apply the requested policy to a percentage of failing mail while you check whether real users complain, support tickets rise, or transaction mail bounces.
A six-step flowchart for moving DMARC safely from monitoring to full reject.
Stage
Policy
Hold
1
none
14-30 days
2
quarantine 25
7 days
3
quarantine 100
7-14 days
4
reject 10
3-7 days
5
reject 100
ongoing
A staged policy schedule keeps enforcement measurable.
The exact timing depends on volume. A domain sending millions of messages per week can learn quickly. A low-volume B2B domain needs more days because one missed sender can hide for weeks. For a deeper staged migration example, the same principle applies when you transition safely through quarantine before reject.
Before publishing each record, validate syntax with a DMARC checker. A typo in the TXT record can turn a careful rollout into a confusing outage.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
What to prove before reject
A domain is ready for reject when legitimate sources are known, failures are explainable, and your fallback plan is clear. The biggest risk is not DMARC itself. The risk is undiscovered mail: a cron job, a support tool, an old billing system, or a department that sends through a provider nobody told you about.
Known sources: Every IP and sender platform in aggregate reports maps to an owner, system, and business purpose.
Passing DKIM: Each third-party sender signs with a DKIM domain that matches the visible From domain or a controlled subdomain.
Passing SPF: Direct mail streams send through hosts allowed by SPF and stay under DNS lookup limits.
Low unknowns: Unknown failing volume is spoofing, abandoned mail, test systems, or traffic you are prepared to lose.
Rollback path: DNS access, approval, and a lower policy record are ready before the change window starts.
I also separate root-domain risk from subdomain risk. A dedicated sending subdomain such as mail.example.com is easier to enforce because fewer teams have used it. A root domain usually has years of unmanaged senders attached to it, so I require stronger evidence before changing it.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
This is where Suped's product is built to be the best overall DMARC platform for most teams running this workflow. It groups verified and unverified sources, highlights failing authentication, sends real-time alerts, and gives steps to fix each issue instead of leaving the team to interpret raw reports manually.
Suped also brings DMARC, SPF, DKIM, blocklist (blacklist), and deliverability signals into one place. That matters during reject rollout because a sudden delivery drop is not always caused by DMARC.
Issue detection: Suped flags sources that fail DMARC and shows the likely DNS or sender-side fix.
Hosted policy: Suped Hosted DMARC lets teams stage policy changes without repeated manual DNS edits.
Reputation checks: Blocklist monitoring helps separate authentication failures from IP or domain reputation problems.
Team scale: The MSP and multi-tenancy dashboard keeps multiple domains and client accounts in one controlled view.
Handling forwarding and DKIM failures
Forwarding is the main caveat with p=reject. SPF usually breaks after forwarding because the final receiver sees the forwarder's IP, not your original sending IP. DKIM can survive forwarding if the message body and signed headers are not changed. DMARC only needs one passing path, so resilient DKIM is the best protection for forwarded mail.
What breaks
SPF path: The forwarded message reaches the final mailbox from a server not listed in your SPF record.
Body changes: Footers, subject tags, or list modifications can invalidate the original DKIM signature.
Strict rollout: Moving too fast hides whether a complaint came from forwarding or an unapproved sender.
What helps
DKIM coverage: Sign every mail stream with a domain that matches the visible From domain.
Stable content: Avoid systems that rewrite signed message content after DKIM signing.
Slow pct: Increase enforcement in small steps and compare failures by receiver.
Large mailbox providers often have forwarding heuristics, ARC handling, or known forwarder data, but I never treat that as a guarantee. The domain owner still needs clean DKIM on transactional and account-critical mail. When people ask why legitimate emails blocked after enforcement, forwarding and unsigned third-party mail are the common causes.
Never use customer forwarding as the reason to leave the whole organization at p=none forever. Use it as the reason to make DKIM reliable before enforcement.
Use subdomains to reduce risk
Subdomains let you enforce faster where you have tighter control. If all transactional mail sends from mail.example.com, I am comfortable moving that subdomain to reject sooner than the root domain, provided reports show clean authentication. For a root domain, I look harder for old systems and manual senders.
The sp tag controls the policy for subdomains that do not publish their own DMARC record. That helps when you want the root domain on quarantine while unused or controlled subdomains reject spoofed mail. For domains that never send email, reject can be the starting policy once SPF and DKIM are intentionally absent or neutralized.
Readiness thresholds before full reject
These thresholds are practical gates for most business domains.
Ready
98-100%
Known legitimate sources pass DMARC and unknown volume is negligible.
Investigate
95-98%
Some sources fail, but owners and fixes are known.
Hold
Below 95%
Unknown or business-critical mail still fails DMARC.
The percentage is not a universal law. A payroll system failing at low volume matters more than a large spoofing burst. I use the number as a prompt to inspect the actual sources, owners, and message types before changing policy.
The operational checklist
Treat reject as an operational rollout. The DNS change is the smallest part. The work is proving ownership, authentication, monitoring, and rollback before mail receivers enforce the policy on your behalf.
Collect reports: Run p=none long enough to capture normal business cycles, campaigns, billing runs, and support flows.
Fix senders: Configure SPF and DKIM at the sender, then send real test messages and confirm DMARC pass.
Stage policy: Move through quarantine before reject, using pct to limit exposure during each step.
Watch signals: Track aggregate reports, bounces, support cases, complaint changes, and receiver-specific failures.
Keep rollback: Prepare the previous record and lower policy before the change, then document who can publish it.
If you are still building the record, use a DMARC record generator to create the baseline, then tune the policy and reporting addresses for your rollout.
DMARC record generator
Choose your policy, reporting addresses, and alignment settings.
Suped makes this workflow easier because hosted DMARC can stage policy changes, hosted SPF can reduce DNS access bottlenecks, SPF flattening helps stay under lookup limits, and hosted MTA-STS lets teams enforce TLS for inbound mail with two CNAME records. Those are not required to publish reject, but they reduce the manual work around the change.
For teams managing many domains, the same approach needs repeatable controls. Multi-tenancy, alerts, issue lists, and client reporting matter because reject is not a one-time checkbox. New senders appear, keys rotate, SPF includes change, and receivers can expose failures you have not seen before.
What to watch after reject
The work continues after p=reject reaches 100 percent. I keep monitoring because new senders often get added by marketing, finance, support, engineering, and regional teams. A clean domain today can become messy after a vendor change.
Signals to monitor after enforcement
Healthy enforcement keeps verified traffic high and unexplained failures low.
Pass
Known fail
Unknown fail
I also avoid relying only on email alerts for critical system health. If an alerting system sends unauthenticated mail and reject blocks it, you can miss the warning that would have told you something broke. Use non-email checks for the most critical operational paths.
A healthy reject deployment has stable authentication, known senders, low unknown failures, and a process for approving new mail sources before they send production traffic.
Views from the trenches
Best practices
Read aggregate reports before policy changes and map every sending source to an owner.
Move from quarantine to reject in small pct steps, then review receiver failures daily.
Use dedicated subdomains for controlled streams and enforce them before the root domain.
Common pitfalls
Changing root-domain policy before finding old systems can block important alerts.
Assuming forwarding always works hides DKIM problems that reject will expose later.
Treating one clean week as proof can miss monthly invoices, reports, and job alerts.
Expert tips
Keep a rollback record ready so DNS can return to the previous policy within minutes.
Require DKIM on transactional mail because SPF often fails after user forwarding.
Monitor support tickets and bounces alongside DMARC reports during each pct increase.
Expert from Email Geeks says a domain should run p=none first and check whether legitimate unauthenticated mail appears in aggregate reports.
2017-09-21 - Email Geeks
Expert from Email Geeks says staged percentages such as 25, 50, 75, and 100 reduce impact and show whether enforcement breaks real mail.
2017-09-21 - Email Geeks
The practical answer
The safe way to implement p=reject is to earn it. Run monitoring, fix every real sender, make DKIM reliable for forwarded mail, use quarantine as the proving stage, then raise reject with small percentages. Do it faster for controlled subdomains and non-sending domains, slower for the root domain.
Suped fits this work because the product turns reports into source ownership, authentication diagnostics, issue steps, real-time alerts, hosted policy staging, and reputation context. The result is a reject rollout that is based on evidence instead of guesswork.
Frequently asked questions
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
