How to Move to a p=reject Policy Without Breaking Email Delivery

What a p=reject Policy Actually Does

When a domain’s DMARC policy is set to p=reject, receiving servers are instructed to block the delivery of any message that fails DMARC alignment. A message fails alignment when the domain authenticated by SPF or DKIM doesn’t match the domain in the “From” header – the address recipients see when they open an email.

How the three policies work:

1. p=none – Monitor only. Reports are generated, but no action is taken on messages that fail alignment. Spoofed emails are still delivered to recipients.
2. p=quarantine – Messages that fail alignment are routed to Spam or Junk rather than being blocked outright.
3. p=reject – Messages that fail alignment aren’t delivered. This is the only policy that prevents spoofed emails from reaching recipients.

A common misconception is that a p=reject policy disrupts legitimate email. It doesn’t – provided authentication is configured correctly. A p=reject policy only blocks messages that fail alignment. For most businesses, a well-configured sender environment means that a p=reject policy will have minimal impact on delivery.

When Organizations Are Ready to Move to a p=reject Policy

Moving too early – before all legitimate sending sources are identified and authenticated – causes legitimate email to be blocked. Three conditions must be met before advancing the policy:

1. All legitimate sending services are identified and included in the SPF record.
2. DKIM is configured, and a valid public key is published in the DNS for every sending service.
3. DMARC aggregate reports show a consistent, high pass rate for legitimate traffic with no unexplained failures.

Readiness is determined by report data, not by how long the policy has been in place. A company with a straightforward email environment may be ready to advance quickly. An enterprise with dozens of sending tools across business units, regions, and departments may need more time. Every sending service must be identified and authenticated before enforcement can begin.

This is where many enterprise IT teams run into difficulty. Marketing platforms, HR systems, and finance tools are routinely added by departments without IT visibility or updates to SPF and DKIM records.

These unauthorized senders appear in DMARC reports as authentication failures. They are one of the most common reasons organizations stall at p=none.

How to Move to a p=reject Policy Safely

Step 1: Read and Act on Aggregate Reports

DMARC aggregate reports contain a breakdown of all email traffic claiming to originate from the domain, including which sources passed or failed SPF and DKIM alignment. These reports are the primary tool for identifying gaps before advancing policy.

Look for:

• Sources with high sending volumes that are failing authentication
• Unknown or unauthorized sending services not recognized by IT
• Legitimate services with misconfigured SPF or DKIM settings

Aggregate reports are delivered as XML files. Interpreting this data manually – across multiple domains, at enterprise scale – isn’t practical. Security and IT teams are already stretched. Adding manual XML analysis to the workload of teams managing distributed email environments and multiple domains isn’t a sustainable approach.

Step 2: Identify and Authenticate All Legitimate Senders

Before enforcing policy, every legitimate sending service must pass SPF and DKIM alignment. The two most common failure patterns are:

SPF Failures

The sending service’s IP addresses or servers aren’t included in the SPF record for the domain. Resolve this by adding the service’s legitimate senders to the SPF record.

Example SPF record:

DKIM Failures

The sending service doesn’t have a DKIM key pair, or the public key isn’t published in the DNS. Resolve this by generating a DKIM key pair for the service and publishing the public key as a TXT record in the DNS.

Example DKIM record:

Each sending service requires its own DKIM key pair. A single domain sending through five platforms needs five key pairs – each generated, configured in the sending service, and published in the DNS.

At the enterprise level, coordinating these DNS changes across departments, without disrupting operations or triggering long internal approval cycles, is one of the most common operational challenges in DMARC deployment.

Step 3: Advance to a p=quarantine Policy

Once reporting data confirms that all legitimate senders are passing authentication consistently, advance the policy to p=quarantine. At this stage, failing messages are routed to recipients’ Spam or Junk folders rather than being blocked entirely. This provides an additional monitoring window to identify any legitimate sender missed during the earlier review phase.

Continue monitoring aggregate reports during this phase. If legitimate emails begin appearing in Spam or Junk folders, identify the sending sources and resolve the authentication failures before advancing further.

Step 4: Advance to a p=reject Policy

When reporting data confirms a consistently high pass rate across all legitimate sending sources, advance to a p=reject policy. Receiving servers will block the delivery of any message that fails DMARC alignment.

Maintaining a p=reject Policy After Enforcement

Reaching p=reject isn’t the end of the process. Email environments change continuously. New sending tools are added by departments, DKIM keys expire, SPF records accumulate entries, and companies launch new domains through acquisitions or regional expansion – often without configuring authentication.

Without continuous monitoring, the enforcement achieved through structured policy progression erodes. Any new sending tool must be added to SPF records, or authentication will fail. An expired DKIM key will break alignment.

Maintaining a p=reject policy requires:

• Continuous monitoring of DMARC aggregate reports across all domains
• Alerts when new or unauthorized senders appear in report data
• SPF record updates as sending services are added or removed
• Ongoing DKIM signing validation and key rotation
• Policy management for every new domain added

Businesses that configure a p=reject policy and stop monitoring aren’t protected from the operational drift that breaks authentication over time. Setting up DMARC is one task. Maintaining it across a growing, changing domain portfolio is an ongoing operation.

How Sendmarc Manages the Progression to a p=reject Policy

Advancing a single domain from p=none to p=reject is manageable. Doing it across multiple domains – while coordinating with distributed IT teams, managing SPF records across multiple senders, rotating DKIM keys, monitoring aggregate reports, and identifying unauthorized sending tools – is an operational burden most teams can’t sustain without dedicated tooling.

Sendmarc provides the reporting, visibility, and policy management needed to reach and maintain a p=reject policy across all domains without adding to the workload of stretched IT and security teams.

Sendmarc offers:

• DMARC Management: DMARC policy status and aggregate report data are visible across all domains, replacing manual XML processing with actionable reporting
• SPF Optimization: SPF records are managed and optimized as sending infrastructure changes, preventing authentication failures caused by record bloat
• DKIM Maintenance: DKIM signing is tracked across all sending platforms, and selectors and key rotation are managed throughout
• Identification of Unauthorized Senders: Unknown or unapproved sending services are surfaced from aggregate report data, giving IT teams a complete picture of every source sending email on behalf of the organization
• Continuous Monitoring: Alerts and reporting continue after enforcement is reached, providing the ongoing oversight needed to maintain a p=reject policy as email environments evolve

This is the difference between a one-time configuration and continuous enforcement. Companies that require ongoing optimization beyond initial setup – not a “set and forget” approach – need a platform that monitors, alerts, and manages policy across the full domain portfolio.

See how Sendmarc manages DMARC policy progression at enterprise scale.