What One Domain Reveals
How do you find a company's SaaS stack from its DNS?
You find a company's SaaS stack in DNS by reading the records vendors make you publish. MX names the email provider, SPF includes name every authorized sender, verification TXT tokens map one-to-one to products, and CNAMEs point support and status subdomains at their SaaS host. Bassethound reads all of them in the infrastructure layer of the five-layer dossier, in a single call.
Best move: read the TXT and MX records first, then the CNAMEs. Verification tokens and SPF includes name the vendors for you.
Why it works: SaaS onboarding makes you publish DNS records to prove you own the domain and to route mail. Those records name the vendor, and they outlive marketing copy.
Key takeaways
- DNS enumeration finds SaaS without crawling the site: MX, TXT, CNAME, DKIM, and DMARC records each name vendors.
- Domain-verification TXT tokens (google-site-verification, atlassian-domain-verification, docusign=, stripe-verification=) map one-to-one to the product that asked for them.
- SPF include mechanisms list every service authorized to send mail as the domain (sendgrid.net, mailgun.org, servers.mcsv.net, _spf.salesforce.com).
- CNAME subdomains reveal customer-facing SaaS: support points at Zendesk, status at Statuspage, help at Intercom.
- DNS signals are server-side and stable, so they survive when the front end is a proxied SPA that a static crawler cannot read.
Which DNS records name a SaaS vendor?
Five record types do most of the work. MX records route mail, so they name the email provider: aspmx.l.google.com is Google Workspace, mail.protection.outlook.com is Microsoft 365, and dedicated hosts point at Proofpoint or Mimecast. TXT records carry two payloads worth reading: SPF policies and verification tokens. NS records name the managed DNS operator (Cloudflare, Route 53, NS1). CNAME records on subdomains point customer-facing tools at their host, so support.example.com resolving to a Zendesk domain is a Zendesk deployment, not a guess. DKIM selector records under _domainkey expose signing vendors.
Read together, these give you an email stack, a DNS operator, and a set of front-office SaaS tools without touching a single page of HTML. The catch is coverage. DNS names the vendors a company had to register with DNS, not the ones it embeds only in JavaScript. A payment widget or analytics tag lives in the page, not the zone file. So DNS is the first pass: strong on infrastructure and email, quiet on browser-side tooling.
What do SPF includes and DKIM selectors tell you?
An SPF record lists every service authorized to send mail as the domain. Each include mechanism names a vendor. _spf.google.com for Google, sendgrid.net for SendGrid, mailgun.org for Mailgun, servers.mcsv.net for Mailchimp, _spf.salesforce.com for Salesforce, spf.protection.outlook.com for Microsoft. One SPF record can expose the transactional-mail provider, the marketing-mail platform, and the CRM in a single line.
DKIM selectors add confirmation. The selector name under _domainkey is vendor-specific: google._domainkey for Google, selector1 and selector2 for Microsoft, s1._domainkey and s2._domainkey for SendGrid, k1._domainkey for Mandrill and Mailchimp, pm._domainkey for Postmark. Where SPF tells you who is allowed to send, DKIM tells you who signs, which narrows a broad SPF list to the platforms in live use. DMARC extends the trail: the rua and ruf tags carry report addresses, and a rua pointing at dmarc.postmarkapp.com or a Valimail host names the deliverability vendor managing the domain.
None of this needs a crawl. The limit is that SPF authorizes senders it may no longer use, so treat an include as evidence a service was set up, and lean on DKIM and live headers to confirm it still sends.
How do domain-verification TXT tokens map to products?
Verification tokens are the cleanest signal in DNS because they are one-to-one. When a SaaS product needs to prove you control a domain, it tells you to publish a TXT record with a prefix it owns. That prefix names the product. google-site-verification is Google Search Console or Workspace. MS= and facebook-domain-verification are Microsoft and Meta. atlassian-domain-verification is Jira or Confluence. adobe-idp-site-verification is Adobe. docusign= is DocuSign. stripe-verification= is Stripe. There is no ambiguity. The company added that record because that vendor asked for it.
Collect the tokens and you have a list of products the company connected to its primary domain, which skews toward the tools it treats as core. Tokens do age. A team can drop a vendor and leave the record behind, so a token proves a relationship existed, not that it runs today. But the false-positive rate is low, because nobody adds a docusign= record by accident. For firmographic and ICP work, the token set is one of the highest-signal, lowest-noise reads in the whole zone, and it costs one DNS query.
What can DNS not tell you about the SaaS stack?
DNS is strong on infrastructure and blind on the browser. It names the email provider, the DNS operator, verified vendors, and any SaaS given a subdomain. The client-side stack stays dark. Analytics tags, payment widgets, chat launchers, and JavaScript SDKs render in the browser, so a company can run Segment, Stripe Checkout, and Intercom without a single DNS record naming any of them.
DNS also lies by omission in the other direction. A verification token or SPF include can outlive the tool that created it, so the zone shows relationships a company once set up, not always ones it still uses. And DNS cannot see anything a reverse proxy hides: if a vendor sits behind the company’s own hostname with no dedicated CNAME, the zone looks quiet.
This is why DNS is one layer, not the whole read. You pair the zone read with a front-end crawl. DNS gives you email, infrastructure, and verified integrations; the crawl gives you the client-side stack. Correlate the two and you cover far more than either does alone. Reporting the gap matters as much as reporting the hits.
Bassethound perspective
Most tools split this work in two. A tech-stack scanner (BuiltWith, Wappalyzer) reads the front end and skips the zone. An infra tool (WhoisXML, Censys, DomainTools) reads DNS and skips the page. You run two products and stitch the results yourself, and the stitch is where the signal is. A SendGrid SPF include means more when you can see the Vercel front end and the Anthropic SDK in the same dossier: now it is a shipping company with real infrastructure, not a parked domain.
That correlation is the point. Bassethound puts the DNS read (MX, TXT vendors, SPF/DKIM/DMARC, nameservers) in the infrastructure layer, next to the tech stack, firmographics, AI-readiness, and security layers, and returns all five from one keyless call. An agent cannot cheaply reproduce that by fanning out to five separate MCPs, because the value is in the join, not the rows. We are honest about the seam: DNS misses browser-side SaaS, tokens age, and proxied vendors hide. The dossier says what it could not reach. But the zone is the cheapest high-signal read on the internet, and it belongs next to everything else, not in its own silo.
Sources
- SPF, RFC 7208: https://datatracker.ietf.org/doc/html/rfc7208
- DKIM, RFC 6376: https://datatracker.ietf.org/doc/html/rfc6376
- DMARC, RFC 7489: https://datatracker.ietf.org/doc/html/rfc7489
- DNS glossary, MDN: https://developer.mozilla.org/en-US/docs/Glossary/DNS
Frequently asked questions
Can you find the SaaS stack from DNS without crawling the website?
Yes for the infrastructure and email layers. MX, SPF, DKIM, DMARC, verification TXT tokens, and CNAME subdomains all resolve without loading a page. Browser-side tools (analytics, payment widgets, chat) live in the page, not the zone, so those still need a crawl.
Which DNS record is the strongest SaaS signal?
Domain-verification TXT tokens. They map one-to-one to a product (docusign=, atlassian-domain-verification, stripe-verification=), because the vendor told the company to add exactly that record.
Do SPF includes prove a company still uses a vendor?
No. SPF authorizes a sender, which can outlive live use. Treat an include as evidence the integration was set up, then confirm with DKIM selectors and live mail headers.
How do you tell Google Workspace from Microsoft 365 in DNS?
MX records. Google routes to aspmx.l.google.com, Microsoft to mail.protection.outlook.com. DKIM selectors confirm it: google._domainkey versus selector1 and selector2._domainkey.
What SaaS does DNS miss?
Anything client-side. Analytics tags, payment widgets, chat launchers, and JavaScript SDKs load in the browser and leave no DNS record. Bassethound pairs the zone read with a front-end crawl and reports what each could not reach.