How to explain DMARC reports without raw XML
Updated on 23 Oct 2026: We added a client report example and clarified DMARC pass rates, reporting limits, and policy decisions.
DMARC aggregate reports become useful for MSP clients when raw XML is translated into four operational facts: which sources used the domain, whether DMARC passed through SPF or DKIM alignment, which senders the client has approved, and what action happens next.
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.
- Authentication: Show which mail passed DMARC through SPF or DKIM alignment.
- Risk: Separate unknown sources, broken senders, and suspected spoofing patterns.
- Action: Assign the DNS, vendor, or sender fix before the next review cycle.
Turn DMARC reports into an MSP client summary
The cleanest way to explain a DMARC report is to convert it into a managed-service workflow. A six-step model works well: 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 focused on business outcomes.
Six-step MSP workflow for translating DMARC aggregate 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, tie the answer to their domain: a payroll platform is passing, a newsletter sender needs DKIM repair, an unknown IP needs investigation, 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, map each field to the plain-language question the client cares about and the operational action the MSP owns. The aggregate report field definitions are specified in RFC 9990.
|
|
|
|---|---|---|
source_ip | Connecting IP | Identify sending service or forwarder |
count | Message volume | Prioritize impact |
policy_evaluated/dkim | Aligned DKIM result | Fix signing |
policy_evaluated/spf | Aligned SPF result | Fix sender path |
auth_results | Underlying SPF and DKIM checks | Compare authenticated domains with the visible From domain |
disposition | Reported DMARC handling | Separate policy handling from inbox delivery |
reason | Receiver exception | Explain override |
date_range | Reporting period | Compare equal windows |
header_from | Visible domain | Check alignment |
policy_published | Policy seen by the receiver | Check propagation and test mode |
report_id | Report identifier | Deduplicate within each reporter and domain |
A compact translation map for common DMARC report fields.
For example, this fragment shows 184 receiver-reported messages under an enforcement policy. It does not prove that the sender is approved or that the messages reached an inbox.
Operator-only raw fragmentXML
<record> <row> <source_ip>203.0.113.10</source_ip> <count>184</count> <policy_evaluated> <disposition>pass</disposition> <dkim>fail</dkim> <spf>pass</spf> </policy_evaluated> </row> <identifiers> <header_from>example.com</header_from> </identifiers> <auth_results> <spf> <domain>example.com</domain> <result>pass</result> </spf> </auth_results> </record>
Client-safe version
184 reported messages used example.com in the visible From address. DMARC passed through SPF alignment. DKIM did not provide an aligned pass. Approval: confirm the source with the client's sender owner. Action: if approved, configure DKIM with the client's domain and verify the result in later reports.
RFC 9990 includes disposition=pass for a DMARC pass under an enforcement policy; older reports also use disposition=none for passing mail. Neither value proves inbox placement. Use the policy_evaluated SPF and DKIM results to determine whether DMARC passed.
That version gives the client a decision: confirm the sender owner, authorize the DKIM work, or accept the documented risk before a stricter policy change.
DMARC metrics to include in client reports
Most MSP client reports need fewer metrics, not more. Use metrics that map directly to service delivery and policy decisions. Anything that does not change a decision stays in the technical notes. Count a message as passing when either SPF or DKIM passes with alignment to the visible From domain; a pass from both still counts once.
- DMARC pass rate: Passed message count divided by total reported message count for the period, expressed as a percentage. Calculate a separate rate for approved senders.
- Known senders: Services confirmed as approved for the client domain, tracked separately from volume.
- Unknown sources: IPs or domains not tied to a client-approved sender.
- Policy readiness: Evidence that supports moving past monitoring or ending a test stage.
- Fix backlog: Open DMARC issues by owner, age, and message impact.
- Reporting coverage: Reporting organizations and time windows included in the summary.
Base policy readiness on each approved sender, not a universal pass-rate threshold. A high overall rate can hide a small payroll sender's failures, while a spoofing spike can lower it without any change to legitimate mail.
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, check the public DNS posture. This separates 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.
A client-ready DMARC report example
Use a short executive summary with the reporting window, authentication results, and a decision. These illustrative figures are a template, not Suped customer data.
Example weekly client summary
Domain: example.com Period: 12-18 October 2026, UTC; 4 reporting organizations Reported volume: 10,000 messages Approved senders: 9,000 messages; 8,910 passed DMARC (99%) Unapproved sources: 1,000 messages failed DMARC; investigation remains open Overall DMARC pass rate: 8,910 / 10,000 = 89.1% Open issue: 90 messages from the approved billing service failed DMARC Action: configure DKIM with example.com; billing owner and MSP engineer; due 30 October Policy decision: keep p=none until the billing fix is verified Next review: the first complete reporting window after the fix
The 89.1% overall rate and 99% approved-sender rate answer different questions. The billing failures need a fix even though approved mail has a high pass rate. Confirm the unapproved sources before describing their failures as spoofing, and keep an absent reporting organization visible as a coverage gap.
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
- Policy-evaluated SPF pass, DKIM fail: DMARC passed through SPF alignment, but DKIM did not provide an aligned pass.
- Unknown IP: Mail came from a source outside the approved sender inventory.
- Policy none: The domain is monitored, but DMARC enforcement is not requested.
- High fail count: Check whether the volume belongs to approved senders or suspected abuse.
What the client hears
- SPF is the current pass path: The service passes DMARC through SPF. DKIM with the client's domain adds another pass path that can survive forwarding when signed content is unchanged.
- Approval is missing: The client must confirm whether the source is legitimate before it is treated as abuse.
- DMARC enforcement is inactive: Receivers still make their own filtering decisions, but the domain does not request quarantine or reject.
- Rollout decision: Resolve failures in legitimate mail before enforcement; investigate suspected abuse separately.
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.
Explain report scope and receiver overrides
A DMARC aggregate report is one receiving organization's summary for a defined reporting period. It is not a complete census of every message the client sent. A client-safe report should state what data was included and separate authentication failure from the receiver's final handling decision. Aggregate reports, also called RUA reports, are requested with the rua tag and typically arrive daily, after the reporting window closes.
- Coverage: Aggregate totals cover only receivers that submitted reports for the period.
- Comparison: Use equal UTC reporting windows and compare the same reporting organizations. Account for late or missing reports and deduplicate by reporting organization and report ID before calling a change a trend.
- Overrides: A reported reason, such as local policy or a trusted forwarder, explains why disposition differed from the published policy.
- Indirect mail: Forwarding commonly breaks SPF, while a valid aligned DKIM signature can survive. Investigate repeated known patterns before labeling them abuse.
- Privacy: Aggregate RUA reports contain grouped counts and authentication identifiers, not message bodies. Per-message failure reports requested with ruf are separate and have limited receiver support.
Do not label every failure as spoofing
A failure is an investigation state. Classify the source against the approved sender inventory, authentication domains, volume history, and receiver override reason before reporting it as impersonation or abuse. Do not add an IP to SPF just because it appears in a report; first confirm the service and its SPF domain.
Use Suped for recurring MSP client reports
Suped's product supports this workflow with multi-tenant domain views, sender classification, issue detection, client reports, and hosted record management. Alerts help the MSP act on newly received report data; they are not live telemetry for every message.
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 client reports support that review while the MSP keeps the underlying report data.
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. Use a workflow that moves every client domain through the same stages, while allowing documented 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: Track sender approval separately from authentication: approved and passing, approved but failing, unknown, or suspected abuse.
- Prioritize: Fix failures in business-critical legitimate mail, including low-volume payroll or billing senders.
- Communicate: Send a client summary with owner, risk, and next action.
- Verify: Confirm the fix in later complete reporting periods after DNS caches refresh, and test the affected mail stream.
Example policy gates
A current way to explain whether a client domain is ready to move through DMARC monitoring, testing, and enforcement.
Monitor
p=none
Use while the sender inventory is incomplete.
Test quarantine
p=quarantine; t=y
Request handling one policy level below quarantine where receiver support for t=y is confirmed.
Enforce quarantine
p=quarantine
Use after routine legitimate mail streams pass consistently.
Test reject
p=reject; t=y
Request quarantine-level handling where receiver support for t=y is confirmed.
Enforce reject
p=reject
Use after the reject test is stable and exceptions are understood.
The time spent at each gate depends on the client and its sending estate. Use complete, representative reporting periods before moving forward, and include routine user mail, seasonal senders, forwarding, and mailing-list behavior in the decision. The t=y gates are optional and require receiver support.
Policy staging without XML
Clients need to understand what each policy stage changes. RFC 9989 made pct historic. Use p=none for monitoring, then request enforcement with p=quarantine or p=reject once approved senders pass consistently. The optional t=y tag asks supporting receivers to handle failures one policy level below the stated policy. Receivers that ignore t can apply the full stated policy, so do not treat it as a percentage rollout or a universal safety control.
Example staged DMARC recordsDNS
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com v=DMARC1; p=reject; t=y; rua=mailto:dmarc-reports@example.com v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com
These are successive alternatives for one TXT record at _dmarc.example.com. Publish only the selected stage, not all five records together.
Explain the policy decision and rollback
- Record: The DNS value changed from monitoring to a quarantine test.
- Business: The t=y tag asks compatible receivers to apply handling one policy level below the stated policy. It is not a percentage sample.
- Evidence: Approved senders are passing consistently enough to move forward.
- Rollback: If an approved sender breaks, return to the previous known-working policy while the issue is fixed. DNS caching delays the effect.
This keeps policy movement understandable. Instead of saying the aggregate XML shows a disposition change, say the domain is moving into a controlled test or enforcement stage because normal business senders are passing.
Keep technical evidence behind client summaries
An effective 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.
Record the sender approval and policy decision alongside the underlying report references so the MSP team can trace each client summary back to its evidence.
- 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.
Frequently asked questions
No, not as the primary report. Keep it as evidence for the MSP team, then send a translated summary with sender status, authentication results, policy readiness, and assigned fixes.
Group the report by sender and explain each source as approved and passing, approved but broken, unknown, or suspected abuse. Then add the next action and owner.
Include enough detail to support a decision. Sender name, volume, pass or fail status, risk, and next action are usually enough. Put XML, IP detail, receiver overrides, and DNS notes in the technical appendix.
An SPF pass in auth_results only authenticates the SPF domain. If that domain lacks alignment with the visible From domain and no DKIM signature supplies an aligned pass, DMARC fails. The policy_evaluated SPF field reports the DMARC result for SPF, including alignment. Relaxed alignment generally permits a shared organizational domain; strict alignment requires an exact domain match.
Do not use pct for a current rollout. RFC 9989 made the tag historic. Monitor with p=none, use t=y with quarantine or reject only after confirming receiver support, and remove t=y when the policy is ready for enforcement. Older receivers can ignore t=y and apply the stated policy.
Suped's product turns DMARC aggregate reports into domain views, sender issues, fix steps, alerts, and client reports. MSP teams keep the raw evidence while clients receive an operational summary.
