Cold Email8 min read

The Free Tech-Stack Lookup Nobody Uses: What a Prospect's DNS TXT Records Reveal

Companies publish their tool choices in public DNS every day — support desk, CRM, billing, dev stack — because their email would break otherwise. Across 623,370 top-1M domains with SPF, that self-reported technographic data is one command away.

SDR teams pay real money for technographic data — which CRM a prospect runs, which support desk, which billing system. Meanwhile, every company that wants its tools to send email on its behalf must declare those tools in a public DNS TXT record, or the mail gets rejected. The result is a free, always-current, self-maintained technographic database that almost nobody in sales bothers to read.

The scale is not niche. In our daily scan of the Tranco top-1M (623,370 domains publish SPF as of the 2026-07-05 snapshot), Zendesk appears in 3.87% of SPF records and Salesforce in 2.62% — and Salesforce has added 1.51 percentage points since 2016. Those are declarations, by the companies themselves, that they run those exact platforms.

Two kinds of signal in one record type

SPF includes: who sends email for them

SPF is a TXT record listing every service authorised to send mail as the domain. Each include: names a vendor:

$ dig +short TXT prospect-company.com
"v=spf1 include:_spf.google.com include:mail.zendesk.com
 include:_spf.salesforce.com include:sendgrid.net ~all"

Read it like a stack diagram: Google Workspace for human mail, Zendesk for support, Salesforce for CRM-driven sends, SendGrid for product notifications. Four tools, four budget lines, four conversations you could open — from one DNS response. Our SPF-reading guide for SDRs goes deeper on interpreting the sending stack itself.

Verification tokens: what else they signed up for

The same TXT query returns domain-ownership proofs that vendors ask customers to publish — and that customers almost never delete. Our scanner recognises roughly 70 token patterns; common ones include:

Common TXT verification tokens and what they imply
Token patternImplies
google-site-verification=…Google Workspace, Search Console or other Google services
MS=ms…Microsoft 365 tenant verification
atlassian-domain-verification=…Jira / Confluence — an engineering or IT org on Atlassian
stripe-verification=…Stripe payments — they charge customers online

Stacked together, these tokens give what we call SaaS density: a one-glance read on how many cloud tools a company has wired into its domain. High density signals a modern buyer with procurement muscle; near-zero density on a sizeable company signals either on-prem culture or an IT bottleneck — both useful to know before you pitch a SaaS product.

The trend: tool sprawl is visible from orbit

0%2%4%20172018201920202021202220232024202520263.87%Zendesk2.62%Salesforce
Share of Tranco top-1M SPF domains authorising Zendesk and Salesforce senders, 2016–2026. Source: our daily OpenINTEL-based scan of the Tranco top-1M.

Zendesk grew from 3.05% to 3.87% and Salesforce from 1.11% to 2.62% over the dataset's decade — every step of it declared in public DNS. The same method surfaces security tooling too: KnowBe4 phishing-training senders now appear in 0.56% of SPF domains, a maturity signal we unpack in a dedicated article.

From record to relevance: using it without being creepy

The line between research and surveillance is how you use it. Nobody wants to read "I noticed your DNS records mention Zendesk." The lookup should shape your hypothesis, not your opening line:

  • Sell into support? A Zendesk include tells you the incumbent, the org chart implication (there is a support team), and the migration angle — without one discovery question.
  • Sell dev tools? An Atlassian verification token means engineering coordination happens in Jira. Pitch the integration, not the category.
  • Sell payments or fintech? A Stripe token confirms online revenue flows. A missing one at an e-commerce company is its own conversation starter.
  • Qualify out. If the SPF shows a competitor they adopted last quarter (TXT records are current, unlike stale databases), spend your touch elsewhere.
Ethics and accuracy

TXT lookups are ordinary public DNS queries — the prospect is not contacted or notified, and reading them is exactly what every mail server does before accepting a message. Two accuracy caveats: leftover tokens can outlive a cancelled subscription, and SPF flattening (publishing raw IPs instead of includes) hides some vendors. Treat DNS as strong evidence, not proof.

At list scale, batch the queries the same way you batch MX lookups and store the extracted vendors as CRM fields. For the aggregate picture — which tools are growing across a million domains, and where your ICP's stack is heading — the daily email infrastructure report publishes the full SPF-derived vendor breakdown, updated every night. And once the research shapes a sharper email, verify the last mile: test where your own messages land before the sequence goes live.

FAQ

Yes. DNS is a public directory; TXT records exist precisely so that third parties can read them. Every mail server queries them millions of times a day. You are reading information the company deliberately published.

How fresh is DNS-based technographic data compared to paid tools?

Usually fresher for additions: a company must publish the SPF include before the new tool can send mail, so DNS often leads databases by weeks. Removals lag — teams rarely clean up records for tools they dropped, so cross-check anything that matters.

What if a domain's SPF is just a list of IP addresses?

That is SPF flattening — the includes were resolved to raw IPs, usually by a DMARC vendor's tooling. The vendors are still there but no longer named, so DNS-based detection undercounts them. Note that flattening itself signals a mature email operation.

Can I automate TXT lookups across a 10,000-domain list?

Yes — any DNS library or a shell loop over dig handles it in minutes; use a caching resolver and reasonable rate limits. Parse out include: mechanisms and known token prefixes, and store vendors as structured fields for segmentation.
Related reading
Found this useful? Share it
AB
About the author
Artem Berezin
B2B Deliverability Specialist

B2B deliverability specialist with 5+ years of hands-on outreach experience. Built campaigns reaching 90,000+ inboxes across 20+ countries — and fixed the deliverability problems that came with that scale.

Check your deliverability across 20+ providers

Gmail, Outlook, Yahoo, Mail.ru, Yandex, GMX, ProtonMail and more. Real inbox screenshots, SPF/DKIM/DMARC, spam engine verdicts. Free, no signup.

Run Free Test →

Unlimited tests · 20+ seed mailboxes · Live results · No account required