How to use DMARC data in client security reviews
Updated on 18 Oct 2026: We clarified DMARC reporting limits and enforcement evidence so client reviews lead to verifiable remediation decisions.
DMARC data belongs in a client security review as evidence of who sends mail for the client's domains, which traffic authenticates with aligned SPF or DKIM, what unauthorized activity receivers reject, and what the MSP must fix next. Turn each signal into a finding with a business risk, an owner, a deadline, and a verification step. Raw XML and unexplained sender statistics do not give client stakeholders enough context to make a decision.
The review should cover a defined reporting window and compare it with the previous period. It should separate legitimate authentication failures from impersonation attempts, show the current DMARC policy, and state whether every active sending source has an accountable owner. That structure makes DMARC useful for service delivery, risk acceptance, change control, and enforcement approval.
What DMARC data belongs in the review
Start with aggregate report data, then add client context. Aggregate reports provide source IPs, message counts, receiver dispositions, SPF results, DKIM results, and alignment information. Standard aggregate reports contain no message bodies or subject lines. A source IP alone rarely identifies the application owner, so the MSP still needs a maintained sender inventory that maps each platform, connector, relay, and vendor to a client contact.
|
|
|
|---|---|---|
Policy | Mode and scope | Stage enforcement |
Known senders | Volume and owner | Keep or retire |
Alignment | SPF or DKIM | Approve remediation |
Unknown traffic | Source and pattern | Investigate or block |
Trend | Prior comparison | Accept next stage |
Compact fields for a client-facing DMARC review
DMARC passes when at least one authentication method passes with alignment to the domain visible in the From address. A raw SPF pass for a vendor-controlled return path does not prove DMARC alignment. The same distinction applies to DKIM when the signing domain belongs to a platform rather than the client. Report aligned outcomes because they describe authentication of the visible client identity. Record the aspf and adkim settings: relaxed alignment compares organizational domains, while strict alignment requires an exact domain match. These modes are described in Microsoft's DMARC guidance.
Do not turn one percentage into the security story
A lower overall pass rate can result from increased impersonation traffic. Calculate legitimate authentication health only after classifying known and unknown sources. Report confirmed unauthorized volume by receiver disposition, including reject and quarantine, separately from legitimate authentication health.
Check reporting coverage and evidence limits
Aggregate reports are summaries from participating receivers, usually delivered daily. Missing reports are an evidence gap, so no reported failures does not establish that a domain is unused or safe.
- Track reporting organizations and covered UTC dates, plus delayed reports and collection start dates. Flag incomplete comparison periods.
- Validate the rua destination and external reporting authorization before interpreting an abrupt drop as reduced sender activity.
- Use report IDs with reporter identity and reporting periods to identify duplicate XML. Document how overlapping periods affect counts.
- Compare reported patterns with sending logs or message traces for critical applications. Reported volume is not a complete outbound ledger.
Retain the source report IDs and the DNS snapshot behind each approval. Restrict raw-report access and agree retention with the client, since source IPs and sending patterns reveal operational details. RFC 9990 defines aggregate reporting and duplicate handling.
Turn report rows into security findings
Each source should move through the same classification process. Group records by organizational domain, source, authentication pattern, and business owner, then compare the source with the approved sender inventory and recent client changes. New marketing software, finance platforms, support systems, and forwarded mail often explain a change, but an explanation does not make a failing configuration acceptable.
- Inventory: Match every material source to a known service, purpose, client owner, and technical contact.
- Classify: Mark the source as authorized, unauthorized, obsolete, forwarding-related, or still under investigation.
- Validate: Check SPF and DKIM alignment, volume consistency, selector use, sending regions, and the receiver's applied disposition.
- Prioritize: Rank findings by impersonation exposure, legitimate delivery impact, affected volume, and enforcement dependency.
- Assign: Record the client approver, implementation owner, target date, validation method, and fallback plan.
The sender inventory is the control boundary. Without it, an MSP can label an unfamiliar source as malicious when it belongs to a forgotten business system, or authorize a suspicious source because it has regular volume. A structured process for inventorying client senders keeps the evidence tied to client change management.
Illustrative finding evidence templatetext
Domain: example.com Window: 2026-07-01 to 2026-07-31 Source: Approved billing platform Observed: 18,420 messages, DKIM aligned, SPF not aligned Assessment: DMARC passes through DKIM; no current DMARC failure Risk: Changes to DKIM configuration require validation Action: Verify DKIM stability; assess aligned MAIL FROM support Owner: Client application owner Verify: Test messages and reports covering the next billing cycle
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Separate client risk from delivery noise
A useful review distinguishes security exposure from configuration debt. Unauthorized sources sending with the client's visible domain indicate impersonation activity or an unapproved service. Authorized sources that fail alignment indicate operational debt and can block a move to enforcement. Both require action, but they need different owners and different language in the client meeting.
Security risk
A source confirmed as unauthorized uses the client's visible From domain, with repeated observations supporting an impersonation finding.
- Evidence: Failed alignment from a source confirmed as unauthorized.
- Owner: MSP security lead and client risk owner.
Delivery debt
An approved application sends legitimate mail but fails DMARC because neither SPF nor DKIM passes with alignment, or its authentication configuration fails intermittently. One reliable aligned method satisfies DMARC.
- Evidence: DMARC failures from an approved source with confirmed business ownership.
- Owner: Client application owner and vendor contact.
Forwarding needs its own review note. SPF often breaks when a message is forwarded because the forwarding system becomes the connecting source. Aligned DKIM can preserve DMARC authentication if the signature remains valid. Do not treat every forwarded SPF failure as an attack. Check DKIM alignment, receiver behavior, message volume, and whether the same path appears consistently.
DMARC addresses spoofing of the client's actual From domain. It does not stop lookalike domains or display-name impersonation. Mail sent through a compromised authorized account can still pass DMARC, so authentication alone does not prove a message is safe. These limits are part of RFC 9989. Receiver dispositions describe reported DMARC handling; they do not establish inbox placement or a count of all attacks prevented.
DMARC report triage workflow for sender identification, authentication checks, and remediation ownership
Build evidence the client can approve
Client stakeholders need a concise control story. Lead with the current policy, the amount of legitimate mail covered by aligned authentication, the remaining enforcement blockers, and the unauthorized traffic receivers handled. Then show the few sources that require a decision. Detailed rows remain available for technical follow-up, but they do not take over the meeting.
Demo client report summary page showing total emails, authorized delivery, threats blocked, and email volume trend
Use consistent denominators. Calculate legitimate authentication health as DMARC-passing known legitimate messages divided by all reported known legitimate messages. Show unresolved traffic separately. Unauthorized traffic should have its own count and trend. Enforcement coverage should state the effective policy for every in-scope domain, including inherited subdomain policies and explicit overrides. Include parked domains; no observed mail does not prove they are protected. If the reporting window or source classification changes, note that change before comparing periods.
RFC 9989 makes pct historic, so a published percentage is not reliable evidence of partial enforcement. Stage policy changes by domain or subdomain and verify receiver behavior. Record t=y where present: it requests handling one policy level below quarantine or reject, so p=reject with t=y is not full rejection coverage.
- Control status: State the effective domain policy, subdomain handling (including sp and np where applicable), test mode, and reporting health.
- Material changes: Show new senders, retired systems, sudden volume shifts, and configuration changes.
- Open risk: List unknown sources, persistent alignment failures, and exceptions that delay enforcement.
- Decisions: Ask for owner confirmation, remediation approval, risk acceptance, or the next policy stage.
A monthly operational report can feed a quarterly security review without duplicating work. Keep the same source names, owner fields, and finding identifiers across both. The process for a monthly DMARC report should preserve enough evidence for later governance decisions.
Run the client review as a control meeting
The meeting should produce decisions instead of awareness alone. Before the call, send the summary and identify every item that needs client input. During the call, confirm business ownership first, then discuss technical remediation. After the call, issue an action register and update the sender inventory. This keeps DNS work connected to client governance.
A review agenda that fits normal MSP operations
- Scope: Confirm covered domains, reporting window, and data completeness.
- Progress: Review policy changes, closed findings, and authentication trend.
- Risk: Discuss unknown sources, recurring failures, and enforcement blockers.
- Actions: Confirm owners and due dates, validation criteria, escalation paths, and an expiry date for each accepted exception.
Do not move a domain to reject because the headline pass rate looks high. Confirm that all approved high-volume and business-critical senders have aligned authentication, low-volume and seasonal systems have been checked across their normal sending cycles, and exceptions have documented owners and expiry dates. Keep a rollback plan for material delivery issues, then verify the policy change in subsequent aggregate data.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A current DNS check complements report history. It confirms what the domain publishes now, while aggregate data shows how receivers observed real mail during the review window. Use both before approving enforcement because a recently corrected record can look healthy even though the period still contains older failures. The reverse also happens when a record changed after a clean reporting period.
For recurring governance, fold these decisions into structured DMARC QBRs. The cadence gives the client a place to approve policy stages, resolve cross-team ownership, and review overdue remediation.
Make the workflow repeatable across clients
Standardize the service before scaling it. Every client should have the same source classifications, severity rules, evidence fields, review cadence, and closure criteria. The MSP can then compare operational workload across tenants without comparing client risk using inconsistent definitions. Keep tenant data separated and expose only the technical detail needed by each stakeholder.
Suped, our DMARC and email authentication platform, centralizes client domains in a multi-tenant dashboard, while automated issue detection turns report patterns into remediation steps. Alerts help the service desk respond as new aggregate reports arrive, and client reports package authentication health and trends for stakeholder meetings. The DMARC for MSPs workflow keeps operational detail and client reporting connected.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
Use Suped's DMARC monitoring to verify authentication changes in subsequent reports. If a review includes blocklist monitoring, keep domain or IP blacklist (blocklist) findings separate from DMARC results; each requires its own evidence and remediation.
Keep the final authority with the client. The MSP can recommend a policy stage, identify safe configuration changes, and verify results, but the client should approve material risk acceptance and changes that can affect business mail. Record that approval alongside the DMARC finding so the next review begins with an auditable decision history.
Frequently asked questions
Show effective policy status, reported legitimate volume, the DMARC pass rate for known legitimate mail, unresolved source volume, receiver dispositions, enforcement coverage, material changes, and open findings. Define each denominator, flag reporting gaps, and compare equivalent periods.
No. DMARC passes when SPF or DKIM passes with alignment to the visible From domain. Both methods working provides resilience where supported, but one aligned method satisfies DMARC.
Present the source, volume, authentication pattern, first and last observation, likely service identity, and investigation status. Do not label it malicious until the sender inventory and client owner checks support that conclusion.
Recommend reject after approved senders authenticate with alignment, low-volume and seasonal sending cycles have been reviewed, forwarding behavior is understood, exceptions have owners and expiry dates, and the client approves the change and rollback plan. Verify receiver-reported handling in later aggregate reports.
Review operational findings monthly and carry material risks, policy decisions, overdue actions, and trend changes into the client's normal quarterly security review. Use alerts between scheduled reviews for sudden authentication failures or source changes.
