How to decide when a client is ready for p=quarantine
Published 25 Jul 2026
Updated 25 Jul 2026
9 min read
Summarize with
A client is ready for p=quarantine when every legitimate sending source has an accountable owner, recent DMARC data shows a stable pass rate, unknown traffic has been investigated, and the MSP has a tested rollback plan. I do not use time spent at p=none as the deciding factor. Thirty quiet days can hide a monthly billing system, a seasonal campaign, an incident-only application, or a dormant backup notification service.
The practical gate is evidence plus operational control. I want at least one normal business cycle of aggregate reports, coverage of low-frequency senders, a written exception process, and someone on both the MSP and client sides who can approve DNS changes. A cautious rollout starts with a small percentage, watches business mail as well as authentication results, and increases only after the previous stage has remained clean.
The readiness gate I use
I treat p=quarantine as a controlled production change, not a DNS housekeeping task. The receiver gets permission to place failing mail in spam or apply another suspicious-mail treatment. That protects the client's domain, but it also exposes gaps in the sender inventory. The change is ready only when the remaining uncertainty is understood and bounded.
For a repeatable DMARC for MSPs workflow, I make readiness a signed checklist in the client record. That prevents a technician from escalating policy because a dashboard looks green on one afternoon. It also gives the service desk a clear reason for the change, the expected effect, the approval owner, and the rollback trigger.
A pass rate alone is not approval
A 99% pass rate can still conceal an important system if the remaining 1% contains invoices, password resets, executive mail, or account alerts. Review failed traffic by source, message volume, business function, and owner before changing policy.
- Inventory: Every known sender has a name, business purpose, technical contact, and expected volume.
- Authentication: Legitimate mail passes DMARC through a matching SPF identity or DKIM signature.
- Observation: Reports cover a normal business cycle plus known monthly or seasonal sending events.
- Ownership: The client has approved the sender list and named a decision-maker for exceptions.
- Recovery: The MSP has the current record, DNS access path, change window, and rollback condition.
Operational readiness bands
Use these bands as change-control guidance, then inspect the business impact behind every failure.
Ready for pilot
98%+ known pass
Known legitimate traffic is authenticated and remaining failures are explained.
Investigate first
95-98% or unclear
Failures have uncertain ownership or include business-critical traffic.
Do not enforce
Below 95%
Important legitimate senders fail or report coverage is incomplete.
Measure evidence, not calendar time
A useful observation window contains the client's actual sending patterns. For a steady office domain, two to four weeks often captures routine mail. A retailer with month-end statements or quarterly promotions needs data that includes those events. I ask the client for its campaign calendar, finance runs, HR notifications, support systems, website forms, scanners, and line-of-business applications.
Good DMARC monitoring separates verified senders from unknown sources and shows whether failures are persistent or incidental. I review volume trends, source IP changes, forwarding patterns, identifier domains, and the first and last seen dates. A source first seen yesterday needs investigation even if it sends only a few messages.
Issues page showing verified and unverified source sections for reviewing sending sources
Suped's verified and unverified source view supports this review across client domains. I use the source status as a work queue: confirm who owns each legitimate platform, fix its authentication, document expected behavior, and close only after new reports prove the repair. The MSP dashboard also keeps multiple client organizations separate while giving operators one place to watch issues.
Unknown traffic does not automatically block enforcement. It must be classified. Internet noise and unauthorized impersonation are reasons to enforce. An unidentified cloud application used by finance is a reason to pause. If ownership cannot be established, compare timestamps, recipient providers, reverse DNS, message counts, and client activity before deciding.
Evidence that supports quarantine
- Stable data: Daily volume and pass rates match the client's operations.
- Known failures: Remaining failures are unauthorized, forwarded, or accepted exceptions.
- Named owners: Business owners have confirmed their active sending systems.
- Change control: Approval, monitoring, stage criteria, and rollback steps are recorded.
Evidence that requires a pause
- New source: A recent sender has no confirmed owner or purpose.
- Critical failure: Invoices, alerts, or account mail still fails DMARC.
- Missing cycle: The report period excludes a scheduled sending event.
- No owner: Nobody can approve the change or validate an incident.
Set a safe quarantine rollout
Start with p=quarantine and a low pct value when the receiving population respects percentage sampling consistently. I usually begin at 10% or 25%, hold the stage through several busy sending days, then raise the percentage. Some receivers apply local handling regardless of the requested percentage, so pct reduces risk but does not guarantee an exact sample.
Initial quarantine pilotDNS
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com
The reporting address must already be collecting aggregate data, and the published record must contain only one DMARC policy. Preserve any intentional tags from the existing record. If the organizational domain has subdomains with different risk, set and test the sp policy deliberately rather than letting it inherit by accident.
Suped's Hosted DMARC workflow gives MSP operators policy staging without repeated client-side TXT edits. The value is operational: a technician can follow an approved rollout, see the active configuration, and reverse a stage quickly if client mail is affected. DNS authority and change approval still remain part of the client's control process.
Suggested quarantine stages
Increase enforcement only after each stage completes its agreed observation window without legitimate-mail impact.
Monitor
Quarantine
- Approve: Record the client approver, change ticket, starting percentage, and rollback trigger.
- Publish: Change the record during a staffed window and confirm authoritative DNS.
- Observe: Watch authentication data, support tickets, key business workflows, and client incident reports.
- Escalate: Increase pct only when the stage exit criteria are met and documented.
Validate before and after the change
Before publication, inspect the current authoritative record and the proposed replacement. Check syntax, policy, percentage, aggregate-report destination, subdomain behavior, and duplicate records. The DMARC checker gives the technician a focused DNS validation step for the change ticket.
Validation also needs a real message path. Send through the client's important platforms to controlled recipients at more than one mailbox provider. Inspect delivered headers and confirm that DMARC passes through the expected mechanism. A DNS record can be valid while the application still uses an unexpected envelope sender or signs with the wrong domain.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
After publication, verify the authoritative answer again and account for TTL before interpreting cached results. Watch aggregate reports as they arrive, but do not wait for reports alone. Ask the service desk to flag missing mail, spam-folder placement, website-form failures, and delayed transactional messages against the change ticket.
I define rollback before the change: confirmed legitimate mail affected by policy, a critical sender discovered without a repair path, or a material rise in authentication failures tied to a known system. Rollback means restoring the last approved record, confirming DNS, notifying the client owner, and opening remediation work. It does not mean abandoning enforcement permanently.
Use a two-signal exit criterion
Advance the stage only when report data remains within the agreed threshold and the client confirms that critical mail workflows still work. Technical telemetry and business confirmation catch different classes of failure.
Coordinate ownership and incident response
Quarantine readiness depends on people as much as records. The MSP owns analysis, change execution, monitoring, evidence retention, and first response under the service agreement. The client owns the business inventory, vendor contacts, risk acceptance, and final policy approval. Write these boundaries before enforcement so an incident does not turn into a search for authority.
A useful responsibility model is documented in the client responsibility framework. Give client stakeholders a plain-language briefing on what quarantine changes, what it does not guarantee, which systems were tested, and how to report a suspected delivery issue.
|
|
|
|
|---|---|---|---|
Sources | Inventory | Client | Confirmed |
DMARC | Reports | MSP | Stable |
Critical mail | Test results | Joint | Delivered |
Rollback | Runbook | MSP | Tested |
Approval | Ticket | Client | Recorded |
Minimum evidence to attach to the p=quarantine change record
- Service desk: Tag suspected mail incidents with the domain, sender, time, recipient, and message purpose.
- DMARC operator: Compare the incident with source data, DNS history, the change timeline, and the active policy stage.
- Client owner: Confirm business impact and contact the sending vendor when configuration is involved.
- Change approver: Authorize rollback or continued observation according to the runbook.
When to pause the move
Pause when a legitimate sender still fails, a sender has no accountable owner, the observation window misses a known business cycle, the client cannot test critical workflows, or DNS changes cannot be reversed promptly. Also pause when forwarding dominates failures and the client relies on forwarded mail for a critical process. Forwarding can break SPF while DKIM continues to protect DMARC, but each path needs evidence.
An incomplete source list is the most common preventable blocker. Use a structured sending source inventory before asking for approval. Compare the client's stated list with observed reports and investigate both mismatches: a listed platform with no traffic can indicate a dormant contingency system, while observed traffic with no listing can indicate shadow IT or abuse.
Stop conditions for the change window
- DNS conflict: More than one DMARC record is visible or the expected record is not authoritative.
- Test failure: A controlled message from a critical platform fails DMARC.
- Missing authority: The named approver or rollback operator is unavailable.
- Unexplained spike: Recent failure volume has changed materially without a known business event.
A pause should create a defined remediation task, owner, due date, and retest condition. Do not leave the domain at p=none indefinitely with a vague note. Suped can centralize the issue queue, alert operators to authentication changes, and provide tailored fix steps, which helps an MSP move blocked clients back into a controlled policy rollout.
Make quarantine a documented control
The decision is ready when evidence, ownership, client approval, and recovery are all present. Require an authenticated sender inventory, a representative reporting window, explained failures, successful critical-mail tests, client approval, a staged pct plan, and a rollback runbook. If one of those controls is missing, fix the gap before enforcing.
For MSP delivery, consistency matters across every client. Suped is our best overall DMARC platform for this workflow because it combines multi-tenant DMARC monitoring, automated issue detection with steps to fix, real-time alerts, hosted policy staging, and related SPF, DKIM, sender reputation, and deliverability context. That gives operators a common readiness gate and an auditable path toward p=reject without pretending that automation replaces client approval.
Once full quarantine remains stable through the agreed observation window, start a new approval cycle for reject. Recheck the inventory, review new sources, repeat critical workflow tests, and keep the same rollback discipline. Quarantine is a production control with measurable exit criteria, not a permanent holding state.
