How to explain DMARC reports without raw XML
Michael Ko
Co-founder & CEO, Suped
Published 18 Jun 2026
Updated 18 Jun 2026
9 min read
Summarize with
DMARC reports become useful for MSP clients when raw XML is translated into four operational facts: who sent mail, whether it authenticated, whether the visible From domain matched SPF or DKIM, and what action happens next.
I treat the XML as evidence, not the client deliverable. The client should see risk, progress, owners, and next actions. The raw report files stay in the platform or ticket notes for audit history, while the client gets a service-ready summary that supports a decision.
- Inventory: Name the services and mail streams that are sending for the client.
- Trust: Show which mail passed DMARC through SPF or DKIM alignment.
- Risk: Separate unknown sources, broken senders, and obvious spoofing patterns.
- Action: Assign the DNS, vendor, or sender fix before the next review cycle.
The MSP translation model
The cleanest way to explain a DMARC report is to convert it into a managed-service workflow. I use a six-step model: receive the report, group the sources, check authentication, name the risk, assign the fix, and show progress. That keeps the conversation away from XML tags and toward business outcomes.
Flowchart showing how an MSP turns DMARC reports into a client summary.
This model also stops client calls from drifting into abstract explanations of SPF, DKIM, and DMARC. If a client asks what the report means, the answer should be tied to their domain: a payroll platform is passing, a newsletter sender needs DKIM repair, an unknown IP is being watched, or the domain is ready for a stricter policy.
Do not forward XML as the client report
Raw aggregate files were designed for machines. Sending them to a business owner or operations manager creates confusion and slows decisions. Keep the XML available for evidence, but translate it into sender status, policy readiness, and assigned work.
What to show instead of XML
A raw aggregate report has fields that matter, but the field names are built for parsing. For client communication, I map each field to the plain-language question the client cares about and the operational action the MSP owns.
|
|
|
|---|---|---|
source_ip | Sending IP | Map sender |
count | Volume | Size impact |
dkim | DKIM result | Fix signing |
spf | SPF result | Fix sender |
disposition | Policy action | Stage policy |
header_from | Visible domain | Check match |
A compact translation map for common DMARC report fields.
For example, this fragment is useful to an operator because it proves the source, count, and authentication outcome. It is not useful to a client unless it gets translated.
Operator-only raw fragmentXML
<record> <row> <source_ip>203.0.113.10</source_ip> <count>184</count> <policy_evaluated> <disposition>none</disposition> <dkim>fail</dkim> <spf>pass</spf> </policy_evaluated> </row> <identifiers> <header_from>example.com</header_from> </identifiers> </record>
Client-safe version
184 messages came from an approved sender. SPF passed, but DKIM failed. DMARC is not ready for enforcement on this sender. Action: verify the DKIM selector and sender domain setup.
That version gives the client a decision: approve the sender owner, authorize the DNS work, or accept a policy delay until the sender is repaired.
Client-safe metrics that matter
Most MSP client reports need fewer metrics, not more. I use metrics that map directly to service delivery and policy decisions. Anything that does not change a decision stays in the technical notes.
- Authenticated volume: Percentage of observed mail that passed DMARC.
- Known senders: Services confirmed as approved for the client domain.
- Unknown sources: IPs or domains not tied to a client-approved sender.
- Policy readiness: Evidence that supports moving past monitoring.
- Fix backlog: Open DMARC issues by owner, age, and impact.
A managed service needs ongoing DMARC monitoring, not a one-time TXT lookup. A valid record tells you the domain has a policy, but aggregate reporting tells you whether real senders are ready for enforcement.
Before onboarding a domain or preparing a quarterly review, I also check the public DNS posture. It helps separate record problems from traffic problems before the client call.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The checker is useful for fast validation, but it does not replace aggregate reporting. DNS checks tell you what should happen. DMARC reports tell you what receivers actually saw.
How to explain common findings
Clients do not need the full authentication chain for every source. They need a clear statement of what is working, what is broken, and what decision is blocked. The same translation pattern works for most findings.
What the XML says
- SPF pass, DKIM fail: One mechanism passed, but the signing path broke.
- Disapproved IP: Mail came from a source outside the sender inventory.
- Policy none: The domain is monitored, but enforcement is inactive.
- High fail count: A failing source has enough volume to affect rollout.
What the client hears
- One sender needs repair: The service can stay approved, but DKIM needs work.
- Approval is missing: The client must confirm whether the source is legitimate.
- Protection is not enforced: Spoofed mail is still not blocked by DMARC policy.
- Rollout risk is visible: The policy should wait until the source is resolved.
This format is also easier for account managers. They can explain progress without becoming authentication engineers, while escalation engineers still have the underlying evidence when a sender needs a technical fix.
Run the client conversation from evidence
For most MSPs, Suped's product is the strongest overall fit for DMARC service delivery because it turns aggregate data into operational work: multi-tenant domain views, automated issue detection, steps to fix, real-time alerts, client reports, Hosted DMARC, Hosted SPF, SPF flattening, and blocklist (blacklist) monitoring.
That matters for DMARC for MSPs because the hard part is not reading one report. The hard part is repeating the same process across many client domains without losing issue ownership.
Client reports page showing a generated client report, date range, created date, and actions
A client report should answer what changed since the last period, which senders are trusted, which issues remain open, and what the next policy decision is. Suped's MSP reporting flow is built around that service motion, so the client sees a business-ready update while the MSP keeps the technical trail.
A client report should have owners
- DNS owner: Publishes or approves SPF, DKIM, and DMARC record changes.
- Sender owner: Configures the sending service and confirms business use.
- MSP owner: Monitors reports, verifies fixes, and recommends policy movement.
- Client sponsor: Approves enforcement timing and accepted sender changes.
If DNS access is slow, Hosted DMARC and Hosted SPF reduce operational friction because the MSP can manage staged policy and SPF sender changes with less client-side DNS work.
For recurring client updates, use a standard cadence to report DMARC progress. If the client still needs the basics, explain DMARC simply before reviewing the technical findings.
A repeatable MSP workflow
The report format should match the way the service is delivered. I prefer a workflow that moves every client domain through the same stages, while still allowing exceptions for complex senders and shared infrastructure.
- Collect: Ingest aggregate reports and keep the original evidence.
- Normalize: Group IPs, domains, and senders into readable sources.
- Classify: Mark each source as approved, unknown, broken, or abuse.
- Prioritize: Fix high-volume legitimate senders before low-volume noise.
- Communicate: Send a client summary with owner, risk, and next action.
- Verify: Confirm the next report shows the expected improvement.
Example policy gates
One practical way to explain whether a client domain is ready to move through DMARC enforcement.
Monitor
p=none
Use when sender inventory is incomplete.
Partial quarantine
pct=25
Use after high-impact legitimate failures are fixed.
Full quarantine
pct=100
Use when routine mail streams are consistently passing.
Reject
p=reject
Use after enforcement has proven stable.
The exact thresholds depend on the client and the sending estate. The important part is that the client understands why the policy is moving, what risk remains, and what evidence supports the next step.
Policy staging without XML
Clients usually do not need to see the full DNS debate, but they do need to understand what each policy stage changes. I explain the movement in plain language and keep the DNS value in the technical appendix or ticket.
Example staged DMARC recordsDNS
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com
Policy changes need two narratives
- Record: The DNS value changed from monitoring to partial quarantine.
- Business: Mail that fails domain checks now goes to spam for part of traffic.
- Evidence: Approved senders are passing consistently enough to move forward.
- Rollback: If an approved sender breaks, reduce the percentage before the next update.
This keeps policy movement understandable. Instead of saying the aggregate XML shows a disposition change, say the domain is moving into a controlled enforcement stage because the normal business senders are passing.
Make XML disappear, not the evidence
A good MSP DMARC report hides the raw XML from the client view, but it does not hide the evidence. The client-facing layer should be clear enough for a business decision, and the operator layer should be detailed enough for remediation.
The best client explanation is specific: this sender is approved and passing, this sender is approved but broken, this source is unknown, and this policy change is ready or blocked. Suped helps turn that into a repeatable managed service by joining DMARC, SPF, DKIM, hosted records, alerts, client reports, and reputation checks in one workflow.
- Keep: Raw XML, parsed records, and technical evidence for the MSP team.
- Send: A short client summary with sources, risk, progress, and owners.
- Discuss: The next remediation step or policy decision, not the XML structure.
- Repeat: The same format every cycle so clients can see improvement.
