95 vendors, identified from public DNS alone

A domain-verification TXT record exists for one reason: to prove to a vendor, once, that whoever controls the DNS also controls the account. An SPF include: mechanism exists for a different but related reason: to tell every mail server on the internet which third parties are allowed to send email as this domain. Neither is written for us. Both are, by construction, a company telling someone else exactly which vendor it uses — and because DNS is public, reading it back is not a guess. It's the same lookup a mail server performs before delivering a message, decoding a relationship the company already declared, not inferring one.

We ran that lookup against every domain in our FTSE 100, FTSE 250 and S&P 500 catalog that has DNS data collected — 177 companies — and classified what came back against roughly 120 known verification-token and SPF-host patterns.

The vendor census

Three products dominate: a Google Workspace or Search Console verification token, a Microsoft 365 token, or both, together account for more identified relationships than the next eight vendors combined.

Full ranking, all 95 vendors: vendor footprint comparison.

One number worth a caveat rather than a headline: 87 of the 173 companies with any vendor identified signal both Microsoft 365 and Google Workspace. That's a striking overlap, but a verification token doesn't expire when a company stops using the service — it sits in DNS until someone deliberately removes it. Some of that 87 is live dual-vendor use. Some of it is a pilot from three years ago, or the DNS footprint of a company Microsoft or Google's own tenant acquired along the way, that nobody has ever cleaned up.

Security tooling: the more useful census

A productivity-suite token tells you what everyone already assumes. A security-vendor token tells you something closer to what the company's actual defensive posture looks like — and for a platform built for security professionals, it's the more interesting list.

The ten companies running a HackerOne verification are, by definition, the ten that have committed to a public or private vulnerability disclosure programme — a fact that's otherwise scattered across individual security.txt files and bug-bounty platform listings, not collected anywhere as a single list. The presence of Wiz or Palo Alto Networks doesn't confirm how well either is configured, but it does confirm the company has budget and headcount pointed at cloud posture and network security specifically, which is not nothing.

What DNS reveals by accident

Most of what a TXT record scan turns up is exactly what it claims to be. A handful of records aren't, and those are more interesting than the census.

Eli Lilly published a copy-paste error, not a DKIM key. Their domain carries a TXT record whose entire content is "Avid_lilly._domainkey" "IN" "TXT" "v=DKIM1;" "h=sha256;" "k=rsa;" "s=AvidLilly2022;" "MIGfMA0GCS..." — the record name, class and type, included as literal text, followed by the key. Someone pasted the output of a zone-file lookup into the value of a TXT record instead of publishing the key at the hostname it names. We checked this directly against a DNS resolver, independent of our own collection code, to rule out a parsing artifact on our end. It's genuinely published this way. Whatever mail server is supposed to verify signatures from selector Avid_lilly won't find this copy; it isn't at the address DKIM verification actually checks.

BT Group is running at least five separate Salesforce orgs. One TXT record lists five semicolon-separated 00D…-prefixed identifiers — Salesforce's own Organization ID format — and the record appears to cut off mid-value, so there may be more than five. Salesforce org sprawl inside a company that size isn't shocking on its own, but having it enumerable from outside, for free, is a reminder of how much structure a TXT record can carry once verification tooling from a dozen different products each adds one.

British American Tobacco has a DKIM public key sitting at the wrong hostname — a p=MIIBIjAN… RSA key published at the domain apex rather than at the <selector>._domainkey subdomain DKIM verification actually queries. Same failure mode as Eli Lilly's, different shape: a real cryptographic key, publicly visible, doing nothing.

The same half-finished SPF edit shows up at two unrelated companies. Both Zscaler and Haleon have a bare include:… fragment sitting as its own standalone TXT record, never folded into their actual SPF line. It's a plausible-looking mistake to make once — copy the new vendor's include: snippet from an onboarding email, paste it as a new record instead of editing the existing SPF string — and here it is independently, twice, which suggests it's a mistake the tooling or the process makes easy rather than one specific person's error.

Nine FTSE 100 / S&P 500 companies publish no SPF record at their primary domain at all: Burberry, Caterpillar, Coca-Cola Europacific Partners, Hiscox, IHG Hotels & Resorts, Lion Finance Group, Lloyds Banking Group, Scottish Mortgage Investment Trust and Weir. Lloyds is the one that stands out for the sector. This checks the apex domain only — a company can enforce SPF correctly at a specific mail-sending subdomain instead and simply have nothing published at the bare domain, so absence here is a prompt to look closer, not a finding on its own.

And one that isn't a mistake, just a leak. AstraZeneca's Amazon SES verification token embeds [email protected] as its own identifier — naming a specific internal mailing product that has no other public footprint. Nobody meant to publish that name. The verification mechanism just needed somewhere to put a unique string, and a real, human-chosen identifier was the string someone reached for.

None of this touched DMARC report-recipient addresses, which are a different field and, unlike everything above, can carry personal data — see the separate assessment before treating that category the same way. Full vendor list, every company, every category: vendor footprint comparison. Full ruleset: vendor_txt_classify.py.