DMARC Failures: What Should an MSP Actually Do With the Report?
Published September 2026 by Solarc Labs
A DMARC “fail” is a triage signal, not an automatic DNS change
The operational mistake is to treat every failed row in an aggregate report as the same problem. NCSC guidance says DMARC reports can include legitimate mail received directly, legitimate mail forwarded through intermediary systems, and spoofed mail. Those states have different next actions. For an MSP, start by asking what sending source the row represents and whether the client actually authorises that source. Do not add an unfamiliar IP address or service to SPF simply because it appears in a report. A green dashboard is not worth expanding the set of systems allowed to send as the client.
First bucket the traffic: legitimate direct, forwarded, spoofed or still unknown
Use the aggregate evidence to classify the source before remediation. A known Microsoft 365, Google Workspace, CRM, billing platform or marketing system may be legitimate but misconfigured. A forwarding path can change which authentication mechanism survives. An unauthorised source may simply be the spoofing activity DMARC is intended to expose. Some rows will remain unknown until the client or service owner confirms whether that sender exists. Keep “unknown” as a real state. Do not silently convert uncertainty into “malicious” or “approved”. The owner of the client domain should be able to see what evidence is missing and who must resolve it.
If a legitimate sender is failing, repair the sender configuration — not the report
NCSC guidance says to identify legitimate email that is not passing SPF or DKIM and then correct the relevant configuration. For SPF, that can mean authorising a sending system through the correct published mechanism. For DKIM, it means ensuring the valid key is published at the right DNS location and that outbound mail is actually signed. The important constraint is legitimacy. Confirm the application, sending domain and owner first. Then make the smallest evidence-backed authentication change and wait for the subsequent report window to show whether the known sender recovered.
If the source is not legitimate, you often do not “fix” that sender at all
Unauthorised or spoofed sources should not be added to authentication records. Their presence can be useful evidence that somebody attempted to send using the domain. The action is to confirm that the organisation does not use the source, keep the policy and authentication controls correctly configured, and investigate further only when the volume, pattern or surrounding evidence justifies it. Do not promise a client that aggregate DMARC data will identify the individual recipient of every spoofed message or provide complete forensic context. The report is an authentication aggregate, not a full mailbox trace.
Forwarded mail needs interpretation before you call it a broken sender
Forwarding and intermediary systems can affect authentication results, so a failed mechanism does not automatically mean the original service is unauthorised. NCSC explicitly includes legitimate forwarded mail among the traffic operators should expect to see while reviewing DMARC reports. Preserve the observed SPF and DKIM results and the known sending path. If one mechanism still provides aligned authentication, or the failure is explained by the forwarding path, record that evidence instead of making speculative DNS changes.
Turn the report into a small MSP action queue
A useful managed workflow records the client, domain, source, authentication result, classification, owner, proposed action and recovery condition. That turns thousands of aggregate rows into a bounded queue: fix a legitimate sender, ask the client to identify an unknown source, observe a spoofed source without authorising it, or verify recovery after a controlled change. Alerting should focus on material transitions and unresolved legitimate senders rather than producing a ticket for every repeated low-value failure. The client should be able to understand what changed, what you know, what remains unknown and what action — if any — is justified.
DomainGuard can support the evidence layer, but it is not full mail forensics
DomainGuard is positioned for small MSPs, IT agencies and email-operations teams managing multiple business domains. Its bounded scope includes SPF and DMARC analysis, explicitly supplied DKIM checks, encrypted monitor state and bounded aggregate DMARC report ingestion. It does not guess DKIM selectors, mutate customer DNS automatically, identify every recipient of spoofed mail, guarantee inbox placement or replace a specialist managed DMARC investigation service. Use it where the job is to make verifiable domain-control state and report evidence easier to review; use broader tooling when the client needs full sender attribution, enforcement management or mail-flow forensics.
Primary sources
Sources used for this article
Continue the job