The Hidden SaaS Map: What 840 GB of DNS TXT Records Reveal About Who Owns the Internet's Apex

The cleanest map of who runs the Internet's apex domains lives in the most ignored DNS record type. When you connect a new domain to Google Workspace, Microsoft 365, Atlassian, Stripe, AfterNic, or one of forty other platforms, the vendor instructs you to add a vendor-prefixed TXT record at your apex. You add the record, the verification flow ticks green, and you forget about it. The TXT record stays in DNS — for years, often for the lifetime of the registration. Multiplied across hundreds of millions of domains, those forgotten tokens are a near-perfect ground-truth census of which vendors own which apexes.

The conventional way to measure SaaS market share — paid seats from quarterly earnings, IDC reports, third-party panel surveys — measures what vendors say they have, weighted toward what they want quoted. Microsoft reports 446 million paid Microsoft 365 seats; Google does not break out a paid Workspace seat number; Atlassian reports "350,000+ total customers" and 51,978 Cloud-ARR-over-$10K customers; Stripe says "more than 5 million businesses, directly or via platforms"; Brevo claims "more than 600,000 customers" and powers >500,000 active sites; Zoho passed "1,000,000 paying customers" with 150 million users in its 30th-anniversary release. None of those numbers count the domains. Two M365 tenants might share one domain, or one apex might verify with eight different platforms. The financial-disclosure number and the domain-footprint number are different objects entirely, and the second is the one that matters for questions about lock-in, ecosystem reach, vendor power, abuse infrastructure, and the geography of digital trust.

This post measures the second number. We took a complete TXT-record DNS crawl from 17 April 2026 — 3,105 result files, 840 GB of raw single-line JSONL (56 GB after xz compression, a 15× ratio), an estimated 1.9 billion hostname queries — and stream-classified every TXT data string against a catalogue of 50+ vendor verification-token formats. We then deduplicated to eTLD+1 (the registrable apex) using the Mozilla Public Suffix List and tallied unique apexes per vendor. The result is the closest the public Internet has to an open-source SaaS market-share census.

The headline: 40,180,281 unique apex domains carry at least one tracked vendor verification token. 25,988,287 of them sit under at least one Google verification — 3.41× the Microsoft-365 footprint of 7,624,510 apexes. The eight domain-marketplace tokens we track (AfterNic, dan.com, 4.cn, Aliyun, west.cn, 17ex, Sedo, DomainEasy) collectively cover 5,027,426 apexes — bigger than the verification tokens of Atlassian, Stripe, Adobe, Apple, and DocuSign combined (893,832), and 65.9% of Microsoft 365's footprint. Six Eastern platforms (Zoho, Yandex, Mail.ru, Aliyun, 4.cn, Baidu) carry 1,581,223 apexes; Zoho's 1,229,484 is the largest non-Google, non-Microsoft SaaS verification footprint we measure, beating Facebook (1,148,511), Brevo (1,120,202), and every Western productivity SaaS except Google Workspace and Microsoft 365. The 2026 layer of AI-era verifications is already visible: 206,934 OpenAI-verified apexes, an emerging 7-apex Anthropic footprint, and a fast-growing tail of work-tools (Notion 12,915, Zoom 61,135, Calendly).

The Data

DomainsProject performs full-corpus DNS measurement passes against the master hostname dataset. The 17 April 2026 pass produced typed result archives for every common record type. The TXT corpus used in this post:

The corpus queries hostnames as they appear in the master dataset — apex names, common subdomains (www., mail.), and any other hostname the crawler has previously observed resolving. It does not query the synthetic prefixes (_dmarc., _domainkey., _mta-sts., default._bimi.) where DMARC, DKIM, MTA-STS, and BIMI policies live by RFC convention. As a consequence, DMARC, DKIM, MTA-STS, and BIMI cannot be measured cleanly from this corpus, and any number we report about them is the artefact of a small minority of operators publishing those records at the apex (a misconfiguration in most cases). The four signals that can be measured cleanly are: SPF (lives at apex by design — 142.3 million unique apexes), apex-stored vendor verification tokens (the subject of this post — 40.2 million unique apexes), parking and marketplace fingerprints (5.0 million unique apexes), and Kubernetes ExternalDNS heritage markers (41,565 apexes).

