MSP guide
DMARC monitoring for MSPs
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed September 8, 2026
DMARC monitoring for MSPs means collecting authentication reports for client domains, identifying changes in sending activity, and turning findings into owned follow-up work. Keep each client's evidence and approvals separate, then use a portfolio view to prioritize investigation.
ChatGPT
Claude
Gemini
Perplexity
GrokWhat evidence belongs in each client record?
A useful monitoring record identifies the client, policy domain, reporting window, observed sending source, authentication and alignment results, and the person responsible for the next action. Keep observed facts separate from the client's sender inventory and the MSP's interpretation.
RFC 9990 defines DMARC aggregate reporting. Reports describe grouped receiver observations; they do not establish sender authorization, identify every root cause, or prove inbox placement. For a suspected failure, preserve a delivered message or complete SMTP diagnostic from the affected sending path.
Use the DMARC onboarding checklist to establish access, domain scope and client approvers before recurring review. Keep unknown sources marked as unknown until an accountable owner classifies them.
A repeatable monitoring record
| Field | Record | Decision it supports |
|---|---|---|
| Scope | Client, policy domain, reporting window and collection gaps | Whether two observations are comparable |
| Sender evidence | Source IP or service, message counts and authentication identities | Which sending path needs investigation |
| Client confirmation | Approved, retired or unrecognized sender; named owner | Whether an authorization change is appropriate |
| Open work | Finding, controlling party, next action and due date | Who can resolve the issue |
| Validation | Approved change, retest evidence and remaining exceptions | Whether work can be closed |
How should an MSP review the portfolio?
1. Check collection before interpreting a trend
Compare reporting windows and collection coverage before calling a change an improvement or regression. A missing report is a coverage gap, not a clean bill of health. Keep each client's data separate even when a portfolio dashboard summarizes it.
Confirm the published reporting destination and any required external-destination authorization. RFC 9990 describes aggregate-report transport and destination validation. A public DNS check confirms the current record; it does not prove every receiver is reporting.
2. Triage changes by evidence and business impact
Review new or unrecognized senders, repeated authentication failures, unexpected policy changes and unresolved findings. Compare the same domain, sender and reporting window. A newly visible sender might be authorized business software, an intermediary or unauthorized use; investigate before assigning a cause.
Choose a review cadence that matches the client's service agreement and sending activity. The cadence is an operating choice, not an RFC requirement. Escalate a reported mail-flow incident through the client's incident process instead of waiting for the next routine review.
3. Assign work to the party that controls the fix
The MSP coordinates the finding. The client confirms business authorization, the sender owner controls application settings, and the DNS owner controls publication. Record the proposed action, approver and rollback condition before changing a record.
Do not use a passing public lookup to close an application-level failure. After an approved change, retest through the same application, authentication identity and message path, then review subsequent aggregate evidence for the affected source.
Use the client DMARC remediation workflow for the detailed repair and approval procedure.
How does monitoring inform enforcement?
RFC 9989 defines DMARC policy and alignment. A monitoring policy does not request quarantine or rejection for failed DMARC validation. Enforcement policies express the domain owner's handling preference; the receiving system still makes its own delivery decision.
Keep policy decisions separate from collecting reports. Confirm legitimate senders, investigate exceptions and validate the affected paths before an authorized client owner approves a policy change. Follow the client-domain policy rollout guide for those decision gates.
Inspect a client's published DMARC record
Check the current policy and reporting destination, then compare the result with the client's monitoring evidence.
Which tool-selection questions belong in the review?
Check client separation and access controls, report coverage and retention, remediation ownership, integrations, and portfolio pricing. For the vendor shortlist and individual tradeoffs, use the DMARC tools comparison for MSPs.
How should an MSP report progress?
Report what changed, the evidence available, unresolved exceptions, and decisions needed from the client. Use the client reporting template for the report format and the DMARC QBR guide for quarterly decisions. Do not label a published policy or a passing lookup as proof that every legitimate sender is configured correctly.
Palisade analyzes aggregate reports and prepares prioritized remediation tickets. An operator reviews evidence and proposed changes before publication. See Palisade for MSPs for the product offer and account workflow.
Sources and further reading
- RFC 9989: DMARC policy and alignment
- RFC 9990: DMARC aggregate reporting
- Palisade product documentation
Questions readers ask
Frequently asked questions
What should an MSP monitor for each client domain?
Monitor report coverage, observed sending sources, authentication and alignment results, policy state, and unresolved changes. Keep the reporting window, evidence and owner attached to each finding. A report source is not proof that the client authorized that sender.
Does a passing DMARC lookup complete the monitoring job?
No. A public lookup checks a published record. It does not inventory production senders or establish the result for a delivered message. Use aggregate reports and, when diagnosing a failure, evidence from the same sending application and message path.
When should an MSP change a client's DMARC policy?
After the client has confirmed legitimate senders, the relevant authentication paths have been validated, and the authorized owner has approved a scoped change and rollback conditions. Monitoring evidence supports that decision; it does not authorize it.
Where can I compare DMARC tools for MSPs?
Use the linked MSP DMARC tools comparison for vendor selection. This guide covers the recurring operating process: evidence collection, triage, ownership and validation.