How to decide when a client is ready for p=reject
Updated on 28 Sep 2026: We updated this guide for RFC 9989 and its current p=reject rollout guidance.
A client is ready for p=reject when every legitimate sending service has been identified, required traffic has valid aligned DKIM, DMARC reports show no unexplained legitimate failures, the domain's use is suitable for reject, and both the MSP and client have approved a tested rollback plan. I treat p=reject as an operational change, not a DNS housekeeping task. The policy states the domain owner's preference for handling mail that fails DMARC, but receivers apply local analysis and do not necessarily reject every failed message.
For clients pursuing reject, I move through monitoring, remediation, at least one month at p=none, and an equally long period at p=quarantine before the reject change. These are minimum observation periods under RFC 9989, not automatic approval points. MSPs need a repeatable acceptance standard that works across many tenants and leaves a clear audit trail for every policy change.
The reject readiness standard
I use six gates before recommending reject. All six must pass. A strong aggregate pass rate cannot compensate for an unknown payroll system, and a complete inventory cannot compensate for broken alignment or a domain that carries high-risk indirect mail. This gate model gives the service desk a consistent decision and gives the account owner a plain explanation for a delay. It also fits a broader DMARC for MSPs operating model.
Six gates that must pass
- Sender inventory: Every source in recent DMARC data has an owner and an approved or unauthorized status.
- Alignment: Each approved stream has valid aligned DKIM and does not depend only on SPF for a DMARC pass.
- Coverage: Reporting covers normal operations, scheduled campaigns, billing runs, and other periodic mail.
- Domain suitability: Mailing-list participation, forwarding, aliases, and other indirect flows have been assessed.
- Enforcement test: At least one month at quarantine caused no unresolved legitimate delivery incidents.
- Change control: The client approver, rollback record, monitoring owner, and support path are documented.
A gate fails when its evidence depends on assumption. For example, a source that looks like a known cloud provider still needs confirmation from the client or application owner. Shared infrastructure and forwarding can make source names misleading. I record the business process, technical owner, visible From domain, authentication method, expected volume, and DKIM signing domain for each approved sender.
Evidence to collect before enforcement
For a domain pursuing reject, collect at least one month of reports at p=none and then an equally long period at p=quarantine. Extend either window when the client sends quarterly notices, seasonal campaigns, annual statements, or irregular incident notifications. The review window must include the client's real sending cycle, so the minimum period does not replace coverage of infrequent mail.
I review domain-level totals and individual sources. Aggregate percentages can hide a low-volume system that handles password resets or legal notices. The source needs a clear disposition: approved and aligned, approved but being fixed, unauthorized, forwarding-related, or unknown. Only approved and aligned sources, plus well-understood unauthorized traffic, support a reject decision.
|
|
|
|---|---|---|
Sources | All classified | Owner log |
DKIM | Aligned and valid | Selector check |
Indirect mail | Risk assessed | User review |
Coverage | Full send cycle | Stage dates |
Approval | Named owner | Change ticket |
Compact evidence record for each client domain
DMARC aggregate data is the primary evidence, but it covers only mail observed by receivers that send reports. I also send test messages through critical applications and inspect the Authentication-Results header. That catches configuration drift between what an application owner described and what the application sends. It also verifies the exact visible From domain because a vendor can use different domains across products or tenants.
Review policy override reasons in aggregate reports, especially mailing-list and forwarded traffic, and check every active subdomain separately. The organizational-domain record can apply to subdomains, while an explicit subdomain record can set a different policy. Record which policy was discovered for each sending domain instead of assuming inheritance.
Ongoing DMARC monitoring is important after enforcement because senders change. A new marketing platform, support system, or acquisition can introduce mail without warning. Reject readiness therefore includes an owner who will review alerts and a process that brings new senders through authentication before launch.
Thresholds that support the decision
No DMARC standard defines a required pass percentage for p=reject. I use 99% aligned legitimate volume as a strong operational target, then inspect the remaining failures individually. A client at 99.8% can still be unready if the 0.2% contains account recovery mail. A client at 98.7% can be ready when every failure is confirmed unauthorized traffic or an understood receiver override, provided every legitimate stream has valid aligned DKIM and the other readiness gates pass.
Operational readiness bands
These are MSP review bands, not requirements in the DMARC specification. Classification, DKIM coverage, and business impact override the percentage.
Ready for final review
99%+ aligned
Approved sources use aligned DKIM and residual failures are explained.
Remediate and retest
95-98.9% aligned
Known legitimate failures remain or the test window is incomplete.
Do not enforce
Below 95%
Material legitimate traffic fails or unknown sources remain.
Manual exception
Any percentage
Any critical low-volume sender fails, regardless of the total rate.
Volume stability matters too. I compare daily source counts and investigate sudden disappearances, because a silent sender cannot prove readiness. If a monthly invoice platform has not sent during the observation window, I wait for its normal run or arrange a representative test. I also check subdomains separately. The organizational domain can look healthy while a delegated subdomain has different senders and policy needs.
Check whether p=reject fits the domain
A technically clean domain is not automatically a good p=reject candidate. RFC 9989 says domains with general users who might post to internet mailing lists should not publish p=reject because indirect mail can lose SPF alignment and message changes can invalidate DKIM. The result can be rejected posts or automatic removal of recipients whose addresses appear to bounce.
Stronger reject candidate
- A controlled transactional or notification domain has no human mailbox users.
- Every legitimate stream applies a valid aligned DKIM signature.
- Forwarding and role-address paths have been tested with representative messages.
Keep at quarantine
- People send routine mail and participate in external mailing lists.
- Any required stream depends only on SPF for its DMARC pass.
- Indirect delivery remains untested or causes unexplained policy overrides.
When one organizational domain mixes human mail with controlled application mail, separate domain use can make policy decisions clearer. A dedicated sending subdomain can use its own DMARC record and move to reject while the general-purpose domain remains at quarantine. Document the policy that applies to existing subdomains and non-existent subdomains before approval.
Use quarantine as an enforcement rehearsal
Quarantine is the required rehearsal for a domain pursuing reject under the RFC 9989 guidance. After at least one month at p=none and remediation of legitimate failures, publish p=quarantine and observe it for at least an equally long period. Extend the period when mail volume is low or a required send cycle has not occurred. The detailed quarantine readiness process should finish before this final stage.
Quarantine rehearsal
- Purpose: Expose hidden legitimate failures before reject.
- Start: Publish p=quarantine after the p=none evidence period.
- Watch: Review failure sources, override reasons, and missing expected mail.
- Exit: Complete at least one month without unresolved legitimate impact.
Reject change
- Purpose: State a reject preference for mail that fails DMARC.
- Start: Publish the full policy after formal approval.
- Watch: Track new failure sources and client delivery incidents.
- Maintain: Continue daily monitoring after the policy change.
Example quarantine recordDNS
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
RFC 9989 removed the pct tag because receivers did not apply intermediate percentages consistently. An old record containing pct does not provide a dependable ramp. The t=y tag now signals policy test mode and an expectation that the receiver use handling one level below the published policy, but receiver handling remains discretionary. For readiness evidence, I use a clean full-quarantine period, direct tests of critical systems, and confirmation that expected mail arrived.
Move to p=reject as a controlled change
The current DMARC specification does not support a 10%, 25%, 50%, and 75% reject ramp. After the quarantine period and all six gates pass, I schedule one controlled change to p=reject. The enforcement plan should document who can approve, pause, or roll back the change.
Example reject recordDNS
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
- Validate: Confirm the authoritative record, discovered policy, and expected TTL after publication.
- Pause: Stop related sender changes when a new source appears, expected volume vanishes, or ownership is uncertain.
- Rollback: Return to quarantine when confirmed business mail fails and cannot be repaired within the agreed window.
- Escalate: Involve the client approver when source status is disputed or a critical application lacks a technical owner.
Publish during a staffed change window and account for DNS TTL. I prepare the quarantine rollback value before the change and record the previous policy exactly. DNS caching means relief is not instant, which makes rapid classification and sender repair more useful than repeated record changes. Continue monitoring beyond the change window because aggregate reports arrive after the messages they describe.
A six-step flow for approving, staging, and monitoring a DMARC reject policy.
Make ownership part of readiness
Technical readiness without client ownership creates avoidable support risk. The MSP can classify sources and recommend a policy, but the client knows which business processes cannot tolerate interruption and whether users participate in mailing lists. I require one business approver and one operational contact. The approver accepts the change risk. The operational contact validates affected workflows and can reach application owners during rollout.
The change ticket should include the current record, proposed record, p=none and p=quarantine evidence periods, known exceptions, scheduled time, DNS TTL, stop conditions, rollback value, and named decision makers. A written client responsibility model prevents uncertainty when a new sender appears during the project. It should also require advance notice before anyone launches a platform that uses the client's domain.
Do not approve reject yet
Stop the rollout when the client cannot name owners for legitimate senders, a critical source relies only on SPF, recent reports contain unexplained traffic, either minimum policy period is incomplete, a required send cycle was missed, general users depend on internet mailing lists, or nobody has authority to approve rollback. These are service delivery gaps, even when the domain's total pass rate looks high.
I also separate authentication failure from delivery failure. Passing DMARC does not guarantee inbox placement, and a reject preference does not repair content or reputation problems. During rollout, the incident record needs message samples and receiver responses so the team does not weaken policy to solve an unrelated delivery complaint.
Run the workflow across many clients
At MSP scale, spreadsheets become fragile because classification, policy state, alerts, and approvals change at different times. Suped is our DMARC and email authentication platform. Its multi-tenant view keeps client organizations separate while analysts track DMARC, SPF, DKIM, blocklist (blacklist) monitoring, and delivery signals in one operating workflow.
Verified and unverified source views support the inventory gate, alerts catch regression, and client reports document progress for stakeholders. Suped's hosted DMARC workflow supports controlled policy changes when the MSP manages DNS. Automation improves consistency, but the MSP still owns sender validation, domain suitability, client approval, and business-impact decisions.
Issues page showing verified and unverified source sections for reviewing sending sources
The source view gives analysts a shared queue instead of separate notes. Each analyst can investigate authentication results, confirm the sending service with the client, and move the source toward a documented disposition. For quality control, I sample completed classifications before approving the enforcement change, especially for domains with many agencies or legacy applications.
Keep a focused DNS validation step in the change checklist. The checker below can confirm that the published policy parses correctly after a change, but it cannot prove that the sender inventory is complete or that reject suits the domain. Pair the result with current aggregate reports and live message tests before approval.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
After publication, I verify the authoritative response and then check again after the expected TTL. I record the observed policy in the ticket, watch failures during the staffed window, and compare source volume with the pre-change baseline. Monitoring continues through the agreed observation period, with rollback available if legitimate mail fails.
Standard templates make this repeatable: one evidence record, one approval checklist, one rollback pattern, and one post-change review. Client-specific mail systems still need individual analysis. The standard belongs around the decision process, not around assumptions about which senders each client uses.
Approve reject only when the evidence is complete
A client is ready for p=reject when approved senders use valid aligned DKIM, unexplained sources are resolved, observation covers at least one month at p=none and an equally long period at quarantine, the domain's use is suitable for reject, and accountable people have approved the change and rollback. The percentage is supporting evidence, not the final decision. Critical low-volume mail deserves the same scrutiny as bulk traffic.
For MSP operations, I make the six gates mandatory and store their evidence with the change. That creates a defensible decision for the client, a clear handoff for the service desk, and a reusable process for the next domain. Once reject is published, the service remains active because new senders and configuration drift can reopen risks that were closed during rollout.
