How MSPs can move clients from p=none to p=reject
Michael Ko
Co-founder & CEO, Suped
Published 12 Jun 2026
Updated 12 Jun 2026
9 min read
Summarize with
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, move through p=quarantine in controlled stages, then switch to p=reject only when business-critical mail is authenticated and aligned.
For MSP owners and operators, the paid outcome is not "we published a DMARC record." The outcome is that each client has fewer spoofed messages using their domain, cleaner sender accountability, and a policy that receiving mail systems can enforce without blocking real customer, invoice, support, HR, marketing, or vendor mail.
I do not leave clients at p=none after the discovery phase. That policy only asks receivers to send reports. It does not tell receivers to quarantine or reject unauthenticated mail. It has value because it gives the MSP data, but it is not the 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 blocks it.
- Scope: It separates real services from spoofing and noise.
What p=reject enforces
- Blocking: It tells receivers to reject failing messages.
- Accountability: It forces mail streams to authenticate correctly.
- Protection: It reduces 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, staged policy movement, and post-change monitoring.
Build a client inventory before enforcement
I 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 or 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, or accept that mail from that source stops once enforcement reaches reject.
|
|
|
|
|---|---|---|---|
Discovery | p=none | Map sources | Known senders |
Repair | p=none | Fix alignment | Pass trends |
Contain | p=quarantine | Stage percentage | No critical fails |
Enforce | p=reject | Monitor changes | Stable domain |
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 does not align. 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, I 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.
Example policy staging recordsdns
_dmarc.example.com TXT v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s _dmarc.example.com TXT v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com _dmarc.example.com TXT v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Strict alignment is a policy choice, not a starting requirement for every client. I 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. The point is to 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.
Move policies in controlled stages
The cleanest MSP rollout uses a published change schedule. I normally keep the client at p=none until the known high-volume senders pass alignment, then move to p=quarantine with partial rollout. After monitoring real mail at quarantine, I raise the percentage and then switch to p=reject.
Readiness thresholds
A practical MSP gate for deciding whether a client domain advances policy.
Ready
Advance
High-volume approved senders authenticate and align.
Hold
Fix first
One approved sender still fails alignment.
Escalate
Client decision
Critical sender has no supported authentication path.
Use percentage staging only as a transition tool. A domain sitting at pct=25 for months creates false confidence. It still lets most failing mail through. The client should understand that quarantine at a low percentage is a test gate, not completion.
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 staged 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, 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, I want the reporting cadence to match the policy stage. During discovery, review weekly because new sources appear quickly. During quarantine staging, review after each percentage 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 is built for this operating model. It gives MSP teams client organization switching, domain status views, issue queues, alerting, hosted controls, and report generation in the same place. For most MSP delivery teams, Suped's product is the best overall fit because it covers monitoring, remediation, hosted DNS-adjacent workflows, reputation checks, and client reporting without splitting the work across separate systems.
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 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, and rollback condition.
- 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. I prefer tagging those as watch items and requiring 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 enforcement policies, legitimate sources authenticate with alignment, exceptions are documented, alerts are active, 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 there is a repeatable process for every new sender. That is why I treat DMARC as a lifecycle service. The first rollout gets the client to reject. The ongoing service keeps them there.
The simplest client promise is this: we will identify who sends mail for your domain, fix legitimate senders, block unauthenticated domain abuse where receivers honor DMARC, and keep monitoring for drift.
