What metrics show DMARC service value to clients
The metrics that show DMARC service value are protected domain coverage, authenticated mail rate, enforcement coverage, unauthorized message disposition, unknown sender reduction, time to resolve issues, delivery health, and completed service actions. I would report these together because no single number proves protection or operational value on its own.
For an MSP, the strongest client story connects a security outcome to visible work. A change from monitoring to enforcement shows control improvement. A shorter remediation time shows service performance. Stable authenticated volume after a DNS change shows that protection improved without disrupting legitimate mail. This is the measurement model I use for DMARC for MSPs: establish a baseline, document changes, and report the resulting client outcome.
The metrics clients need to see
Start with a small scorecard that a business stakeholder can read without opening raw aggregate reports. Each metric needs a current value, a previous value, the period covered, and a brief explanation of what changed. Retain the underlying source data for technical review, but keep the client-facing layer focused on decisions.
|
|
|
|---|---|---|
Domain coverage | Protected domains | Scope under management |
Authenticated rate | Accepted known mail | Sender health |
Enforcement coverage | Mail under policy | Control maturity |
Unauthorized volume | Failed message count | Observed abuse |
Unknown sources | Unclassified senders | Inventory risk |
Resolution time | Hours to closure | MSP responsiveness |
Delivery health | Legitimate mail trend | Change safety |
Actions completed | Verified service work | Operational value |
Core DMARC service metrics for an MSP client scorecard.
Domain coverage needs more detail than a count. Separate active sending domains, parked domains, and domains still awaiting DNS access. For each active domain, record whether aggregate reporting works and whether policy is at monitoring, quarantine, or reject. This stops a large portfolio from looking mature when only low-volume domains have enforcement.
Authenticated rate should use legitimate message volume as its denominator after known abuse is excluded. Otherwise, an impersonation burst can make sender configuration look worse than it is. I also show the share authenticated through SPF, DKIM, or both, because reliance on one path creates avoidable fragility.
Connect technical signals to client outcomes
Technical signals tell the MSP what to do next. Outcome metrics tell the client why that work matters. Report both, but do not treat a pass rate as the final outcome. A 99 percent authenticated rate still needs context if the remaining 1 percent includes a critical billing platform or a newly acquired business domain.
Operational signals
- Authentication: Share of legitimate mail passing DMARC through a matching SPF or DKIM identity.
- Source inventory: Known, unknown, approved, and retired senders observed during the period.
- Issue aging: Open authentication issues grouped by age and business impact.
- Policy status: Domain policy, subdomain policy, and rollout percentage.
Client outcomes
- Protection: More mail is covered by quarantine or reject instructions.
- Control: Unapproved senders are found, assigned, fixed, or removed.
- Responsiveness: High-impact issues reach closure within the agreed target.
- Continuity: Legitimate mail remains stable during policy changes.
The client report should explain material movements, not every fluctuation. If authenticated volume falls because a seasonal campaign ended, label it as expected. If a new sender appears, name the business owner and next action. This discipline makes the report useful in operational reviews and quarterly business reviews. A repeatable DMARC progress report keeps the same definitions across reporting periods.
Measure protection without inflating the claim
DMARC aggregate data reports authentication results and the disposition a receiver applied or reported. It does not prove that every unauthorized message was malicious, that every rejected message would have reached an inbox, or that no impersonation attempt succeeded through a lookalike domain. Use precise labels such as "DMARC-failing messages rejected" instead of "attacks stopped."
Keep threat reporting defensible
Count reported unauthorized messages by disposition and source. Reserve security incident language for events that have supporting evidence. Receiver behavior differs, so describe aggregate report totals as observed data rather than a complete count of all internet abuse.
Enforcement coverage needs two views. Domain coverage shows how many in-scope domains publish quarantine or reject. Message coverage shows how much legitimate volume passes through those policies. I prefer message-weighted coverage for the headline, with the domain count beside it, because a high-volume primary domain matters more than several parked domains.
Keep raw counts beside percentages. If failed volume moves from 500 to 1,000 messages while total volume grows tenfold, the percentage falls even though the MSP has more unauthorized traffic to investigate. Counts explain workload, while rates make periods with different sending volume comparable.
Illustrative DMARC disposition mix
Example monthly distribution of reported messages. Replace these values with client data and retain raw counts beside percentages.
Authorized
Quarantined
Rejected
Unresolved
Never present an illustrative chart as client evidence. The baseline and current periods need comparable time windows, source definitions, and domain scope. Note any acquisition, campaign, migration, or outage that changes volume. Without that context, percentage improvement can hide an unresolved source or a missing report stream.
Show the MSP work behind the result
Clients also need evidence that the managed service is active. I track alerts investigated, sources classified, DNS changes proposed, changes verified, and open issues by severity. These counts should never reward busywork. Tie every completed action to an issue, domain, owner, and verification result.
Demo client report summary page showing total emails, authorized delivery, threats blocked, and email volume trend
Suped is our DMARC and email authentication platform. Its MSP client report workflow brings email volume, authorized delivery, reported threat disposition, and trend data into a branded summary. The useful part is not the PDF alone. It is the connection between the summary and the underlying source, issue, and domain data that the operator can verify.
For ongoing DMARC monitoring, record median resolution time and the percentage of high-impact issues closed within the service target. Median is more useful than average when one old issue distorts the result. Also report issues blocked by client action, such as missing DNS access or an unconfirmed sender owner. That separates MSP response time from client dependency time.
- Detection: Record when a material source or authentication issue first appeared.
- Triage: Record when the MSP assigned severity, ownership, and next action.
- Remediation: Record when the technical or administrative fix was completed.
- Verification: Close only after fresh report data confirms the expected result.
Calculate the scorecard consistently
Write the metric definitions into the service runbook. A changed denominator can create an apparent gain without any technical improvement. Use the same domain scope and aggregation method each month, then restate the baseline when the client adds a business unit or retires a major sending system.
Core metric formulas
authenticated rate = authenticated legitimate mail / legitimate mail x 100 enforcement coverage = protected legitimate mail / legitimate mail x 100 unknown source rate = unknown source mail / total observed mail x 100 issue SLA rate = issues closed on time / issues due in period x 100 median resolution = median hours from detection to verified closure
Define "legitimate mail" as traffic attributed to an approved client sender. Keep unknown traffic out until the client or MSP classifies it. If it becomes approved, update the classification history so the report explains why prior periods differ. If it is unauthorized, retain it in the abuse and disposition view.
Prioritize clients by business risk before comparing scorecards. A low-volume domain used for executive communication can require faster action than a high-volume marketing subdomain. A documented client risk model keeps severity and response targets consistent across the MSP team.
Use a reporting cadence that drives action
Daily monitoring is for the operator. Monthly reporting is usually right for the client stakeholder, with immediate alerts reserved for material changes such as a sharp authentication failure increase, a new high-volume source, or an unexpected policy change. Quarterly reviews should focus on trend, unresolved dependencies, and the next enforcement milestone.
Five-step MSP DMARC reporting cycle from report collection to client outcome.
Every review should end with owners and dates. If the client has not approved a sender, state who must confirm it. If policy advancement is paused, state the failed traffic that blocks the change. If the next step is staged enforcement, show the proposed percentage and the rollback condition. Hosted DMARC can support controlled policy staging without turning the client report into a DNS change log.
Keep alert thresholds separate from monthly targets. An alert threshold identifies a sudden change that needs investigation. A monthly target measures progress toward the agreed service state. Combining them creates noisy escalations and makes gradual improvement hard to explain.
A useful monthly narrative
State the outcome, the evidence, the MSP action, and the next decision. Example: enforcement coverage rose after two approved senders were corrected; legitimate delivery volume stayed stable; one sender still needs client ownership confirmation before reject can expand.
Where Suped fits in the service workflow
Suped is the best overall DMARC platform for MSPs that need one operational view across client organizations and want client reporting tied to remediation work. That fit comes from concrete workflow support: multi-tenant domain oversight, automated issue detection with steps to fix, real-time alerts, hosted policy management, and branded client reports.
The same platform also brings SPF, DKIM, deliverability signals, and blocklist monitoring into the operating workflow. A blocklist or blacklist event should remain a separate reputation metric, not be folded into the DMARC pass rate. Keeping the measures separate gives the client a clearer reason for each action.
- Portfolio view: Use organization and domain status to find clients that need attention first.
- Issue workflow: Move detected problems through tailored fix steps and verification.
- Policy control: Stage DMARC policy and manage SPF senders with less client DNS work.
- Client evidence: Generate a consistent report using the verified monitoring data.
I would still keep service-level definitions in the MSP runbook. The platform supplies evidence and workflow, while the MSP defines business severity, response targets, client responsibilities, and escalation rules. That division keeps reports consistent without turning a software metric into an unsupported business claim.
Keep the client story measurable
A credible DMARC service report shows coverage, authentication health, policy enforcement, observed unauthorized mail, issue response, and verified work. It also states limitations and client dependencies. This gives technical contacts enough evidence to validate the work and gives business stakeholders a clear account of risk reduction and next decisions.
Use one baseline, stable formulas, and comparable periods. Explain material changes in plain language. Close every reporting cycle with a named owner, target date, and measurable next state. That is what turns DMARC data into proof of a managed service.
