DMARC

The DNS Query Explosion: The Hidden Infrastructure Cost of DMARC Monitoring at Scale

October 9, 2026

Randy Hall, CEO— AI-assisted and reviewed prior to publication.

A single domain's DMARC setup looks harmless on paper: one TXT record, a handful of aggregate reports a day, maybe a dozen sending sources to reconcile. Multiply that by the two, three, or five hundred client domains a typical managed service provider now oversees, and the picture changes. What looked like light bookkeeping becomes a constant stream of DNS lookups, record checks, and reverse-IP resolutions running in the background of every monitoring platform on the market.

What Actually Causes the DNS Query Explosion?

The explosion comes from three compounding sources: SPF's own per-message lookup limit, the reverse-DNS and ASN work needed to make sense of aggregate reports, and the polling that monitoring tools do to catch record changes. None of these is expensive alone. Run across hundreds of domains, dozens of daily reports, and continuous polling intervals, the query count scales into the hundreds of thousands per tenant per month.

Start with the protocol-level cost. The SPF specification, defined in RFC 7208, caps every SPF evaluation at ten DNS-querying mechanisms, and that limit has to be tracked as a single global count across the whole recursive evaluation, not per include statement. Every mailbox provider checking an inbound message against a client's SPF record can trigger up to that many lookups on its own, and that happens on every message, from every provider, for every domain an MSP protects.

Then there is the reporting side. DMARC aggregate reports arrive from receivers as XML summaries covering a rolling window, typically twenty-four hours, listing every source IP that sent mail claiming to be the domain. Making that data useful means resolving each IP, which is exactly the workflow security teams describe when they walk through triage: reverse DNS lookups to identify the sending host, WHOIS queries to find the network owner, and reputation checks against blocklists, as one analysis of aggregate report workflows lays out. A domain with even a modest number of third-party senders, marketing platforms, CRM tools, helpdesk software, can generate dozens of distinct source IPs per report. Across hundreds of client domains reporting daily, that is tens of thousands of secondary DNS queries just to attribute traffic.

The third layer is monitoring itself. Platforms that track DMARC, SPF, DKIM, MTA-STS, and BIMI records for drift need to re-query DNS on some interval to detect changes, because DNS offers no push notification when a client's registrar or IT staff edits a record. The tighter that polling interval, the earlier a broken record gets caught, and the higher the query count climbs.

Why Does This Matter for MSPs Specifically?

It matters because MSPs operate at a multiplier that single-domain tools were never designed for. A platform built to check one domain's records comfortably absorbs the load of one domain, but the same architecture running unmodified across a full client roster turns a rounding error into a real infrastructure cost and, at some providers, a rate-limiting problem.

DNS resolvers are not infinite. Google's own Public DNS documentation states that it enforces query-per-second limits on outgoing requests from its serving clusters to protect authoritative name servers from being overwhelmed, and separately rate-limits responses to any single client IP to guard against amplification abuse, as described in Google's Public DNS security documentation. A monitoring tool that queries too aggressively from a shared IP range can trip exactly the kind of throttling those limits exist to enforce, producing timeouts that look like a broken client DNS record when the real cause is the checking tool itself.

Managed authoritative DNS is not free either. Amazon's Route 53, one of the more commonly used platforms for MSP client zones, bills $0.40 per million standard queries for the first billion queries a month and $0.20 per million after that. That is a modest line item at low volume, but it compounds when a monitoring platform polls SPF, DMARC, MX, and BIMI records for hundreds of zones on a tight schedule, every day, indefinitely.

The Scale Problem Behind the Numbers

DMARC adoption itself is growing fast enough that the aggregate load across the industry is rising independently of any one MSP's client count. Valimail's tracking of the top ten million domains shows the industry crossed roughly two million domains with valid DMARC records by April 2024, a threshold representing about 20 percent adoption among that set. Separate reporting citing Valimail data found the monthly pace of new DMARC records roughly doubled year over year, climbing from about 55,000 new domains a month in 2023 to around 110,000 a month by the third quarter of 2024. Every one of those new records is a fresh source of aggregate reports landing in someone's monitoring pipeline.

For federal agencies and their contractors, the query volume is not optional overhead, it is a compliance floor. CISA's Binding Operational Directive 18-01 requires agencies to set a DMARC policy of reject for their second-level domains and mail-sending hosts, a mandate that CISA's own directive text confirms drives sustained aggregate reporting and monitoring across every covered domain, indefinitely. MSPs serving that market inherit the query load whether or not they priced it into the contract.

DMARC record math at typical MSP scale, assuming daily aggregate reports and a modest polling cadence, looks roughly like this:

The ranges vary widely by sender diversity and polling frequency, but the direction is the same: query volume scales linearly with domain count and does not level off.

Managing the Load Without Losing Visibility

None of this means MSPs should monitor less. It means the underlying architecture has to be built for aggregation rather than brute-force polling. Caching resolved IP-to-ASN and PTR data instead of re-resolving the same sending source on every report is the single biggest lever, since the same handful of ESP and cloud-provider IPs tend to show up across dozens of client domains.

DNS's own negative-caching behavior helps here too, though it has to be respected rather than fought. Batching record checks into scheduled sweeps rather than continuous per-domain polling, and deduplicating queries for source IPs that recur across a client portfolio, keeps the query count proportional to genuine change rather than to raw domain count. This is the difference between a monitoring platform that scales cleanly to a thousand domains and one that starts timing out at three hundred.

For MSPs evaluating whether their current stack can absorb this load, the practical test is straightforward: ask how the vendor's architecture handles report attribution once client count doubles, not just whether it works for a demo tenant. A platform's pricing structure is often the fastest signal, since providers that charge per domain with no volume-based query overhead have usually solved the caching problem already, while those that quietly throttle beyond a threshold have not.

Building Monitoring That Scales With the Client List

The DNS query explosion is not a flaw in DMARC itself. RFC 7489 and the aggregate-reporting standard that succeeds it were built for domain-by-domain visibility, and they do that job well. The strain shows up specifically at the layer where a single monitoring platform has to do that job hundreds of times over without falling back on the same brute-force polling that works fine for one domain and buckles under three hundred.

MSPs bringing a new client roster onto DMARC monitoring can sidestep most of this by starting with correct SPF and DMARC record structure from day one, since a flattened, lookup-efficient SPF record generates fewer downstream queries for every receiver checking it. Teams building that process from scratch can walk through the setup sequence in ActiScan's getting-started guide, which covers record structure before report volume becomes a factor. For MSPs ready to see how query-efficient monitoring behaves against an actual client portfolio rather than a single test domain, the fastest way to check is to sign up and run it against a real roster.

The infrastructure cost of DMARC monitoring at scale will not shrink as adoption keeps climbing toward the levels CISA and the major mailbox providers now expect. What changes is whether an MSP's tooling absorbs that growth quietly or turns it into throttled queries, delayed alerts, and a DNS bill nobody budgeted for.