A high overall DMARC pass rate can coexist with a broken business-critical service. The larger stream dominates the arithmetic, while the smaller stream may carry password resets, invoices or urgent alerts. Review known legitimate services separately before using the headline rate to approve a change.
Define what passes
References: RFC 9989 §5.3.5, RFC 9990 §3.1.1.9, RFC 9990 §3.1.1.8, RFC 9989 §5.4.
Use the DMARC-evaluated aligned results rather than raw SPF or DKIM success alone. With an applicable valid policy and completed checks, passing one aligned mechanism is sufficient for a message-level DMARC pass; requiring both creates a different metric. Disposition is separate: a message can be handled under a receiver exception without becoming an authentication pass.
Weight rows by their message counts. A single healthy row representing thousands of observations and a failing row representing ten are not equally sized populations. Label the rate as applying to collected observations, not every message sent.
Split the approved sending inventory
Map observed identities to services using provider configuration, known routes and authorized message samples. A source IP by itself may be shared or represent a forwarder. Preserve unclassified traffic instead of assigning ownership from a guess.
For each critical service, record observed volume, aligned pass and fail counts, receiver coverage and latest test result. Keep unknown and suspected unauthorized traffic separate from the verified legitimate cohort. Classification changes should be dated so an improved rate cannot silently result from excluding inconvenient data.
Examine the small stream
Illustrative case: a marketing service has 99,900 passing observations and a password-reset service has 100 failing observations. The combined pass rate is 99.9 percent, while the observed password-reset pass rate is zero. The aggregate rate is mathematically correct but operationally incomplete.
This does not prove every password reset was rejected or that all messages from that service reached reporting receivers. It does justify immediate route-level investigation. Inspect current raw messages, aligned identities, provider settings and relevant gateways rather than celebrating the overall percentage.
Set decision gates around impact
Use the headline rate for context, then require evidence for critical services before tightening policy. A low-volume service without observations needs a test or a documented gap, not an assumed pass. Prioritize remediation by business impact, legitimacy confidence and current failure evidence.
Close the service issue with fresh end-to-end tests and subsequent report observations when available. Keep both the total metric and the service view in the operating report. A useful summary makes the important exception visible instead of allowing healthy volume to hide it.
Make exceptions visible in the operating review
List each critical service with its owner, expected identity, observed failures and current investigation state. Show the count even when rounding would make the overall chart look perfect. Include the latest successful controlled test and any routes it did not exercise. An owner should explicitly accept a remaining gap rather than allowing an unclassified service to disappear from review. Check after sender or template changes, because an earlier passing sample does not establish that a newly modified route still signs and aligns correctly.
Continue the investigation
Use the aggregate-report walkthrough to interpret the underlying fields and the alignment diagnosis guide when a raw authentication pass does not satisfy DMARC.
Keep the decision bounded
The local calculation gives 99,900 / 100,000 = 99.9% overall pass and 0 / 100 = 0% for the hypothetical password-reset cohort. The immediate decision is to investigate that critical route, not infer rejection of all 100 messages. These are invented teaching counts, not customer telemetry.