Methodology

What "verification token" means in this post. A vendor verification token is a TXT data string with a recognisable vendor-prefixed format that a SaaS vendor instructs the domain owner to add at their apex during onboarding. Examples: google-site-verification=… (Google Search Console / Workspace), MS=ms… (Microsoft 365), facebook-domain-verification=… (Meta), atlassian-domain-verification=… (Atlassian), apple-domain-verification=…, stripe-verification=…, adobe-idp-site-verification=…, zoho-verification=zb…, brevo-code:…, afternic-verification-…, dan-ownership-verification=…. Each prefix maps to exactly one vendor in our classifier. The classifier source is reproduced below in the "Reproducibility" subsection.

Vendors counted, vendors NOT counted. We track 50+ vendor categories that issue apex TXT verification tokens. We deliberately exclude vendors that verify exclusively via CNAME records, subdomain TXT records, or HTML meta tags — Cloudflare (CNAME), Mailgun (CNAME-based DKIM), most of SendGrid's flow (CNAME-based link rewriting and subdomain DKIM), Sectigo / Comodo CNAME-DCV, and the entire CNAME-based Let's Encrypt ACME flow are systematically under-counted here. The 12 SendGrid hits and 12 Mailgun hits we report below are the residual apex-TXT minority of each vendor, not their actual customer footprint. This is the SaaS Map's largest known bias: it measures vendors that use apex TXT verification, not all vendors.

SPF is treated separately. SPF records (v=spf1 …) cover 142,308,762 apexes — by far the largest TXT category — but SPF mechanism includes (include:_spf.google.com, include:spf.protection.outlook.com) reflect email-routing relationships, not vendor adoption. A domain that routes mail through Google Workspace has include:_spf.google.com; a domain that uses Google Search Console has google-site-verification=…; the two populations overlap heavily but are not identical. To keep the question clean — which vendors does this domain trust by name? — we count verification tokens, not SPF includes. A separate companion post will treat the SPF graph as its own object.

Apex extraction. We use the Mozilla Public Suffix List via golang.org/x/net/publicsuffix to compute the registrable apex (eTLD+1) of every queried hostname. mail.foo.co.uk and _acme-challenge.foo.co.uk and foo.co.uk all collapse to foo.co.uk for vendor counting. This corrects a class of error that simpler last-2-label heuristics make on compound suffixes (.co.uk, .com.br, .gov.in, etc.) where the wrong rollup would either over-count or assign the wrong "TLD".

Deduplication. A single apex with multiple matching TXT records for the same vendor (for example, three different Google Search Console properties under one apex) counts once for that vendor's total. Different apexes with the same vendor are independent customers. The unit of analysis is (vendor, apex). Cross-vendor apex counts (a single apex carrying both Google and Microsoft tokens) are dedup-aware in the per-region totals.

Excluded TLDs. Per project policy, we exclude .ru, .su, .moscow, .xn--p1acf, .xn--p1ai, and any apex ending in .yandex from all counts. Yandex as a verification-token vendor is still tracked (Yandex.Webmaster verifies non-.ru domains globally, particularly in Turkey, Kazakhstan, and Belarus); the per-TLD breakdowns in this post simply have no Russian-territorial rows.

Reproducibility. The classifier and aggregator are ~250 lines of Go: a streaming JSONL reader against the typed result archives, a vendor-prefix table, and a PSL-aware apex extractor whose output is piped to sort -u for memory-bounded deduplication. The 17 April 2026 active dataset is publicly available at domainsproject.org/dataset. The TXT-typed crawl is part of the subscriber feed.

Known limitations beyond the CNAME-vendor bias.

