Define the business question before counting domains
Billing and operations often describe different things with the same word “domain.” A billing system may count contracted units, an operational inventory may list verified domains, and a reporting system may record domains observed in traffic. Those totals can differ without any one system being wrong. Reconciliation starts by defining the metric, its time window and the unit being counted, then explaining each difference rather than forcing all totals to match.
Azure's multitenant identity guidance distinguishes identity and authorization from commercial entitlements and recommends managing entitlement logic in the application or a dedicated system. That distinction is directly relevant: an authenticated user or a configured domain does not automatically establish a billable entitlement. This manuscript proposes a reconciliation method and does not claim that EmailAuth implements a particular billing model, inventory API or analytics feature.
Establish stable customer and domain relationships
Record the approved customer identifier, operational tenant identifier, billing-account reference and domain inventory identifier where each system provides them. Keep display names separate from stable keys. A customer can rename its organization, use several domains or have distinct production and training tenants. A domain can also move between customer relationships over time. The reconciliation needs effective dates and ownership history rather than a current string match alone.
RFC 7643 distinguishes service-provider resource identifiers from externally supplied correlation identifiers in its identity schema. This is an example of why identifier roles matter, not a claim that SCIM defines domain billing. Apply the same care in the proposed mapping: identify which system owns each key and which field merely correlates records across systems. Do not infer customer ownership from an email suffix or from the person who last edited a row.
Write a reproducible metric definition
For every reported total, define the counted entity, inclusion criteria, exclusion criteria, status rules, effective time and deduplication method. “Active customer domains at month end” needs a precise meaning for active, customer and domain. Does it include pending verification, suspended tenants, subdomains, aliases, trial accounts or recently retired records? These are business definitions to approve, not technical facts to assume. Preserve the rule version used for each report.
Distinguish a domain inventory count from observed sender coverage. A configured domain may generate no traffic in the period, while a reporting source may observe an unrecognized or historical sender. Authentication reports are not necessarily a complete census of all messages or all configured services. A useful metric states the available sources and coverage caveats rather than treating absence of observations as proof that a domain is unused or should not be billed.
Keep raw totals before reconciliation adjustments
Retain each source's original total under the approved scope and timestamp. Then show the reconciliation categories that explain the difference: unmatched customer mapping, pending activation, retirement timing, duplicate representation, historical reassignment, source lag or a genuine unresolved exception. Do not silently modify raw totals to make a dashboard look consistent. The adjustment record is what makes the final number explainable and reproducible.
No source extract was collected here. In an authorized implementation, retain source versions or export identifiers and the query logic used to select rows. Minimize personal and financial data in the working dataset. Billing-account references can be represented by approved internal identifiers without copying payment credentials or unnecessary transaction details into the operational report. The reconciliation purpose does not authorize broader customer-data sharing.
Model domain and sender coverage separately
RFC 9989 evaluates domains and alignment relationships in email authentication. It does not define a platform's billable domain unit. A customer with one visible From domain may use several sending services, while one supplier may send for many customer domains. A domain count therefore cannot replace a sender-level operational drill-down. Keep those dimensions distinct in the data dictionary.
RFC 9990 defines DMARC aggregate reporting and its report-discovery and delivery mechanisms. Such reports can contribute observations for operational analysis, but their presence and coverage must be recorded. Do not infer that every receiver reports, every reporting period is complete or every operational sender appears in the retained dataset. The metric should label missing periods and source limitations rather than manufacturing a complete denominator.
A reconciliation worksheet
Create a worksheet with metric name, rule version, reporting cutoff, source system, raw total, source coverage and extraction reference. Add customer-to-tenant and tenant-to-domain mapping rules, effective dates, status definitions and deduplication criteria. The exception ledger should identify each unmatched or disputed item, the responsible owner, evidence needed and decision status. Use nonsecret references instead of embedding sensitive billing or account details.
The output section should retain the reconciled total alongside the raw totals and categorized adjustments. Add a sender-level drill-down that explains which observed services contribute to operational coverage for each domain, without pretending that a sender count is a billing entitlement. A reviewer should be able to reproduce the result from the approved rule and retained source material. This worksheet is proposed and has not been populated with real customer data.
Fictional diagnosis: three totals that disagree
A fictional service has 120 contracted domain units, 126 operational inventory rows and 98 domains observed in the month's retained reporting data. These numbers are illustrative, not measurements. The team initially wants to overwrite the inventory total with the billed count. The proposed reconciliation instead asks what each number represents and which records explain the differences.
In the fictional exercise, some inventory rows may be pending activation or historical records, while some configured domains may have no observed traffic in the available reports. Those are possible categories, not invented evidence that resolves the totals. The team would retain the original numbers, apply approved status and timing rules, and investigate unmatched items. It would not issue invoices, delete domains or change customer entitlements merely to make the figures agree.
Review exceptions with the right owners
Commercial owners decide contractual inclusion and billing rules. Operations owners verify configuration state and domain dependencies. Analytics owners explain query logic and source coverage. Security or identity owners verify tenant mappings and access boundaries. No single dashboard operator should silently decide all four. Document the approval needed when a reconciliation finding would lead to a bill adjustment, tenant change or domain retirement.
Separate a reporting correction from an operational action. A duplicate row can be excluded from a metric under an approved rule without authorizing deletion of the underlying resource. A missing billing mapping can be flagged without authorizing a charge. An apparently unused domain can remain operationally important. This separation prevents a useful analytical exercise from becoming an unreviewed change to customer access, configuration or finances.
Version the definition and preserve uncertainty
When the metric definition changes, record the reason and whether prior periods were recalculated. A change in deduplication or status rules can alter the reported trend without any change in customer behavior. Preserve comparable versions or explicitly label the discontinuity. Do not present a revised total as evidence of growth, churn or improved coverage until the definition change has been accounted for.
The catalogue requires a reproducible metric definition with raw totals, coverage caveats and sender-level drill-down. That original evidence remains open. The fictional totals are not a completed reconciliation or a substitute for source data. Human specialist review, source applicability, production routes, accessibility and owner release also remain open. A publishable example needs authorized retained inputs, approved definitions and a reproducible calculation, with no billing or operational changes implied unless separately approved and executed.