A DMARC percentage is useful only when its denominator is defined. The same numerator can describe authentication success, approved-sender health or observed enforcement, depending on the population below it. Write the question and the counting rule before choosing the chart.
Distinguish the questions
References: RFC 9989 §5.3.5, RFC 9990 §3.1.1.9.
For an observed DMARC pass rate, use passing aligned message observations divided by all included message observations in the same scope. For approved-service health, restrict both numerator and denominator to the verified legitimate cohort. For a disposition distribution, count handling categories without calling them authentication results.
With an applicable valid policy and completed checks, an aligned SPF pass or aligned DKIM pass can satisfy the message-level DMARC rule. Counting only messages where both pass produces a stricter metric and must be labelled accordingly. Counting raw authentication success without alignment answers another question entirely.
Declare scope and exclusions
References: RFC 9990 §3.1.1.8, RFC 9990 §3.5.4.
State the policy and author domains, reporting receivers, UTC interval, as-of time and deduplication policy. Record treatment of unknown traffic, invalid reports, overlaps and late arrivals. Sum each included row's count; the number of rows is not the number of observed messages.
Use zero denominators as unavailable, not zero percent or 100 percent. A service with no observations has no measured pass rate for that scope. Low-volume rates should display counts so a reader can distinguish one failure in two observations from a stable larger population.
Compare two legitimate views
Illustrative dataset: 900 observations belong to verified legitimate services, of which 891 pass. Another 100 observations are unclassified, of which 20 pass. The observed overall pass rate is 911/1,000, or 91.1 percent. The verified-legitimate pass rate is 891/900, or 99 percent. Both are valid for their stated cohorts; neither authorizes calling the 100 unclassified observations malicious.
If classification later changes, version the metric rather than quietly revising the denominator. A rising percentage can reflect excluded data instead of better authentication. Preserve the old scope and explain whether the change represents a repair, new evidence or a reporting adjustment.
Avoid unsupported coverage claims
Dividing reported observations by sender submissions does not automatically produce receiver coverage because the populations and units may differ. Use a scoped reconciliation before describing coverage numerically. Show contributing reporters and missing expected routes when a defensible universal denominator is unavailable.
For operational decisions, combine a clearly defined overall rate with critical-service rates, unknown volume and evidence freshness. Save the calculation query, input version and exception rules. Another analyst should be able to reproduce the number and understand the question it actually answers.
Write a metric contract
Give each metric a stable name, business question, counting unit, scope filter and owner. Include a worked small-number fixture with its expected result and a zero-observation case. State when a reporting period is provisional and how late reports revise it. Separate a change to the calculation from a change in the underlying mail so historical comparisons remain intelligible. Review the contract with the people using the number for policy decisions; a technically correct percentage can still answer the wrong business question.
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 preserves both 911 / 1,000 = 91.1% overall and 891 / 900 = 99% verified-legitimate pass. With zero observations it returns unavailable, not a percentage. Cohort labels are supplied assumptions; the exercise does not classify actual traffic.