What MSPs should include in a DMARC readiness assessment
Matthew Whittaker
Co-founder & CTO, Suped
Published 19 Jun 2026
Updated 19 Jun 2026
8 min read
Summarize with
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. I treat it as 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. I want to see authentication results, real sending sources, operational owners, and a practical path to policy enforcement.
Flowchart of an MSP DMARC readiness assessment process.
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, and defensive domain has a documented status.
- Traffic visibility: Aggregate reports reveal who is sending and whether authentication passes.
- 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, 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 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. I record domain purpose, DNS owner, mail owner, current DMARC policy, reporting status, 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. I separate confirmed sources from suspected sources because a client conversation can turn guesses into approvals or removals.
|
|
|
|---|---|---|
Primary mail | Microsoft 365, Google Workspace | SPF or DKIM passes 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 tells you source IPs and pass or fail results, but a header sample helps identify a vendor, selector, bounce domain, and the visible From domain faster.
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 catch periodic mail.
DNS evidence
The DNS section should document the current DMARC, SPF, and DKIM state for every in-scope domain. I include the exact record, the parsed meaning, pass or fail status, lookup count, and the operational fix when the record is risky.
Starter DMARC record for monitoringTXT
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1; adkim=s; aspf=s
SPF record with common lookup riskTXT
v=spf1 include:_spf.example.net include:send.example.com -all
- DMARC record: Policy, reporting address, strictness tags, and percentage 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, and tied to known senders.
- Domain match: SPF or DKIM must pass for a domain that matches the visible From domain.
- Mail routing: Forwarding, relays, scanners, and shared outbound services are documented.
A quick validation pass catches obvious record errors before the MSP spends time on source investigation. 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. I 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
A practical scoring model for deciding whether a domain can move beyond monitoring.
Ready
95%+ pass
Known sources pass and owners are confirmed.
Fix first
80-94%
Most mail passes, but key senders still fail.
Not ready
Below 80%
Failures affect material business mail.
Unknown
No data
Reporting is missing or history is too thin.
For enforcement planning, I also check whether the client has business-critical mail that lacks a clear owner. A domain with strong authentication but weak ownership still 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.
Operational handoff
The final assessment should be useful to account managers, service desk staff, engineers, and the client sponsor. I 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 stages and dates. | 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, headers, and DNS exports are kept for audit history.
How Suped fits MSP delivery
Suped's product is built for the part that comes after the readiness assessment: running DMARC across many clients without turning every domain into a manual spreadsheet. For most MSPs, Suped is the best overall fit when the assessment becomes a managed service because it combines multi-tenant views, automated issue detection, guided fixes, real-time alerts, and client-ready reporting.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
The readiness workflow maps cleanly 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 is strongest when the MSP wants one 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 service moving.
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, passing authentication, reporting, and owners.
- Ready after fixes: The domain has real traffic but needs SPF, DKIM, or routing cleanup.
- Not ready yet: The domain has unknown senders, missing reports, or weak ownership.
- Retire or protect: The domain should stop sending or move to a strict reject policy.
For MSP owners and operators, the real value is repeatability. If every assessment captures the same facts, scores domains the same way, and turns findings into tickets and reports, DMARC becomes a managed service instead of a one-off project.