• Some apex TXT records are stale — added years ago, the underlying SaaS subscription has long lapsed, but the operator never cleaned up the DNS. This biases all counts upward. Without a rollback to historical TXT-record snapshots we cannot decompose live-customer from stale-token, and we don't try.
• Registrar boilerplate SPF (e.g., v=spf1 ip6:fd1b:212c:a5f9::/48 -all from one large hosting platform's default zone) is counted once per apex regardless of whether the customer actually configured email — this inflates SPF coverage but does not contaminate the vendor-verification counts (which require a vendor-specific prefix).
• The pervasive *1ed6-suffix hash records in the unclassified tail are believed to be Sectigo / Comodo TXT-DCV tokens, but we cannot confirm a stable prefix and therefore do not assign them to a CA in this analysis. GlobalSign — which uses an explicit _globalsign-domain-verification=… prefix — is included with 684,627 apexes and serves as a partial proxy for the TLS-CA-validation layer.
• Unicode normalisation: a small number of Punycode (xn--) apexes are treated as distinct from their Unicode form. We aggregate at the Punycode level (the form actually present in DNS).
• The 51 SendGrid hits, 12 Mailgun hits, and 307 Cloudflare hits should be read as residual misconfigurations — operators who manually pasted a vendor's CNAME instructions into a TXT record. These vendors' real customer footprints are orders of magnitude larger and live in CNAME-typed crawls, which are out of scope for this post.

The Scorecard

The top-level vendor leaderboard. Counts are unique apex domains carrying at least one TXT verification token of the listed format, deduplicated by eTLD+1, with Russian-territorial TLDs removed.

Top 25 vendor verification-token footprints (apex count)

Three findings drop out of the leaderboard immediately. First, Google's 26.0 million is 3.41× Microsoft 365's 7.6 million — a far wider gap than seat-revenue comparisons would suggest, and consistent with Google's having both a search property (Search Console verification, the primary onboarding step for any indexed site) and a productivity property (Workspace verification), where Microsoft has only the productivity property. Second, AfterNic alone — at 4.97 million apexes — is bigger than every non-Big-Two SaaS verification footprint we measure, including Zoho, Facebook, Brevo, and the entire Western productivity tail; the for-sale layer of the public DNS is a top-3 vendor category. Third, Zoho at 1.23 million sits ahead of Facebook (1.15M), Brevo (1.12M), and every Western productivity SaaS except Google and Microsoft — a single Indian platform outweighs the apex footprint of the entire English-language SaaS productivity tail (Atlassian + Apple + DocuSign + Stripe + Adobe + HubSpot + Zoom + Mailchimp + Klaviyo).

Marketplace concentration

Marketplace tokens cover 5.0 million unique apexes — bigger than Atlassian (231K), Stripe (97K), Adobe (73K), Apple (485K), and DocuSign (59K) combined (893,832), and 65.9% of Microsoft 365's verification footprint. AfterNic dominates with 4.97 million apexes and the long-tail Chinese aftermarket (4.cn + Aliyun + west.cn + 17ex) collectively reaches 56,141 apexes — small relative to AfterNic but larger than Sedo by three orders of magnitude. Sedo's 122 apexes here is the residual, not the actual Sedo customer count: Sedo verifies primarily via OAuth/email rather than apex TXT.

East / West split

Western SaaS, dominated by Google and Microsoft, outweighs Eastern SaaS 20.7-to-1 in apex footprint. But the East-West ratio masks a more interesting fact about Zoho specifically: Zoho's 1.23 million apexes is larger than Facebook (1.15M), larger than Brevo (1.12M), and larger than every Western SaaS in our catalogue except Google and Microsoft. Zoho is a single-firm Eastern apex footprint that beats the entire English-language productivity tail, and it does so quietly — Zoho is rarely in the discussion when "the SaaS Map" is sketched in Western trade press.

Google's 3.4× Apex Lead — and Why

Google's 25,988,287 apex tokens versus Microsoft's 7,624,510 yields a 3.41 ratio. The structural explanation has three parts.

Part 1: Search Console is the funnel. Every site that wants to be indexed by Google can verify ownership via Search Console; verification is the precondition for the analytics, sitemap submission, structured-data validation, manual-action review, and search-performance reporting that any operator running a real site eventually wants. Microsoft Bing Webmaster Tools exists and uses a similar TXT verification flow, but Bing's market share never gave it the same gravitational pull, and its verification footprint is small enough that we did not catalogue it as its own vendor.

Part 2: Workspace is the productivity arm. Google Workspace verification is the precondition for binding a custom domain to Gmail, Calendar, Drive, Meet. The exact verification flow generates a google-site-verification=… TXT token at the apex. Microsoft 365 verification is the analogous precondition for binding a custom domain to Exchange / Outlook / Teams, and generates an MS=ms… token at the apex. The asymmetry is that the Search Console population and the Workspace population are both Google — both verifications use the same google-site-verification=… prefix — so one Google verification record at the apex covers both flows. Microsoft has no search-engine analogue inside its verification namespace.

Part 3: SMB and individual-blog adoption. The long tail of small-business and individual-blog domains skews dramatically toward Google. WordPress.com properties bind their custom domains via Google verification. SquareSpace properties bind via Google verification. The "I just bought a domain and want to be findable" workflow is universally Google. Microsoft 365 reaches this segment via the Microsoft Domains hosting product but at much lower scale.

The per-TLD breakdown reinforces the asymmetry. Google's footprint is 53% on .com (13.77M), with the remainder spread across all of .org (964K), .de (697K), .net (646K), .co.uk (643K), .fr (500K), .com.br (417K), .com.au (393K), .co (376K), and .info (338K). Microsoft 365's footprint is more concentrated in business-friendly enterprise jurisdictions: 42% on .com (3.23M), then .de (382K), .co.uk (360K), .nl (300K), .com.au (281K), .org (260K), .net (198K), .fr (174K), .ca (139K), .ch (120K). Microsoft's .nl density is striking — 300K Netherlands apexes is more than 4× Microsoft's .fr footprint despite the Netherlands being one-quarter France's population — and is consistent with industry reports of heavy Microsoft 365 adoption in the Dutch enterprise market.

The Marketplace Layer: For-Sale Domains as a Top-Three SaaS Category

Of the eight marketplace fingerprints we track, AfterNic dominates with 4,973,495 unique apexes — larger than every non-Big-Two SaaS verification footprint we measure. dan.com (acquired by Squarespace in 2022, originally Undeveloped) is the second largest at 400,205. The Chinese aftermarket cluster — 4.cn (21,477), DomainEasy (25,216), Aliyun's domainov.aliyun.com listing fingerprint (15,263), west.cn (9,856), and 17ex.com (9,545) — collectively reaches 81,357 apexes. Sedo, despite being one of the largest aftermarket platforms by completed-sale volume, has only 122 apex-TXT verification fingerprints because Sedo onboards primarily through OAuth or email confirmation; its TXT footprint is a small minority of its actual listing book.

The aftermarket layer is 5.03 million apexes — 12.4% of the total tracked-vendor-token apex population, and a top-three vendor category in its own right. That is a much larger share than most discussions of "the SaaS Map" assume. Anyone reasoning about the apex footprint of the public DNS who omits the for-sale layer is missing more domains than every Western SaaS combined except Google and Microsoft.

The per-TLD breakdown for AfterNic is extreme. 80% of AfterNic listings are on .com (3.97M of 4.97M), with .de a distant second at 413K. The implication: the speculative-aftermarket population of the public DNS is overwhelmingly a .com phenomenon, in line with .com's premium-domain price floor and resale liquidity. Western European ccTLDs (.de, .nl, .fr, .co.uk) appear at small but non-trivial rates; Chinese ccTLDs (.cn) appear at 15,520 — small in absolute terms but indicating that Chinese aftermarket flow does cross-list into AfterNic's distribution network.

The Eastern Belt: Zoho's Outlier Lead, Yandex's Quiet Globalisation

Zoho's 1,229,484 apex footprint is the single most surprising finding in the dataset. The Indian-headquartered office-suite vendor sits ahead of Facebook (1.15M), Brevo (1.12M), Apple (485K), Atlassian (231K), Stripe (97K), Adobe (73K), and every other Western SaaS in our catalogue except Google and Microsoft 365. Zoho's per-TLD distribution shows where: 662K on .com, 56K on .com.br (Brazil — Zoho's second-largest market by apex), 53K on .in and 11K on .co.in (India, the home market, ~64K combined), 34K on .org, 29K on .net, 28K on .co.uk, 16K each on .co and .ca, 15K on .com.au. Brazil at 56K is, surprisingly, roughly Zoho's home-market apex footprint — consistent with Zoho's heavy localisation push in Latin America starting in the mid-2010s and the company's Brazilian tax-and-CRM compliance offerings.

Yandex's 305,479 apex footprint is the second-largest Eastern signal, and its per-TLD distribution is the giveaway that Yandex is not purely a Russian platform: 114K on .com, 17K on .top, 12K on .com.tr (Turkey — the largest non-Russian market for Yandex), 10K on .com.cn (China), 7K on .org, 7K on .buzz, 7K on .by (Belarus), 7K on .pro, 6K on .kz (Kazakhstan). Yandex.Webmaster verification is global; the platform's appearance under apex-TXT verification on .com.tr, .kz, and .by reflects Yandex's residual SEO presence across the Russophone-extended world. Turkey is Yandex's largest non-Russian apex base by a wide margin, consistent with Yandex's 2017 Turkey-search investment and the platform's local-language indexing strength there.

Mail.ru's 58,806 apexes is dominated by .com global registrations and is the smallest of the three Eastern leaders. The Chinese aftermarket cluster (Aliyun, 4.cn, west.cn, 17ex) is large in number of platforms but small in apex count per platform, and is dominated by .cn and .com.cn apexes that the public crawler has more limited reach into.

The 2026 Layer: AI-Era Verifications Are Already Visible

The newest entries in the SaaS Map are AI vendors and modern work tools. OpenAI's openai-domain-verification=… token covers 206,934 apexes as of 17 April 2026 — already larger than Pinterest (175K), Mailchimp (80K), Adobe (73K), Amazon SES (69K), Zoom (61K), DocuSign (59K), and HubSpot (57K). Per-TLD: 108K on .com, 6K each on .org, .de, .net; 4,556 on .ai (the highest concentration of OpenAI verifications on a single non-.com TLD by a wide margin); 3,557 on .io. The signal is recursive: AI startups buy .ai domains and verify with OpenAI, producing a measurable correlation between TLD and vendor.

Anthropic's anthropic-domain-verification=… token is at 7 apexes — emerging but already non-zero in our crawl. Notion (12,915 apexes), Zoom (61,135), Calendly (in the long tail), Loom (in the long tail), Asana (2 apexes), Intercom (1 apex) round out the modern work-tools layer. These are small numbers in absolute terms but represent the leading edge of the SaaS Map's evolution. The same crawl run a year from now will show the AI vendors growing into the same range as the legacy stack.

What's at Stake

• Public market-share numbers don't measure the apex. Microsoft 365's 446 million paid seats and Google Workspace's 150-million-plus paid users are seat-level claims that don't translate cleanly into domain-level reach. A SaaS census from DNS gives a different and arguably more decision-relevant view: who actually controls the apex.
• Marketplaces are a top-three vendor category. Domain marketplaces aren't usually grouped with productivity SaaS, but at the apex level they're bigger than Atlassian, Stripe, Adobe, Apple, and DocuSign verification tokens combined. Anyone reasoning about "the SaaS Map" who omits the for-sale layer is missing several million domains of the picture.
• Eastern platforms have a smaller but distinct apex footprint. Zoho's 1.23M is larger than every Western SaaS verification footprint we measure except Google and Microsoft. The dominant pattern in DNS is not Western monoculture but a layered map with regional pockets — most visibly Zoho in India and Brazil, Yandex in Turkey and Kazakhstan, Aliyun and 4.cn in China.
• Stale verification tokens are a security and procurement-hygiene problem. Every old vendor token is a record of a relationship that may or may not still be active; for some, it's an active vector — an attacker who compromises the verification flow can re-establish access. DNS hygiene tooling is underdeveloped relative to the size of the problem (40.2 million apexes carrying at least one vendor token).
• The CNAME shift will erode this measurement. Cloudflare, Mailgun, parts of SendGrid, Sectigo's CNAME-DCV, and the entire ACME-DNS-01 flow already verify via CNAME instead of apex TXT. The vendor population we can measure from TXT alone will shrink each year unless the measurement extends to CNAME-typed crawls.

What Would Help

1. Researchers: extend the catalogue. The classifier in this post tracks 50+ vendor prefix patterns. There are at least another hundred SaaS verification formats in the public wild that we did not track (Salesforce, Workday, ServiceNow's _global_domain_verification, AWS WorkMail, Smartsheet, Box, Dropbox-team, Google Cloud Identity, etc.). A community-maintained catalogue of vendor TXT prefixes would meaningfully extend reproducible SaaS-census research.

2. Vendors: standardise the verification format. Today every vendor invents its own prefix syntax (vendor-domain-verification=, vendor-site-verification=, vendor-verify=, vendor=, vendor:, etc.). A single registered prefix scheme with vendor-namespace tags — analogous to how DKIM selectors namespace email-auth keys — would let domain operators clean up DNS programmatically and would make abuse-monitoring dramatically more tractable.

3. Registrars and DNS panels: surface stale verification tokens. Domain owners rarely audit their TXT records. A "tokens older than two years" UI in registrar control panels would close the largest hygiene gap in the dataset. The classifier source for this post is short enough to embed in any DNS-management product.

4. CAs: complete the migration to CNAME-DCV. TXT-DCV at the apex creates a meaningful risk vector (every CA's tokens are temporary but live in the apex during the issuance window). CNAME-DCV moves the validation point to a vendor-controlled subdomain and shrinks the blast radius of an apex compromise. The CA / Browser Forum's April 2025 ballot SC-70 already shortens the domain-reuse period from 398 days to 10 days by 2028; the same instinct argues for moving validation off the apex entirely.

5. Investors and analysts: read the apex map alongside the seat number. A SaaS vendor with a low apex-footprint-to-seat-revenue ratio is seat-dense (a few large enterprise customers each carrying many seats) — Microsoft 365's 7.6M apexes against 446M seats is ~58 seats per apex, a clear enterprise-density signal. A vendor with a high apex-footprint-to-seat-or-customer ratio is long-tail — Google's 26.0M apexes against the company's reported "billions of users" implies the long-tail individual-blog and SMB segment is the gravity well. Brevo's 1.12M apexes against the company's reported 600K customers shows roughly 1.87 apexes per Brevo customer — small businesses run multiple verified domains. The SaaS Map is the public-data input to that analysis.

This analysis used the 17 April 2026 DNS TXT crawl from the DomainsProject pipeline (3,105 result archives, 840 GB of raw JSONL / 56 GB after xz compression, ~1.9 billion hostname queries) classified against a catalogue of 50+ apex-TXT vendor verification formats and deduplicated to eTLD+1 via the Mozilla Public Suffix List. Russian-territorial TLDs (.ru, .su, .moscow, .xn--p1acf, .xn--p1ai) and the .yandex brand TLD are excluded from all counts per project policy. The full master corpus and the 17 April 2026 active crawl are documented at /stats/ and /dataset. Companion posts on SPF (the State of SPF), parking fingerprints (The Parking Lot Index), and the Kubernetes ExternalDNS census follow this one.