Define the population before interpreting the colours
A bulk domain scan can make a large portfolio easier to triage, but its value depends on what entered the scan and what each result actually means. A hundred green rows do not establish that every business sender authenticates correctly. They may only show that a particular set of public names returned parseable records from one vantage point during one collection window.
This article proposes a bounded scan workflow. No scan, DNS query, account lookup or API call was performed, and no EmailAuth bulk-scanning feature is asserted. Standards and official provider documentation were reviewed on 8 November 2026. Collection tooling, customer authority and actual receiver behavior still require verification before execution.
Build a scoped input register
Start with a customer-approved inventory and preserve the original submitted value alongside the normalized query name. Record which customer owns the task, the source of the inventory and the permitted checks. An apex domain, a mail subdomain and a delegated child zone are not interchangeable targets. Normalize internationalized names using a documented library and version, preserving the display form so reviewers can detect mistaken substitutions.
Remove exact duplicate tasks without erasing evidence that two inventory entries referred to the same name. Quarantine malformed input instead of constructing a plausible replacement. Record omissions explicitly: unknown subsidiaries, unprovided DKIM selectors and private DNS views are coverage gaps, not clean results. Public visibility alone neither proves ownership nor authorizes uploading a customer portfolio to an external scanning service.
Specify the observations the scanner may make
List the exact record owners and types to be examined and the resolver or authoritative vantage to be used. Retain collection time, response status, answer data, relevant TTLs and the tool or evaluator version. Distinguish the recursive answer a client sees from the authoritative zone data. Cached observations have a different meaning from fresh authoritative responses, as described by RFC 1034.
Do not treat a record-list API as a public DNS scan. It can reveal configured records that are not currently served publicly, and it can omit another provider's delegated child zone. Route 53 documents both pending records and the risk of inconsistent multi-page listings during changes. Its API is a useful inventory source when separately authorized, but it is not evidence that every resolver received the same answer. Route 53 list limitations.
Keep absence separate from collection failure
A DNS result needs more than a boolean found flag. NXDOMAIN indicates a name error; a NODATA result indicates no relevant data of the requested type and must be interpreted from the response contents. SERVFAIL, refusal, timeout and truncated or otherwise incomplete collection require their own handling. They must not be rewritten as “no authentication record.” RFC 1035 response codes and RFC 2308 negative answers support these distinctions.
Use a bounded retry policy and preserve every materially different observation. Do not keep retrying until a favourable answer appears. If an error persists, mark that check inconclusive and identify who will investigate the resolver, delegation or access condition. Reporting an unknown result maintains the distinction between a domain problem and a measurement problem.
Evaluate authentication within its real scope
A syntactically valid SPF record is not a universal sender authorization result. SPF evaluation uses a particular sending IP and identity, and DNS-dependent terms have protocol limits. A static analysis may identify potential issues, but without a declared evaluation context it cannot prove that an actual message passes. RFC 7208 defines the lookup-limited terms; a simple count of all DNS packets is not the same calculation.
DKIM scanning is selector-dependent. Finding a public key for one supplied selector does not show that all senders use it or that a signature validates. An unknown selector is not evidence that a domain has no DKIM deployment. Likewise, a DMARC policy record describes domain policy and discovery information, while message evaluation also requires an authenticated identifier aligned with the author domain. RFC 6376 and current RFC 9989 define those different layers.
Bound collection load and downstream effects
Choose concurrency, timeouts and a maximum retry budget appropriate to the authorized service. Resolver capacity and provider API quotas are separate limits. Where a permitted inventory API is involved, honour its documented rate controls rather than increasing parallelism to conceal throttling. Cloudflare's published API limits and backoff headers are a vendor example, not a universal DNS query budget. Cloudflare rate limits.
A read-only scan should not automatically publish records, add domains to a paid plan, notify a customer or open a remediation workflow with external recipients. Define those actions separately. Store the portfolio and results under approved access and retention rules, especially when the inventory reveals customer relationships or unpublished service names.
Report denominators and a useful next decision
Separate in-scope, attempted, completed, failed and excluded checks. Explain whether percentages use domains, individual record checks or observed messages as their denominator. Never combine a message-authentication rate with a static configuration percentage. Group findings by evidence and urgency, then assign a human to confirm each proposed remediation against the actual sender inventory.
For a fictional portfolio of fifty domains, forty completed checks, seven timeouts and three withheld targets would not justify “eighty percent compliant.” The report should state the observed configuration findings for the forty, preserve seven inconclusive outcomes, and explain the three exclusions. Those numbers illustrate reporting design only; they are not scan results.
The catalogue still requires: One complete customer lifecycle runbook with roles, evidence and measurable service responsibilities. This proposed workflow supplies no completed customer run, verified domain observations or delivery test. Independent review, source applicability, original evidence, visual review and owner release remain necessary before publication.