What MSPs should include in a DMARC readiness assessment

Published 19 Jun 2026

Updated 24 Oct 2026

11 min read

Summarize with

MSP DMARC readiness assessment checklist covering domains, senders, DNS, risk, and rollout.

Updated on 24 Oct 2026: We clarified DMARC test mode and added reporting platform checks to the MSP readiness assessment.

A DMARC readiness assessment for an MSP client should cover domain scope, sender inventory, authentication, reporting, ownership, and enforcement planning. It should be a service delivery artifact 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.

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 DMARC alignment to the visible From domain, all business-critical 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.

Domain scope and DNS ownership

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 need a policy decision after checking for legitimate mail on the domain and its subdomains.

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.

Sender class	Examples	Readiness check
Primary mail	Microsoft 365, Google Workspace	SPF or DKIM passes with DMARC alignment for normal employee mail.
Marketing	Campaign and newsletter systems	Sample messages pass DKIM with DMARC alignment, 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.

SPF, DKIM, and DMARC checks

The DNS section should document the current DMARC, SPF, and DKIM state for every in-scope domain. Include the exact record, its parsed meaning, SPF lookup count, and the operational fix when a record is risky. Use delivered-message headers and aggregate reports to establish authentication and DMARC alignment; DNS records alone do not prove either. Publish the monitoring example as a TXT record at _dmarc.example.com and replace the example reporting mailbox with the client's reporting destination.

Starter DMARC record for monitoringTXT

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;

Illustrative SPF record with two includesTXT

v=spf1 include:_spf.example.net include:send.example.com -all

DMARC record: Validate a single DMARC policy record, its aggregate-report address, alignment modes, test mode, and subdomain controls. Flag historic rf and ri tags rather than relying on them.
SPF record: Check for one SPF record, broad includes, and the final qualifier. Count DNS-querying terms across nested includes and redirects against the limit of 10; exceeding it returns permerror.
DKIM keys: Selectors for approved platforms must resolve to valid keys. Check key strength and verify successful signing on sample messages.
Domain match: Compare the SPF MAIL FROM (Return-Path) domain and DKIM d= domain with the visible From domain. DMARC needs one successful method with domain alignment: a shared organizational domain in relaxed mode, or an exact domain match in strict mode.
Mail routing: Document forwarding, relays, scanners, mailing lists, and shared outbound services. Test whether DKIM survives forwarding, where SPF commonly fails.

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 authorization required by RFC 9990 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

Reporting platform readiness

Check the reporting workflow once at the MSP level, then confirm it for each client. Under RFC 9990, aggregate reports are XML, usually GZIP-compressed. Test ingestion with live reports before relying on a dashboard for enforcement decisions.

Parser compatibility: Confirm support for legacy and RFC 9990 reports, preserving authentication details separately from DMARC alignment results.
Coverage checks: Record reporting receivers, report date ranges, and last receipt times. Investigate ingestion errors and missing reports before treating silence as zero traffic.
Client separation: Verify that domain mapping and access permissions keep each client's reports in the correct organization.
Data handling: Document report retention, permitted exports, and who can access redacted message samples.

Aggregate reports are periodic and do not cover every receiving system; use message headers and mail logs during active incidents. Message-specific failure reports under RFC 9991 are optional and can expose message content or personal data. Request them only for an approved diagnostic need.

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 DMARC 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 pct historic, so receivers following it ignore percentage-based staging. With t=y, quarantine requests none and reject requests quarantine for failing messages. Older receivers can ignore t=y and apply the published policy, so approve the full policy's delivery impact before testing.

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. DNS rollback does not instantly clear receiver caches or recover messages already rejected.

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.

Artifact	Purpose	Owner
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 prioritized tickets with owners, due dates, and acceptance evidence.	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. MSP teams can use multi-tenant views, automated issue detection, guided fixes, alerts, and client 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. After initial DNS delegation, supported DMARC and SPF changes can be managed there; DKIM and other DNS changes still need the appropriate DNS owner.

Spreadsheet delivery

Manual review: Engineers reconcile DNS checks, report files, and tickets by hand.
Reporting delay: Aggregate reports arrive periodically, so active incidents need message headers and mail logs.
Recurring work: 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 for investigating and fixing authentication failures.
Client reporting: Reports turn authentication progress into a client-facing outcome.

MSP service fit

Suped supports recurring readiness reviews with client-specific monitoring, issue guidance, and reports. Keep the approved sender inventory and change decisions linked to the assessment baseline.

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.

Frequently asked questions

For a small client with one primary domain and known senders, the initial DNS and ownership review can be completed quickly. Enforcement readiness takes as long as the client's sending cycle because monthly billing, payroll, renewal, or seasonal mail must appear in the evidence before policy changes.

Yes. Confirm the domain's sending role and check subdomains before applying p=reject and v=spf1 -all where no legitimate mail originates. This reduces spoofing of the protected domain; unrelated lookalike domains need separate controls.

Unknown high-volume senders, failing business-critical mail, missing authentication with DMARC alignment for approved platforms, weak DNS ownership, incomplete subdomain coverage, or reports that miss a complete sending cycle should stop a move to reject until the MSP has evidence and an approved fix plan.

An MSP can complete discovery without DNS access and review reports if reporting already exists. Starting reporting or remediation needs DNS access or a reliable client-side change process. Hosted record management reduces later changes after initial delegation.

Inventory every subdomain that sends mail or has its own DMARC record. Then document the organizational-domain policy, explicit overrides, the sp policy for existing subdomains, and the np policy for non-existent subdomains before changing enforcement.

Suped turns the readiness baseline into ongoing MSP delivery. It monitors DMARC, SPF, DKIM, blocklist and blacklist signals, then gives the MSP issues, fix steps, alerts, and client reporting across multiple organizations.