How to report DMARC progress to MSP clients
Updated on 14 Aug 2026: We updated this guide for current DMARC policy staging, comparable client metrics, clearer action ownership, and repeatable MSP reporting.
DMARC progress reporting for MSP clients should show risk reduced, legitimate senders verified, policy movement, and the next actions needed from either the MSP or the client. Do not send raw aggregate XML, a screenshot full of authentication rows, or a percentage with no context. The client needs to know what changed, why it matters, and what decision comes next.
For MSP teams building this into a recurring service, MSP DMARC reporting has to be repeatable. A good report format works for a five-domain client and still works when the client has dozens of brands, cloud apps, and business units sending mail.
The best client report has two layers. The first layer is executive: status, risk, trend, and decisions. The second layer is technical: sources, authentication failures, DNS changes, and policy staging. Mixing those layers into one dense report creates confusion, so keep them separate and keep the executive view short.
What clients need to see
A client does not need every DMARC detail every month. They need enough evidence to trust that the service is moving forward. The report should connect technical work to plain operational outcomes, especially when the client has to approve DNS changes or chase an internal application owner.
- Current state: Show the active DMARC policy for each domain and subdomain, reporting status, monitored coverage, and aligned SPF or DKIM results for known senders.
- Progress made: List verified senders, fixed records, removed unknown senders, and policy changes completed during the reporting period.
- Risk reduced: Show how much legitimate volume passes DMARC and which domains now have an enforcement policy, without counting unauthenticated attack traffic as a remediation failure.
- Open issues: Name the sender, failure type, owner, due date, and next fix instead of saying that authentication needs improvement.
- Client decision: State whether the client needs to approve a policy move, confirm a vendor, or retire an old sending source.
Client-friendly reporting rule
Every metric should answer one client question: are we safer than last month, and what has to happen before the next policy step?
Keep the first page close to an account review note. It should fit in a client success meeting without forcing the client to understand DNS syntax. The technical appendix can carry the details for IT contacts who want the evidence.
Map DMARC data to business progress
DMARC data becomes useful to a client when each source has a status. Group sources into verified, needs fix, and unknown. That simple split keeps the report readable and gives the client a clear sense of movement.
Authentication progress by source status
Use status groups to show movement instead of raw DMARC row counts.
Verified
Needs fix
Unknown
Good DMARC monitoring should turn aggregate reports into sender groups, aligned authentication outcomes, and issue lists. The MSP then adds client context: who owns the sender, whether it is still approved, and whether the domain is ready for a stricter policy.
|
|
|
|---|---|---|
Known sender passes DMARC | Verified | Keep monitoring |
No aligned identifier | Needs fix | Configure aligned DKIM or SPF |
Unknown source | Review | Confirm owner |
Dormant approved sender | Watch | Extend discovery window |
Policy or DNS regression | Urgent | Restore or approve change |
Compact client-facing DMARC status labels.
The table should stay compact. Long explanations belong in the technical notes or remediation ticket, not the executive report. Clients scan labels faster than they scan raw authentication fields.
Make month-to-month metrics comparable
A trend is useful only when each reporting period uses the same rules. Keep the reporting window, domain scope, sender classification method, and denominator consistent. Compare message-weighted DMARC pass rate separately from verified source coverage because one high-volume campaign can move the first metric without changing the second.
- Reporting window: Use complete calendar periods, compare equivalent numbers of days, and label partial periods.
- Domain scope: Record domains and subdomains added or removed, with parked and non-sending domains reported separately.
- Metric denominator: Label whether a percentage uses message volume, known senders, or all observed sources.
- Change notes: Annotate campaigns, sender migrations, DNS edits, policy changes, and gaps in received reports.
Do not turn missing data into progress
Aggregate reports come from participating receivers and can arrive late. A lower failure count does not prove improvement when report volume or receiver coverage also fell, so show reporting completeness beside the trend.
A monthly report structure MSPs can reuse
A repeatable report structure reduces delivery time and makes DMARC easier to sell as an ongoing managed service. Use the same sections every month, then change the evidence and actions based on the client.
- Executive summary: One paragraph covering current policy, major progress, open risk, and the next decision.
- Domain coverage: A list of monitored domains and subdomains, parked domains, reporting gaps, and domains still waiting for DNS setup.
- Sender inventory: Known senders, newly detected senders, unknown traffic, and senders removed from scope.
- Authentication health: Overall DMARC pass rate and aligned SPF or DKIM outcomes by source, with important exceptions named clearly.
- Policy plan: The proposed next policy step, the reason for it, and the condition that has to be met first.
- Action register: Open tasks with owner, priority, due date, age, status, and expected client input.
Do not rush policy enforcement
Moving a client to reject is only progress when legitimate senders have been verified and the remaining failures are understood. A stricter policy with unresolved business mail creates support work and damages trust.
Current DMARC policy staging examplesdns
_dmarc TXT "v=DMARC1; p=none; rua=mailto:d@client.example" _dmarc TXT "v=DMARC1; p=quarantine; t=y; rua=mailto:d@client.example" _dmarc TXT "v=DMARC1; p=reject; rua=mailto:d@client.example"
The report should explain why the client is at the current stage. For example, p=none is appropriate during discovery, p=quarantine with t=y requests testing one policy level lower, and p=reject is the target once legitimate mail sources have been authenticated. RFC 9989 removed pct because receivers did not apply percentage values consistently.
Create client report dialog with organization, date range, logo, and language options
Split executive reporting and remediation work
MSPs often lose reporting clarity by putting every detail into one file. The client sponsor wants trend and risk. The technical contact wants specific DNS and vendor fixes. Both views matter, but they should not fight for space.
Executive report
This is the version for QBRs, account reviews, and service updates. Keep it short and decision-focused.
- Audience: Client owner, security lead, and operations manager.
- Content: Policy status, trend, major risks, and approval items.
- Length: One to two pages with a short appendix if needed.
Remediation report
This is the version for the MSP engineer, DNS owner, or application owner doing the fix.
- Audience: Technical contact, vendor owner, and service desk lead.
- Content: Source, domain, failure type, DNS task, and verification step.
- Length: As long as needed, but grouped by owner and priority.
This split also makes renewals cleaner. The executive report proves the managed service is active. The remediation report proves the engineering team has a queue and is not just watching charts.
Show actions, not just percentages
Percentages are useful only when they lead to action. A report that says 92% of mail passed DMARC is incomplete if the failing 8% includes payroll, invoices, or a critical line-of-business system.
Use an issue format that can be copied straight into a ticket. That keeps the MSP delivery loop tight: identify, assign, fix, verify, then report the status in the next client update.
Use owner-ready issue wording
- Source: Name the sending service or call it unknown if ownership is not confirmed.
- Failure: State whether aligned SPF, aligned DKIM, or both paths are missing, and whether the message failed DMARC overall.
- Impact: Explain whether the issue blocks a quarantine or reject policy move.
- Fix: Give the exact DNS, vendor, or application step required.
- Proof: Show how the MSP will confirm the fix in the next DMARC data cycle.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
This is where automation helps, but the MSP still owns the client explanation. Suped, our DMARC and email authentication platform, detects common DMARC, SPF, and DKIM issues and provides remediation steps. This makes it easier to turn findings into tickets without rewriting the same guidance for every client.
Use Suped for repeatable MSP delivery
Suped's MSP workspace combines multi-tenant client management, DMARC reporting, issue detection, alerts, and client reports in one workflow. MSP teams can use that workflow to apply the same reporting method across clients while keeping each organization's domains and actions separate.
Suped also supports the operational changes behind the report. Hosted DMARC can simplify policy staging, Hosted SPF can reduce DNS change friction, SPF flattening helps with lookup limits, and Hosted MTA-STS can enforce TLS without asking the client to host policy files. Record each change in the action register so the next client report explains what moved.
Client reports page showing a generated client report, date range, created date, and actions
A repeatable Suped workflow is to add the client organization, onboard domains, verify report receipt, review top issues, assign fixes, and generate the client report at the end of the period. The report becomes the proof of work instead of a separate project after the work is done.
Before kickoff or renewal, a domain health checker style review is useful for spotting DMARC, SPF, DKIM, and DNS gaps. It gives the MSP a concrete baseline before service delivery begins.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped also brings blocklist (blacklist) monitoring and deliverability signals into the same operating view. Keep those signals separate from the DMARC progress score, but include them as context when a client asks why mail performance changed after a DNS or policy update.
What good progress looks like
Progress is not only a higher pass rate. A client can have a high pass rate and still be stuck at p=none because one important sender is unsigned. Report progress using operating thresholds, then add context for the business systems behind the numbers.
Suggested DMARC reporting thresholds
Use thresholds as operating guidance, then validate sender importance before policy moves.
Discovery
p=none
Reporting is active and sources are being identified.
Controlled enforcement
p=quarantine
Most legitimate senders pass and failures are owned.
Full enforcement
p=reject
Legitimate sources are verified and remaining failures are expected.
Blocked progress
Hold
Unknown or business-critical failures remain unresolved.
A month-end status can read like this: DMARC reporting is active, 86% of observed sending sources are verified, two business senders need aligned DKIM configuration, and the domain should stay at p=none until those fixes are confirmed.
Flowchart showing the DMARC reporting process from report collection to client summary.
That wording gives the client a clear reason for the recommendation. It also prevents a vanity metric from hiding a delivery risk.
Common reporting mistakes
The biggest reporting mistakes happen when the MSP reports technical data without translating it into a client decision. DMARC progress is a managed path toward enforcement without breaking legitimate mail, not a graph by itself.
Mistakes that weaken client trust
- Raw data: Sending aggregate records without source grouping or business context.
- No owner: Listing failures without naming who has to fix or approve them.
- False progress: Treating p=reject as success when legitimate senders are still failing.
- No baseline: Starting a managed service without recording the initial domain state.
- Hidden blockers: Waiting until the QBR to reveal a vendor or DNS dependency.
Every report needs a summary, status table, sender inventory, action register, and policy recommendation. If one of those pieces is missing, the client will struggle to see the value of the service.
Avoid making price the center of the report. Pricing belongs in the commercial conversation. The report should prove delivery quality, show risk movement, and identify the work that keeps the domain ready for enforcement.
End with a client decision
The best DMARC progress report for an MSP client is a plain-language service update backed by technical evidence. It should say what was monitored, what improved, what is still failing, who owns each fix, and whether the domain is ready for a policy move.
Suped's client organizations, DMARC monitoring, issue remediation, alerts, and report generation support this operating model. The MSP can manage the work and produce a client-ready explanation within the same Suped workflow.
End with a specific recommendation instead of a generic health score. Keep the message concrete: approve this policy change, fix this sender, confirm this vendor, or hold enforcement until this risk is removed.
