How to build a monthly DMARC report for MSP clients
A monthly DMARC report for an MSP client should show what mail was sent, which sources passed authentication, what changed during the month, which risks remain, and who owns each next action. I keep the client-facing summary short, then attach enough technical evidence for the client's IT contact to verify the findings. Raw XML belongs in the reporting system, not in the main report.
The report also needs continuity. A client should be able to compare this month with the prior month without learning a new format. That means using the same reporting window, metric definitions, sender categories, risk labels, and action table every time. The result becomes part of an ongoing DMARC for MSPs service rather than a one-off export.
What a monthly DMARC report must answer
I build the report around client decisions, not protocol fields. An owner wants to know whether the domain has less exposure to spoofing. An IT lead wants to know which sender needs work. An account manager needs a clear explanation of completed work, blocked dependencies, client decisions, and next month's priorities. A security contact needs evidence for policy approval. One report can meet those needs when every metric leads to a decision or action.
The reporting window should use complete aggregate data. I close the month, allow a short buffer for receivers that submit reports later, and record the exact start and end dates. I also note material coverage limits, such as a newly onboarded domain, missing reports, partial DNS visibility, or a sender that was active for only part of the month.
- Coverage: List every monitored domain, the reporting period, received data, and any coverage gaps.
- Volume: Show total messages and the change from the previous complete period.
- Authentication: Report DMARC pass rate and separate SPF and DKIM results where they explain a failure.
- Sources: Separate authorized, unknown, confirmed unauthorized, and likely forwarding sources.
- Actions: Name the owner, due date, status, evidence, and business effect for each item.
Five parts of a monthly DMARC report: coverage, volume, authentication, sources, and actions.
Use a repeatable monthly workflow
A reliable report starts with a fixed operating cadence. I assign one reporting owner for each client and use the same cutoff, review, approval, and delivery dates each month. This prevents a polished document from hiding stale data or unresolved ownership. It also makes staff handover easier because the workflow does not depend on one technician's memory.
I separate data preparation from interpretation. First I confirm coverage and clean the source list. Then I investigate changes, update actions, write the summary, and complete a peer review. This sequence catches common errors, including comparing partial months, treating forwarded mail as a new authorized source, trusting incomplete DNS data, or declaring a sender safe because its name looks familiar.
Monthly production checklist
- Freeze data: Use a complete reporting window and record any missing coverage.
- Classify sources: Confirm each material sender with the client or an existing service record.
- Compare periods: Explain significant changes in volume, pass rate, source status, and policy.
- Update actions: Carry open items forward with owners, evidence, dependencies, and dates.
- Review delivery: Check branding, client names, domain scope, period labels, and permissions.
Suped's client report workflow lets an MSP choose the client organization, date range, logo, and report language before creating the report. I still review the selected organization and period before generation because a correct template cannot compensate for the wrong tenant or incomplete dates.
Create client report dialog with organization, date range, logo, and language options
The generated document is the delivery artifact, while the MSP ticket or service record remains the source of truth for ownership. I store the final report, approval note, meeting notes, and linked remediation tickets under the same monthly reference. If the client challenges a number later, the team can reconstruct the reporting window and the interpretation used at delivery.
For a larger team, I add this sequence to the ongoing MSP DMARC runbook. The runbook should define escalation thresholds, report approvers, storage location, and the response path for an unknown high-volume sender.
Collect evidence before writing
Start with aggregate DMARC data, current DNS records, prior-period metrics, sender inventory, and open remediation work. I reconcile high-volume sources against the client's approved services before assigning a status. A recognizable provider name is a clue, not authorization. The client or an existing system record must confirm that the sender belongs to the domain.
Before I publish the policy snapshot, I validate the live record with a focused DMARC checker. This catches syntax errors, duplicate records, invalid tag values, and reporting destinations that do not match the change ticket. The report should describe the live state observed during the reporting window, not the intended configuration in a project plan.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
DMARC pass rate needs context. A message passes DMARC when either SPF or DKIM passes and the passing identifier matches the visible From domain under the applicable alignment mode. Report SPF and DKIM separately only when those details explain a failure pattern or a remediation decision. A client executive rarely needs every authentication combination in the summary.
Forwarding can break SPF because the forwarding host becomes the connecting source. DKIM can preserve DMARC authentication when the signature remains valid and uses an aligned domain. I label likely forwarding separately when the data supports that interpretation, and I avoid opening a sender-remediation ticket until the team has checked DKIM results and message paths.
|
|
|
|---|---|---|
Period | Start and end | Defines scope |
Volume | Message count | Shows activity |
DMARC | Pass rate | Tracks health |
Sources | Status groups | Directs review |
Policy | Mode and pct | Shows control |
Actions | Owner and date | Creates follow-up |
Compact evidence fields for each monthly client report.
Turn authentication data into client outcomes
A useful report distinguishes authorized failures from suspicious traffic. An authorized sender that fails DMARC threatens deliverability and blocks enforcement progress. An unknown source needs investigation. A confirmed unauthorized source tests whether the current policy gives the desired receiver instruction. Combining those cases into one failure count produces the wrong conversation.
I prioritize by business effect and volume, then explain the evidence in plain terms. For example, the billing platform sent 18% of client mail without aligned DKIM is more actionable than a generic DKIM failure warning. It identifies the service, scale, problem, and reason the client should approve remediation.
Client-facing summary
- Outcome: State the protection or delivery effect.
- Change: Compare with the prior complete period.
- Decision: Request approval or client input.
- Owner: Name the accountable party and date.
Technical appendix
- Evidence: Include source, affected domain, volume, and authentication path.
- DNS: Record the observed policy and alignment.
- Ticket: Reference the remediation work item.
- Caveat: State coverage or attribution limits.
Every issue should end with a disposition: fix, monitor, investigate, accept, or close. I avoid using 'risk accepted' as a parking status. It needs a named approver, a reason, a review date, and a description of the residual exposure. Unknown sources also stay visible until confirmed, even when their volume falls in the next month.
If source discovery is still incomplete, I keep the domain at its current policy and point the client to the outstanding dependency. A structured sender audit gives the MSP a safer basis for deciding whether enforcement can progress.
Write the executive summary
The first page should make sense without the appendix. I use a compact structure: reporting scope, current protection state, material change, completed work, open risk, and required client decision. Each statement should have supporting evidence elsewhere in the report. If nothing material changed, I say that and identify the monitoring performed.
Percentages need denominators and comparisons need matched periods. Authentication improved is too vague. DMARC pass rate increased from 96.8% to 98.4% across complete monthly periods gives the client a measurable change. I also explain whether a volume shift affected the percentage.
Demo client report summary page showing total emails, authorized delivery, threats blocked, and email volume trend
Suped's report summary shows total email, authorized delivery, blocked threats, and the volume trend in one client-facing view. I use that summary to open the service review, then move to named sources and action ownership. A blocked-threat count should still be described within the limits of aggregate DMARC data and the receiver policy reported.
Keep raw IP lists and repetitive receiver rows out of the executive summary. They can remain available in the platform or appendix for investigation. A client report should compress evidence without hiding uncertainty. When attribution is not confirmed, use 'unknown source under review' instead of naming a vendor based only on an IP owner or reverse DNS result.
Track remediation and DMARC enforcement
Policy progression belongs in the report, but it should never be treated as a monthly quota. I record the policy applied to the organizational domain and relevant subdomains, the percentage tag when used, the date of the last change, the evidence reviewed, and the approval required for the next stage. A move toward quarantine or reject follows verified sender coverage and controlled observation.
For clients with frequent changes, hosted DMARC can support policy staging without asking the client to edit the TXT record for every adjustment. The monthly report still needs the effective policy, change approval, observation result, and rollback condition. Management convenience does not remove change control.
Example policy snapshot for the technical appendixDNS
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com
The action register is the bridge between reporting and service delivery. Each line needs one accountable owner, a target date, current status, dependency, validation method, and client-visible effect. Fix DKIM is not enough. Client application owner will enable aligned DKIM for the billing sender by 18 August; MSP will verify in aggregate data after seven complete days can be managed.
I document the validation window separately from the implementation date. DNS publication confirms that a record changed, while aggregate reports show whether legitimate traffic still authenticates after the change. The monthly report should distinguish those two checks so a newly published control is not described as fully validated before enough complete data arrives.
Do not recommend enforcement from pass rate alone
A high overall pass rate can hide a low-volume business-critical sender that still fails. Check every authorized source, subdomain behavior, recent sender changes, forwarding patterns, and the client's rollback plan before recommending a stricter policy.
Make the report operational
Delivery should create work, not close it. I send the report to the approved recipients, review material findings in the service meeting, convert accepted actions into tracked tickets, and archive the final evidence. The report records what was known at month end. The ticket records subsequent investigation, approval, implementation, and validation.
I also preserve month-to-month definitions. If the source classification changes, the report should explain why. If a client adds domains mid-period, coverage should be separated or clearly qualified. If one month has more receiving data than another, avoid presenting the change as mail growth without checking the underlying report coverage.
|
|
|
|
|---|---|---|---|
Billing DKIM | Client app | In progress | DMARC data |
Unknown source | MSP analyst | Review | Client reply |
Policy change | Client IT | Approval | Change ticket |
Report review | MSP lead | Complete | Approval note |
A compact action register keeps the monthly review accountable.
The monthly meeting should end with confirmed owners and dates. I send the action extract soon after the meeting and update the service record when responsibility changes. This small control prevents the same unresolved source from appearing in several reports with no explanation of what happened between reviews.
For client communication, the reporting document and meeting notes should use the same status terms. A separate guide to reporting DMARC progress helps account managers explain movement without exposing clients to raw XML or unexplained protocol language.
Where Suped fits for MSP delivery
Suped is our DMARC and email authentication platform. For most MSP operations, it is the best overall fit because the multi-tenant dashboard keeps client organizations, monitored domains, authentication results, issues, and client reports inside one operating workflow. The practical benefit is consistency across clients without combining separate exports by hand each month.
The workflow connects DMARC monitoring with automated issue detection, steps to fix, real-time alerts, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, blocklist (blacklist) monitoring, and deliverability insights. Use those capabilities according to the contracted service scope. A monthly DMARC report should not imply that a client receives controls or monitoring that are outside that scope.
A practical Suped reporting workflow
- Switch client: Open the correct organization and confirm monitored domain scope.
- Review health: Check volume, DMARC results, verified sources, unknown sources, and active issues.
- Resolve findings: Use tailored fix steps and attach ownership through the MSP ticket process.
- Create report: Select the complete date range, client identity, MSP logo, and language.
- Approve delivery: Verify claims, record caveats, confirm branding, and deliver with the action register.
Automation reduces assembly work, but the MSP still owns interpretation. Client authorization, business criticality, risk acceptance, and change approval require human confirmation. That division works well: the platform handles repeated collection and presentation, while the service team owns judgement, client communication, change control, and accountable remediation.
The same platform can support a basic monitoring engagement or a broader managed email authentication service. The report should reflect the exact service purchased and clearly separate observed findings, work completed by the MSP, actions assigned to the client, and optional improvements that need approval.
Close the month with accountable next actions
A strong monthly DMARC report gives the client a stable view of coverage, authentication health, source status, policy progress, completed work, and open ownership. Build it on complete data, preserve the definitions used last month, and explain material changes in business terms. Keep technical evidence available without forcing every reader through raw aggregate records.
The final quality check is simple: every risk has evidence, every action has one owner and date, every policy recommendation has a stated basis, and every headline number can be reproduced. That turns monthly reporting into a dependable MSP control and gives the next service review a clear starting point.
