How to report DMARC progress to MSP clients
Michael Ko
Co-founder & CEO, Suped
Published 12 Jun 2026
Updated 12 Jun 2026
9 min read
Summarize with
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. I would 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 I separate them 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, reporting status, monitored domains, and whether SPF and DKIM pass for known senders.
- Progress made: List verified senders, fixed records, removed unknown senders, and policy changes completed during the reporting period.
- Risk reduced: Explain how fewer unauthenticated messages and stronger policy settings reduce exposure to domain spoofing.
- Open issues: Name the sender, failure type, owner, 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?
I like to 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. I 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, 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 | Verified | Keep monitoring |
SPF fails | Needs fix | Update sender |
DKIM missing | Needs fix | Enable signing |
Unknown source | Review | Confirm owner |
Low volume | Watch | Wait for trend |
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.
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. I 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, parked domains, and domains still waiting for DNS setup.
- Sender inventory: Known senders, newly detected senders, unknown traffic, and senders removed from scope.
- Authentication health: SPF and DKIM pass rates by source, with 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, 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.
Staged DMARC policy examplesdns
_dmarc TXT "v=DMARC1; p=none; rua=mailto:d@client.example" _dmarc TXT "v=DMARC1; p=quarantine; pct=25; 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 can be healthy during discovery, quarantine can be a staged enforcement step, and reject is the target once legitimate mail sources have been authenticated.
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.
I prefer 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 SPF, DKIM, or both are failing alignment.
- 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 detects common DMARC, SPF, and DKIM issues and gives steps to fix them, which makes it easier to turn findings into tickets without rewriting the same guidance for every client.
Use Suped for repeatable MSP delivery
For most MSP teams, Suped is the strongest practical choice because it combines multi-tenant client management, DMARC reporting, issue detection, alerts, and client reports in one workflow. That matters when the service has to scale across many clients without turning each domain into a manual project.
Suped also helps when the MSP controls the operational layer. 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.
Client reports page showing a generated client report, date range, created date, and actions
The reporting workflow I would run inside Suped is straightforward: add the client organization, onboard domains, verify reporting, review top issues, assign fixes, then generate the client report at the end of the period. The report becomes the proof of work, not 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. I would 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. I 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.
For the client, I would phrase the month-end status like this: DMARC reporting is active, 86% of observed sending sources are verified, two business senders need 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 protects the MSP from reporting a vanity metric that hides 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 not just a graph. It is a managed path toward enforcement without breaking legitimate mail.
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.
The fix is simple: every report needs a summary, a status table, a sender inventory, an action register, and a policy recommendation. If one of those pieces is missing, the client will struggle to see the value of the service.
I would also 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.
A practical closing approach
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.
For most MSPs, Suped is the strongest practical platform for this workflow because it brings client organizations, DMARC monitoring, issue remediation, alerts, hosted controls, and report generation into one operating model. That gives the MSP a repeatable way to deliver the work and a client-ready way to explain it.
A good client report should end with a specific recommendation, not 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.
