DMARC p=reject: Why 90% of Companies Get It Wrong

Your CEO's domain is being spoofed right now. Attackers are sending invoices, password resets, and wire transfer requests using your exact From address—and most receiving mail servers are happily delivering them.

DMARC with p=reject fixes this completely. At full enforcement, spoofed mail is bounced before it reaches the inbox. No delivery. No damage. Yet most organizations that have DMARC deployed are stuck at p=none—the monitoring-only policy that generates reports but blocks nothing.

The reason isn't laziness. It's that moving from p=none to p=reject is genuinely dangerous if you don't know what you're doing. Done wrong, it breaks marketing emails, kills transactional notifications, and silently drops legitimate business correspondence. Done right, it takes 8–12 weeks and requires a methodical process most guides skip over.

This is that guide.

---

What DMARC p=reject Actually Does

DMARC (Domain-based Message Authentication, Reporting & Conformance) is a DNS policy that tells receiving mail servers how to handle messages that fail authentication checks.

The three policy levels are:

Policy	What happens to failing mail	Use case
p=none	Delivered normally	Monitoring/discovery
p=quarantine	Sent to spam folder	Transition phase
p=reject	Bounced—never delivered	Full enforcement

When a mail server receives a message claiming to be from yourcompany.com, it checks:

1. SPF — Is the sending IP authorized to send for this domain?
2. DKIM — Does the cryptographic signature match and align with the From domain?
3. DMARC alignment — Does SPF or DKIM pass and align with the From header domain?

If neither SPF nor DKIM passes with alignment, the message fails DMARC. At p=reject, the receiving server bounces the message entirely—it never reaches the inbox, the spam folder, or anywhere else.

This is what stops spoofing. Not filtering, not scoring—a hard rejection at the infrastructure level.

The critical word is "alignment." A message from Mailchimp might pass SPF (Mailchimp's IPs are authorized for Mailchimp's infrastructure) but fail DMARC alignment because the SPF domain (mailchimp.com) doesn't match your From header domain (yourcompany.com). That aligned check is where most implementations fall apart.

---

The 10 Most Common DMARC p=reject Mistakes

1. Moving to p=reject Without Completing Sender Discovery

This is the most common—and most damaging—mistake. Organizations assume they know every system sending email as their domain. They're almost always wrong.

A typical 50–200 person company has 8–15 distinct sending sources: Google Workspace or Microsoft 365 for employee mail, a marketing platform, a transactional email service, a CRM, a support ticketing system, a monitoring tool that pages on-call engineers, HR software that sends offer letters, a legacy ERP that sends invoices. Miss any of them and you'll break real business email on the day you flip to p=reject.

Fix: Run p=none for a minimum of 4 weeks and analyze every aggregate report before touching policy.

2. Misreading Aggregate Reports

DMARC aggregate reports arrive as XML. They are not human-readable without tooling. Many teams glance at a pass percentage—say, 94%—and assume they're close enough to enforce.

The 6% failure rate might be entirely spoofing attempts (safe to reject) or it might be your invoice sending system that nobody knew about (catastrophic to reject). Aggregate reports don't tell you which—you need to identify every source IP and categorize it before moving forward.

