What MSPs should include in a DMARC readiness assessment
Published 19 Jun 2026
Updated 20 Aug 2026
10 min read
Summarize with
Updated on 20 Aug 2026: We updated this assessment for RFC 9989, evidence-based enforcement gates, subdomain policy, and practical rollback planning.
A DMARC readiness assessment for an MSP client should include domain scope, sender inventory, authentication records, SPF lookup count, DKIM coverage, DMARC policy and reporting, forwarding and relay paths, stakeholder ownership, enforcement risk, remediation plan, alert routing, and a client-ready rollout timeline. It should be a service delivery artifact, not a one-time DNS note, because it has to tell the MSP what to fix, who approves it, and when the client can safely move toward enforcement.
For MSPs building a repeatable offer, the assessment should connect into a wider DMARC for MSPs operating model: onboarding, monitoring, remediation, reporting, and renewal. That makes the assessment useful after the first client meeting instead of a file that sits in a folder.
- Technical state: What DNS records exist today, what passes, what fails, and what is missing.
- Sender ownership: Which teams or vendors own each legitimate mail source and who can approve changes.
- Risk level: Which domains can move quickly, which need cleanup, and which have unknown traffic.
- Service plan: What the MSP will monitor, fix, escalate, and report after the assessment.
What the assessment must prove
The assessment has one job: prove whether the client can start a controlled DMARC rollout without breaking legitimate email. A valid DNS record is only one signal. The evidence must cover authentication results, real sending sources, operational owners, and a practical path to policy enforcement.
MSP DMARC readiness assessment flowchart covering domain scope, sender inventory, DNS checks, risk scoring, remediation, and monitoring.
Readiness test
A client is ready for staged enforcement when legitimate sources pass SPF or DKIM with the visible sending domain, high-volume senders are known, risky mail paths have owners, and the MSP has a monitoring process for new failures.
- Domain coverage: Every active, parked, redirect, defensive, and sending subdomain has a documented status.
- Traffic visibility: Aggregate reports reveal who is sending and whether authentication passes with DMARC alignment.
- Change control: DNS owners, vendor owners, and client approvers are named before policy changes.
- Support motion: Alerts, tickets, and monthly reporting have clear routing across the MSP team.
Scope before DNS
Start with domain scope before checking any DNS record. MSPs often inherit clients with old marketing domains, regional domains, acquired domains, delegated subdomains, and domains that only redirect to the primary website. Those domains still matter because attackers can abuse a weak or empty policy on a forgotten domain.
Include
- Primary domains: Domains used for employee mail and customer-facing replies.
- Marketing domains: Domains and subdomains used for campaigns, newsletters, events, and product updates.
- Unused domains: Parked or defensive domains that still need reject policies.
Do not rely on
- Memory: Client stakeholders forget domains that were used for past campaigns.
- One zone: DNS can be split across registrars, hosts, and legacy providers.
- MX records: A domain can send mail even when it does not receive mail.
The same inventory becomes the start of client onboarding. Record domain purpose, DNS owner, mail owner, current DMARC policy, reporting status, subdomain inheritance, and whether the domain should send at all.
Sender inventory
A useful sender inventory lists every system that sends using the client's domain, then ties each source to an owner and authentication method. Separate confirmed sources from suspected sources because a client conversation can turn guesses into approvals or removals. Classify each unknown source as an approved vendor, shadow IT, a forwarding or relay path, or unauthorized traffic.
|
|
|
|---|---|---|
Primary mail | Microsoft 365, Google Workspace | SPF or DKIM passes with DMARC alignment for normal employee mail. |
Marketing | Campaign and newsletter systems | DKIM keys are live and sender domains are approved. |
CRM | Salesforce or sales tools | Envelope sender and visible From domain are understood. |
Website | Forms, shops, portals | Mail path is authenticated or moved to approved sending. |
Finance | Invoices and billing notices | High-trust mail is tested before enforcement. |
Common sender classes to review during a readiness assessment.
The inventory should include sample messages or headers where possible. A DMARC aggregate report shows source IPs and pass or fail results, but a header sample helps identify a vendor, selector, bounce domain, and the visible From domain faster. Retain only the evidence needed for the assessment and redact message content or personal data before attaching samples to tickets.
Common MSP gap
The easiest source to miss is a low-volume sender that only runs monthly, such as invoices, statements, password resets, or renewal notices. A readiness assessment should use enough reporting history to cover a complete sending cycle.
DNS evidence
The DNS section should document the current DMARC, SPF, and DKIM state for every in-scope domain. Include the exact record, the parsed meaning, pass or fail status, SPF lookup count, DMARC alignment result, and the operational fix when the record is risky.
Starter DMARC record for monitoringTXT
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;
SPF record with common lookup riskTXT
v=spf1 include:_spf.example.net include:send.example.com -all
- DMARC record: Policy, aggregate-report address, alignment mode, test mode, and subdomain controls are recorded.
- SPF record: Lookup count, duplicate records, broad includes, and final qualifier are checked.
- DKIM keys: Selectors for approved platforms are present, valid, sufficiently strong, and tied to known senders.
- Domain match: SPF or DKIM must pass for a domain that aligns with the visible From domain.
- Mail routing: Forwarding, relays, scanners, mailing lists, and shared outbound services are documented.
A quick validation pass catches obvious record errors before the MSP spends time on source investigation. When aggregate reports go to an external domain, confirm the required RFC 9990 authorization record and verify that reports are arriving. Use a focused DNS check when the client only needs record validation, then move into aggregate reporting for traffic evidence.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Risk scoring
A readiness score should translate technical findings into a decision the client can act on. Score by domain, not by client, because one client can have a clean primary domain and several risky secondary domains. This helps the MSP move safe domains first while remediation continues elsewhere.
DMARC enforcement readiness
An evidence-based model for deciding whether a domain can move beyond monitoring.
Ready
Approved sources pass
Every approved business-critical source passes and residual failures are classified.
Fix first
Open failures
Known legitimate sources still fail authentication or alignment.
Not ready
Material risk
Ownership, routing, or delivery impact remains unresolved.
Unknown
Insufficient data
Reports do not cover a complete sending cycle.
Treat the aggregate pass rate as supporting evidence, not the approval gate. Spoofed volume can distort the percentage, while a low-volume payroll or renewal system can be business-critical. A domain with strong authentication but weak ownership also needs caution because nobody can approve or validate changes when a failure appears.
Do not skip traffic evidence
Moving straight to reject because the DNS record looks valid can block legitimate systems that were never inventoried. The readiness assessment should prove what is sending before policy changes.
For deeper source cleanup, the next service step is a sender audit. That is where the MSP turns readiness findings into exact fixes for each platform, selector, include, and relay.
Policy staging and rollback
The assessment should define the change sequence, acceptance gate, observation period, and rollback trigger for each domain. RFC 9989 makes the older pct tag historic and defines t=y for testing an enforcement policy. Older receivers can ignore an unfamiliar t tag, so treat test mode as an extra signal, not the only protection against disruption.
- Complete the baseline: Collect reports across a complete sending cycle and classify every material source.
- Set the policy path: Document the planned movement through monitoring, quarantine, and reject, with a client approval at each gate.
- Check inheritance: Record the organizational-domain policy, explicit subdomain records, sp policy, and np policy for non-existent subdomains.
- Prepare rollback: Save the previous record, name the decision owner, pre-approve the revert, and account for the current DNS TTL.
Use business evidence, not elapsed days
A fixed two-week window is too short when a client sends payroll, invoices, renewals, or seasonal campaigns less often. Advance policy only after the evidence covers the client's full sending cycle and every critical source has an owner.
Operational handoff
The final assessment should be useful to account managers, service desk staff, engineers, and the client sponsor. Separate the handoff into artifacts because each group needs a different level of detail, and the MSP needs a repeatable service process.
|
|
|
|---|---|---|
Domain list | Defines scope and policy status. | MSP engineer |
Sender list | Shows approved and unknown sources. | Client sponsor |
Risk score | Ranks domains for rollout order. | Service lead |
Fix backlog | Turns gaps into tickets. | Technical team |
Rollout plan | Sets policy gates, change windows, and rollback triggers. | MSP and client |
Minimum artifacts for an MSP DMARC readiness handoff.
The handoff should also define how the MSP will handle alerts, exceptions, and monthly client reporting. This is especially important when DMARC is packaged inside a broader email security or compliance service, because stakeholders need progress without having to read raw XML reports.
- Alert path: Who receives DMARC failures, SPF lookup warnings, and blocklist or blacklist alerts.
- Ticket rules: Which findings become tickets and which are tracked in a scheduled review.
- Escalation: Which client contacts approve DNS, vendor, and policy changes.
- Evidence: What screenshots, reports, redacted headers, and DNS exports are kept for audit history.
How Suped fits MSP delivery
Suped's product supports the work that follows a readiness assessment: operating DMARC across multiple clients without maintaining a separate spreadsheet for every domain. MSP teams can use multi-tenant views, automated issue detection, guided fixes, real-time alerts, and client-ready reports to run the recurring service.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
The readiness workflow maps into Suped: add client organizations, monitor domains, review authenticated and failing sources, resolve issues with tailored steps, and report progress. The platform brings DMARC monitoring, Hosted DMARC, and Hosted SPF into one operational view, which helps MSPs move clients through policy staging without needing DNS access for every small update.
Spreadsheet delivery
- Manual review: Engineers reconcile DNS checks, report files, and tickets by hand.
- Slow alerts: Failures are found during scheduled review instead of near the event.
- Weak scale: Each new client adds more recurring operational work.
Suped delivery
- Central view: MSPs manage multiple client organizations and domains in one place.
- Actionable fixes: Issues include practical steps instead of raw authentication data only.
- Client reporting: Reports turn authentication progress into a client-facing outcome.
MSP service fit
Suped supports a recurring workflow for readiness checks, ongoing monitoring, hosted record management, SPF flattening, blocklist monitoring, and client reports. The assessment creates the baseline, then Suped keeps the evidence, fixes, alerts, and reporting in the same service process.
What good readiness looks like
A good DMARC readiness assessment ends with a clear decision for each domain. The client should know what is safe now, what needs fixing, what can be retired, and what the MSP will manage on an ongoing basis.
- Ready now: The domain has known senders, aligned authentication, reporting, confirmed owners, and a rollback plan.
- Ready after fixes: The domain has real traffic but needs SPF, DKIM, alignment, or routing cleanup.
- Not ready yet: The domain has unknown senders, missing reports, incomplete sending-cycle coverage, or weak ownership.
- Retire or protect: The domain should stop sending or move to a strict reject policy.
For MSP owners and operators, the practical value is repeatability. If every assessment captures the same facts, scores domains by the same evidence, and turns findings into tickets and reports, DMARC becomes a managed service instead of a one-off project.
