How to decide when a client is ready for p=reject
A client is ready for p=reject when every legitimate sending service has been identified, required traffic passes aligned SPF or DKIM, DMARC reports show no unexplained high-volume failures, 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 tells receiving systems to reject mail that fails DMARC, so an incomplete sender inventory can interrupt real business mail.
For most clients, I move through monitoring, remediation, quarantine, and then reject. Time spent at each stage matters less than clean evidence. A domain that has produced stable, understood reports for two weeks can be safer than one left at p=none for a year without active review. 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 five gates before recommending reject. All five must pass. A strong aggregate pass rate cannot compensate for an unknown payroll system, and a complete inventory cannot compensate for broken alignment. 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.
Five gates that must pass
- Sender inventory: Every source in recent DMARC data has an owner and an approved or unauthorized status.
- Alignment: Each approved sender passes DMARC through aligned SPF or aligned DKIM.
- Coverage: Reporting covers normal operations, scheduled campaigns, billing runs, and other periodic mail.
- Enforcement test: A controlled quarantine stage 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, and expected volume for each approved sender.
Evidence to collect before enforcement
The review window must include the client's real sending cycle. Thirty days is a useful default because it catches many monthly systems, but it is not a protocol requirement. Extend the window when the client sends quarterly notices, seasonal campaigns, annual statements, or irregular incident notifications. Shorten it only when the sender estate is small, stable, and confirmed by the people who own each application.
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 the first and the well-understood unauthorized categories support a reject decision.
|
|
|
|---|---|---|
Sources | All classified | Owner log |
SPF | Aligned or backup | Report sample |
DKIM | Aligned and valid | Selector check |
Coverage | Full send cycle | Date record |
Approval | Named owner | Change ticket |
Compact evidence record for each client domain
DMARC aggregate data is the primary evidence, but 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.
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 understood forwarding that does not threaten a required workflow.
Operational readiness bands
These are MSP review bands, not requirements in the DMARC specification. Classification and business impact override the percentage.
Ready for final review
99%+ aligned
Approved sources are aligned 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.
Use quarantine as an enforcement rehearsal
Quarantine is a useful rehearsal when it is actively monitored. I normally start with a limited percentage, review receiver behavior and support tickets, then raise coverage after each clean observation period. The exact pace depends on mail volume and business risk. A high-volume retailer can collect evidence quickly, while a low-volume professional firm needs more calendar time to cover infrequent senders. The detailed quarantine readiness process should finish before this final stage.
Quarantine rehearsal
- Purpose: Expose hidden legitimate failures with lower operational impact.
- Start: Use a limited percentage for representative traffic.
- Watch: Review failure sources, help desk cases, and missing expected mail.
- Exit: Reach full coverage without unresolved legitimate impact.
Reject rollout
- Purpose: Stop mail that fails DMARC at participating receivers.
- Start: Use a small percentage after formal approval.
- Watch: Track new failure sources and client delivery incidents.
- Exit: Reach full rejection and continue daily monitoring.
Example quarantine rehearsal recordDNS
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com
The pct tag can reduce exposure during the change, but it does not repair authentication. Receiver handling can also differ, so I do not treat a quiet help desk as proof by itself. The evidence still needs DMARC report review, direct tests of critical systems, and confirmation that expected mail arrived. After a clean full-quarantine period, I schedule the first reject percentage as a separate controlled change.
Stage p=reject with clear stop conditions
I use staged rejection for risk control, not because DMARC requires it. A common sequence is 10%, 25%, 50%, 75%, and 100%. Each step needs enough message volume to be meaningful. Low-volume clients often need several business days at a step, while high-volume domains can expose problems sooner. The full staged enforcement plan should document who can advance or pause it.
Example first reject stageDNS
v=DMARC1; p=reject; pct=10; rua=mailto:dmarc@example.com
- Advance: Residual failures remain classified and no legitimate sender incident is open.
- Pause: A new source appears, expected volume vanishes, or ownership is uncertain.
- Rollback: Confirmed business mail is rejected and cannot be remediated within the agreed window.
- Escalate: A client owner disputes source status or a critical application lacks a technical owner.
Publish during a staffed change window and account for DNS TTL. I prepare the rollback value before the change and record the previous policy exactly. Lowering the percentage, returning to quarantine, or returning to monitoring can reduce impact, but the chosen rollback depends on the incident. DNS caching means relief is not instant, which makes rapid classification and sender repair more useful than repeated record changes.
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. 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, evidence window, 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 unaligned authentication, recent reports contain unexplained traffic, the observation window missed a required send cycle, 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 rejecting unauthenticated mail 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, and it is the best overall choice for this MSP workflow because it puts multiple client organizations in one dashboard and turns authentication issues into concrete remediation steps. The same operating view can cover DMARC, SPF, DKIM, blocklist monitoring, and deliverability signals without losing tenant separation.
I use verified and unverified source views to drive the inventory gate, real-time alerts to catch regression, and client reports to document progress for stakeholders. Suped's hosted DMARC workflow also supports controlled policy staging when the MSP manages the change. Automation helps with consistency, but the MSP still owns sender validation, 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 first 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. Pair the result with current aggregate reports and live message tests before advancing the percentage.
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. If nothing unusual appears, monitoring continues through the agreed observation period before the next percentage increase.
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 aligned authentication, unexplained sources are resolved, the observation window covers real business cycles, quarantine has completed without unresolved impact, and accountable people have approved staged enforcement 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 five 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 reaches 100%, the service remains active because new senders and configuration drift can reopen risks that were closed during rollout.
