How MSPs can move clients from p=none to p=reject
Updated on 14 Aug 2026: We updated this playbook for RFC 9989, current policy testing, subdomain control, and safer MSP rollbacks.
MSPs move clients from p=none to p=reject by treating DMARC enforcement as a managed rollout, not a one-time DNS edit. The practical sequence is simple: collect reports, identify every legitimate sender, fix SPF or DKIM alignment for those senders, apply p=quarantine as a controlled policy stage, then switch to p=reject only when business-critical mail is authenticated and aligned.
For MSP owners and operators, the client outcome is not "a DMARC record was published." The outcome is that each client has fewer spoofed messages using their domain, cleaner sender accountability, and a policy that receiving mail systems can use without disrupting real customer, invoice, support, HR, marketing, or vendor mail.
Do not leave clients at p=none after the discovery phase without a documented reason. That policy only asks receivers to send reports. It does not request quarantine or rejection for unauthenticated mail. It gives the MSP essential data, but it is not the default destination.
Start with policy control, not DNS changes
The first MSP mistake is changing policy before owning the client inventory. A client often has more senders than they remember: Microsoft 365, Google Workspace, CRM platforms, accounting systems, billing tools, ticketing systems, marketing platforms, form plugins, website hosts, scanners, and legacy line-of-business apps. The DMARC project starts by proving which senders are real.
Flowchart showing the MSP DMARC rollout path from adding a domain to enforcing reject.
For MSPs managing many client domains, Suped's product fits this work because it brings DMARC monitoring, SPF and DKIM visibility, hosted policy controls, alerts, blocklist and blacklist monitoring, and client reporting into one operational queue. The multi-tenant view matters because an operator needs to know which client is ready to advance and which one still has a broken sender.
What p=none proves
- Visibility: It shows who is sending as the client's domain.
- Risk: It reveals unauthenticated mail before enforcement affects it.
- Scope: It separates real services from spoofing and noise.
What p=reject requests
- Disposition: It asks receivers to reject failing messages, subject to receiver judgment.
- Accountability: It requires legitimate mail streams to authenticate with alignment.
- Protection: It reduces exact-domain spoofing against staff and customers.
Do not sell enforcement as a DNS-only task. The DNS record is the last visible step. The real work is sender discovery, authentication repair, client approval, policy movement, and post-change monitoring.
Build a client inventory before enforcement
Start every client with a sender inventory. That inventory becomes the operating document for the engagement. It should include the source name, owner, business purpose, envelope-from domain, visible From domain, DKIM selector, SPF path, sending IPs, current authentication result, and whether the source is approved.
- Core mail: Confirm the primary mailbox platform and any shared mailbox routing.
- Business apps: Find accounting, billing, CRM, booking, support, and HR systems.
- Marketing mail: Separate newsletters, campaigns, automations, and one-off sends.
- Infrastructure: Check web servers, forms, printers, scanners, alerts, and backup systems.
- Ownership: Assign each sender to a client contact and an MSP technician.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The inventory also sets client expectations. If a vendor sends mail as the client but refuses to support aligned DKIM or aligned SPF, that vendor is a business risk. The MSP should put that fact in writing and ask the client whether to replace the sender, move it to a subdomain, fix the vendor configuration, or accept that mail from that source stops once enforcement reaches reject.
|
|
|
|
|---|---|---|---|
Discovery | p=none | Map sources | Known senders |
Repair | p=none | Fix alignment | Approved streams pass |
Contain | p=quarantine | Observe full policy | No critical failures |
Enforce | p=reject | Monitor changes | Stable domain and subdomains |
Compact delivery stages for MSP client enforcement.
Fix authentication sources before the policy changes
A source is ready for enforcement when it passes SPF or DKIM and one of those methods is aligned with the visible From domain. Passing SPF alone is not enough if the return-path domain belongs to a vendor and lacks alignment. Passing DKIM alone is not enough if the DKIM signing domain is unrelated to the client's domain. The enforcement decision rests on alignment.
For MSP service delivery, prefer DKIM alignment where the sender supports it. DKIM survives forwarding better than SPF and keeps the sending app accountable. SPF still matters, especially for direct mail streams, but many clients hit lookup limits as more vendors get added. Suped's Hosted SPF and SPF flattening help MSPs manage sender includes without repeated DNS edits.
Current DMARC policy staging recordsdns
_dmarc.example.com TXT v=DMARC1; p=none; sp=none; np=reject; rua=mailto:dmarc@example.com _dmarc.example.com TXT v=DMARC1; p=quarantine; sp=quarantine; np=reject; rua=mailto:dmarc@example.com _dmarc.example.com TXT v=DMARC1; p=reject; sp=reject; np=reject; t=y; rua=mailto:dmarc@example.com _dmarc.example.com TXT v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@example.com
Strict alignment is a policy choice, not a starting requirement for every client. Use strict alignment when the client's sender map is controlled and relaxed alignment when the client has complex vendor usage that still needs cleanup. Document the choice and avoid accidental enforcement.
The fixes usually fall into repeatable MSP runbooks. For the primary mailbox platform, enable DKIM signing and verify the selector. For app vendors, add the vendor's DKIM CNAMEs or TXT records, then confirm the d= domain aligns. For web forms and scanners, route through the primary mail platform or use a dedicated authenticated SMTP relay. For unsupported vendors, move mail to a subdomain so enforcement on the root domain does not depend on weak infrastructure.
Update the runbook for RFC 9989
RFC 9989 replaced the DMARC policy specification in May 2026. It keeps the path through monitoring, quarantine, and reject, but it makes older percentage-based runbooks obsolete. The separate RFC 9990 now defines aggregate reporting, while RFC 9991 defines failure reporting.
|
|
|
|---|---|---|
pct | Historic sampling tag | Remove it during the next controlled record change |
t=y | Requests handling one policy level lower | Use as a test signal, not percentage staging |
sp | Policy for existing subdomains | Inventory and set it deliberately |
np | Policy for non-existent subdomains | Use reject to close unused namespace |
RFC 9989 controls that affect an MSP rollout.
The t=y tag is not a percentage control. With p=quarantine, it requests none-level handling. With p=reject, it requests quarantine-level handling. The tag applies to the p, sp, and np policies in the same record, so test mode can also lower the requested treatment for non-existent subdomains. Receivers still make the final disposition, so an MSP should not treat test mode as a rollback plan or a guarantee. Advance only after reports cover the client's full sending cycle, including monthly or seasonal traffic.
- Existing subdomains: Confirm which ones send mail before setting or inheriting sp.
- Non-existent subdomains: Set np=reject so forged mail using unused names receives the strongest requested policy.
- Indirect mail: Check forwarding and mailing-list traffic, and require aligned DKIM wherever possible.
- Rollback: Pre-approve the prior policy record, DNS owner, decision maker, and incident channel.
For domains whose users post to internet mailing lists, do not make reject automatic. RFC 9989 warns about interoperability problems and advises at least one month at p=none followed by an equally long period at p=quarantine before deciding whether p=reject is appropriate.
Move policies in controlled stages
The cleanest MSP rollout uses a published change schedule. Keep the client at p=none until known high-volume senders pass alignment and the inventory covers a complete sending cycle. Then apply p=quarantine, monitor real mail, and switch to p=reject only after approved sources remain stable.
Readiness thresholds
A practical MSP gate for deciding whether a client domain advances policy.
Ready
Advance
Approved senders pass DMARC across a complete sending cycle.
Hold
Fix first
One approved sender still fails alignment.
Escalate
Client decision
Critical sender has no supported authentication path.
Do not carry pct into new records. RFC 9989 marks it historic because receivers applied intermediate values inconsistently. Use scheduled whole-policy changes, the protocol's t=y test signal where appropriate, separate subdomain policies, and a documented rollback record.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
This is where Hosted DMARC saves MSP time. Instead of asking a client or registrar admin for DNS access at every policy move, Suped's product lets the MSP manage policy changes through a hosted configuration after the required setup is in place. That reduces change friction across a portfolio of domains.
Do not jump straight to reject for a domain with unknown senders. The client will blame the MSP for blocked invoices, booking confirmations, password resets, and customer replies even when the real issue is an unmanaged sender.
Use reporting to make the client handoff clean
Client handoff is where MSPs turn technical work into retained value. A good DMARC service report should show the policy at the start of the period, current policy, approved senders, fixed senders, unresolved senders, rejected traffic, subdomain status, and any client decisions waiting on approval. That gives account managers a plain record of progress without forcing them to explain raw XML reports.
Client reports page showing a generated client report, date range, created date, and actions
For a managed service, match the reporting cadence to the policy stage. During discovery, review weekly because new sources appear quickly. During quarantine, review after each policy or test-mode change. After reject, move to monthly reporting with real-time alerts for new failures, DNS drift, and sudden sender changes.
- Executive view: Show policy movement, enforcement status, and risk reduction.
- Technical view: List sources, failures, DNS records, and exact fixes.
- Account view: Identify blockers, client approvals, and next billing-period actions.
- Security view: Track spoofing attempts, blocklist or blacklist signals, and drift.
Suped's MSP and multi-tenancy dashboard supports this operating model with client organization switching, domain status views, issue queues, alerting, hosted controls, and report generation in one place. That gives delivery teams a shared workflow for monitoring, remediation, reputation checks, and client reporting.
Standardize the MSP runbook
DMARC enforcement works best as a standardized MSP service. The runbook should be clear enough that a technician can run discovery, a senior engineer can approve enforcement, and an account manager can explain the status to a client without improvising.
- Intake: Add the client domain, confirm the DNS owner, and start aggregate reporting.
- Classification: Mark each source as approved, unknown, retired, or malicious.
- Remediation: Fix DKIM, SPF, forwarding paths, and vendor sender domains.
- Change control: Record the policy move, date, client contact, rollback record, and approval.
- Review: Check post-change failures and document the next enforcement step.
A strong MSP runbook has one owner for each client domain and one source of truth for sender status. Without ownership, domains stall at monitoring because nobody is accountable for vendor fixes or policy approval.
The service should also include exception handling. Some clients have seasonal senders, acquisition domains, franchised locations, third-party booking systems, or old tools that send once a quarter. Tag those as watch items and require the client to approve them before policy advancement. That protects the MSP when a forgotten sender reappears.
For MSP positioning, connect this work to managed DMARC services rather than one-off remediation. Clients pay for ongoing assurance: new sender detection, policy drift checks, SPF lookup control, DKIM validation, DMARC policy enforcement, TLS policy options, and reputation signals after the domain reaches reject.
The end state clients pay for
A client is genuinely moved to reject when the root domain and relevant subdomains have deliberate enforcement policies, legitimate sources authenticate with alignment, exceptions are documented, alerts are active, rollback is approved, and reporting shows that new failures are triaged. Publishing p=reject without those controls is fragile. Publishing it with those controls creates a service the MSP can support.
The practical finish line is operational: the client has enforcement, the MSP has visibility, and every new sender follows a repeatable approval process. DMARC is a lifecycle service. The first rollout gets the client to reject when reject is appropriate. The ongoing service keeps legitimate mail aligned and detects drift.
Use a precise client promise: identify who sends mail for the domain, fix legitimate senders, request the strongest appropriate handling for unauthenticated exact-domain abuse, and keep monitoring for drift.