Fix: Use a DMARC reporting platform (dmarcian, Valimail, or Postmark's free analyzer) that maps IP addresses to known services.

3. SPF Record Over the 10-Lookup Limit

SPF has a hard limit of 10 DNS lookups per evaluation. Many organizations unknowingly exceed this through accumulated include: directives added over years. When SPF exceeds the limit, the evaluation returns permerror, which fails DMARC the same as a hard SPF failure.

A typical overgrown SPF record looks like:

v=spf1 include:_spf.google.com include:sendgrid.net include:spf.protection.outlook.com include:spf.mailchimp.com include:mail.zendesk.com include:_spf.salesforce.com include:amazonses.com include:spf.hubspot.com -all

Count the lookups. Add recursive lookups for each include:. You're likely already over the limit.

Fix: Use SPF flattening (AutoSPF, dmarcian's SPF Optimizer) or restructure using subdomains. Test with dig TXT yourdomain.com and count recursively.

4. DKIM Not Configured on Third-Party Senders

SPF alone is insufficient for reliable DMARC alignment in complex sending environments. DKIM provides the stable alignment mechanism that survives email forwarding and services that route through shared infrastructure.

Many teams configure DMARC, enable SPF for their primary mail provider, and consider the job done. Every third-party sender—marketing platform, transactional email service, support tool—needs DKIM configured with your domain's signing key, not the provider's default signing.

Fix: For every sender in your inventory, verify DKIM is configured to sign with your domain. Most platforms have a "custom domain authentication" or "domain verification" section in settings.

5. Jumping Straight to p=reject Without Using p=quarantine as a Stepping Stone

p=quarantine is not a destination—it's a diagnostic tool. Before rejecting anything, quarantining lets you observe how enforcement affects real mail flow without permanently losing messages. Users and admins can check spam folders for false positives.

Skipping p=quarantine means your first enforcement step drops mail permanently. If you missed a legitimate sender, those messages are gone with no recovery path.

Fix: Always go p=none → p=quarantine at low pct= → p=quarantine at 100% → p=reject. Each stage has a monitoring window.

6. Not Using the pct= Tag During Rollout

The pct= tag tells receiving servers to apply the policy to only that percentage of failing messages. At pct=10, only 10% of DMARC failures get the quarantine/reject treatment—the rest are treated as p=none.

Most guides don't mention this tag. It's the most important safety mechanism in the DMARC specification. It limits blast radius while you're ramping up enforcement and gives you time to catch misconfigured senders before they affect all mail.

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.com

Fix: Start every policy transition at pct=10 and increase in weekly increments.

7. Forgetting Subdomains

By default, subdomains inherit the parent's DMARC policy. But many organizations have subdomains used for specific purposes—notifications.yourcompany.com, alerts.yourcompany.com, legacy.yourcompany.com—where authentication can't be properly configured.

If those subdomains inherit p=reject, their mail starts bouncing. You also need sp=reject explicitly if you want subdomains protected from spoofing, because some receivers interpret inheritance differently.

Fix: Audit all subdomains that send email. Add explicit sp= policies or per-subdomain DMARC records for subdomains with non-standard sending requirements.

8. Treating p=reject as Set-and-Forget

Email infrastructure changes constantly. New SaaS tools get onboarded, marketing agencies get added to sending lists, someone spins up a new service that sends alerts—and none of it goes through your DMARC review process.

The day you add an unauthenticated sender after you're at p=reject, that sender's mail starts bouncing immediately with no warning.

Fix: Establish a change control process for any DNS or email-sending change. Review aggregate reports weekly indefinitely, not just during implementation.

9. Using Forensic Reports (ruf=) Without Privacy Review

Forensic reports (RUF) contain copies of individual failing messages, including message headers and sometimes body content. In many jurisdictions, collecting and retaining this data triggers privacy obligations.

Many organizations blindly copy the ruf= configuration from sample DMARC records without realizing they're now receiving copies of potentially sensitive email content.

Fix: Evaluate whether forensic reports are necessary for your use case. Aggregate reports (RUA) provide sufficient visibility for most implementations. If you enable ruf=, review your privacy obligations.

10. Not Verifying the DMARC Record Actually Published Correctly

DNS propagation can take up to 48 hours. Typos in DMARC records cause silent failures (the record parses incorrectly and defaults to p=none). Many teams update their DMARC record and assume enforcement is active without verifying.

Fix: After any DMARC change, verify with:

dig TXT _dmarc.yourdomain.com +short

Cross-check with MXToolbox's DMARC lookup tool to confirm the policy parses correctly.

---

The Migration Path: p=none → p=quarantine → p=reject

Here is the exact sequence that reliably reaches full enforcement without breaking legitimate mail.

Stage 1: Deploy Monitoring (Week 1–2)

Publish a p=none record pointing to your reporting inbox or platform. No enforcement, just visibility.

_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1"

What to do: Do nothing except let reports accumulate. You need a minimum of 14 days—ideally 30—to see the full range of legitimate senders. Some systems only send weekly. Some only send when triggered by specific events.

Stage 2: Sender Inventory and Authentication (Week 2–6)

Export your aggregate report data and build a complete sender inventory:

Sender	IP Range	SPF Status	DKIM Status	Action Needed
Google Workspace	209.85.x.x	Pass	Pass	None
Mailchimp	198.2.x.x	Fail (alignment)	Fail	Configure DKIM
SendGrid	167.89.x.x	Pass	Pass	None
Zendesk	185.89.x.x	Fail	Fail	Configure both
Legacy CRM	10.0.1.x	Fail	None	Migrate to relay

For every sender showing failures, take the required authentication action before proceeding. This is the work. It takes 2–4 weeks depending on how many senders need configuration.

Target before proceeding: 95%+ of legitimate mail volume passing DMARC.

Stage 3: Quarantine Rollout (Week 7–10)

Once legitimate mail is authenticating cleanly, begin enforcement at quarantine with a low percentage.

Week 7: p=quarantine; pct=10 Week 8: p=quarantine; pct=25 Week 9: p=quarantine; pct=50 Week 10: p=quarantine; pct=100

At each stage, review reports for unexpected failures. Check spam folders across your organization for quarantined legitimate mail. If you see legitimate failures, pause and fix before advancing.

_dmarc.yourdomain.com TXT "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@yourdomain.com"

Stage 4: Reject Rollout (Week 11–12)

After running p=quarantine; pct=100 cleanly for one week, advance to reject on the same percentage ramp.

Week 11: p=reject; pct=25 Week 11 (mid-week): p=reject; pct=50 Week 12: p=reject; pct=100

Final record at full enforcement:

_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@yourdomain.com; fo=1"

---

Monitoring Tools

You need ongoing visibility after reaching p=reject. One unconfigured new sender means bounced mail.

Tool	Best For	Cost
dmarcian	Enterprise, detailed analytics	$199–$499/mo
Valimail	Automated sender authentication	$299+/mo
Postmark DMARC	Small domains, quick setup	Free tier available
EasyDMARC	Mid-market, good UX	$50–$199/mo
Manual XML parsing	Low volume, technical teams	Free

For most 20–200 person companies, EasyDMARC or Postmark covers the monitoring needs at reasonable cost. The key requirement: weekly report review and alerting on new failure sources.

---

Impact on Deliverability

The relationship between p=reject and deliverability is frequently misunderstood. A well-implemented p=reject improves deliverability for legitimate mail—it does not hurt it.

Here's why: major inbox providers (Gmail, Microsoft 365, Yahoo) use DMARC policy as a trust signal when evaluating sender reputation. Domains at p=reject signal that the domain owner has invested in authentication, which correlates with legitimate sending behavior.

What damages deliverability is a poorly implemented p=reject that causes legitimate mail to bounce. Bounces hurt sender reputation across all major providers. A 5% bounce rate will begin affecting deliverability within days.

The inverse is also true: staying at p=none indefinitely does not protect deliverability. It leaves your domain available for spoofing, and spoofed mail sent from your domain can damage the domain's reputation whether or not you sent it.

Real-world result: A 150-person SaaS company that completed a proper p=reject migration reported zero deliverability degradation on legitimate mail and 340 blocked spoofing attempts in the first 30 days post-enforcement.

---

What to Do If You're Currently Stuck at p=none

If your DMARC has been sitting at p=none for more than 6 months, you likely have one of two problems: report data you haven't acted on, or a sender you identified but couldn't get authenticated.

Start by pulling the last 30 days of aggregate reports and categorizing every source. For each unauthenticated source, determine: is it a known legitimate sender or unknown traffic?

• Known legitimate sender: Prioritize DKIM configuration. Most platforms have documentation for this. It typically takes 30–60 minutes per sender.
• Unknown traffic: This is likely spoofing or forgotten legacy infrastructure. Investigate the IP range before deciding.

The most common blocker is a legacy system that someone owns but nobody wants to touch. The workaround is subdomain isolation—move that sender to a subdomain with its own p=none policy while enforcing p=reject on the parent domain.

For a complete implementation walkthrough including SPF and DKIM configuration for 20+ common platforms, the PlatOps email security service includes DMARC migration as a managed engagement with a defined 90-day path to p=reject.

---

Get Your Domain to p=reject

DMARC p=reject is achievable for every organization. The process is methodical, not magical—it requires a proper inventory, authentication work on third-party senders, and a staged rollout with monitoring at each step.

The organizations that fail do so for predictable reasons: they skip the inventory, they rush the rollout, or they treat p=reject as the end of the process rather than the beginning of ongoing management.

Done correctly, you end up with your domain fully protected against spoofing—and a monitoring process that keeps it that way as your email infrastructure evolves.

Book a free email security assessment to get a current-state report on your domain's authentication posture, including every sender found in your DNS traffic and a prioritized remediation plan.