What One Domain Reveals

What do DNS TXT records reveal about a company?

By · July 11, 2026 · 6 min read

DNS TXT records reveal a company's email-sending infrastructure and the SaaS tools it verified. SPF includes name every authorized sender, DMARC names the policy and reporting vendor, and verification tokens (google-site-verification, atlassian, facebook) each map to a product the company set up. Bassethound reads them in the infrastructure layer of the five-layer dossier, in one call.

Best move: treat the TXT record set as a public inventory of every vendor a company authorized to act for its domain.

Why it works: a company only adds a TXT record when a vendor tells it to. SPF includes, DMARC reports, and verification strings each name a live integration, and DNS returns them to anyone who asks.

Key takeaways

  • TXT records are public. Any resolver returns them with no auth, no key, and no rate gate on the DNS itself.
  • An SPF record’s include: mechanisms name every third party allowed to send mail as the domain, which reveals the ESP and marketing stack.
  • Verification tokens (google-site-verification, facebook-domain-verification, atlassian-domain-verification, MS=) each map to one SaaS product a human set up.
  • A DMARC record exposes the enforcement policy (none / quarantine / reject) and the rua address, which often names a DMARC processing vendor.
  • Bassethound parses the full TXT set in the infrastructure layer, correlated with MX and the tech stack, so a dead token cannot pose as a live one.

What do domain verification tokens give away?

When a company adopts a SaaS product that needs proof of domain ownership, the vendor hands it a string to drop in a TXT record. google-site-verification means a Google service (Search Console, Workspace, Ads). facebook-domain-verification means Meta commerce or ads. atlassian-domain-verification means Jira or Confluence. MS= means Microsoft 365. The list runs long: Stripe, DocuSign, Adobe, Zoom, Notion, Miro, Apple, and _amazonses for SES.

Each token is a fingerprint of one product decision. Read the full TXT set and you assemble a partial map of the company’s software. The signal quality is high because the evidence is opt-in. A person opened DNS and pasted the string to make a product work, which beats a script tag anyone could copy or a marketing page anyone could write. Nobody adds a verification token by accident.

The catch is staleness. Tokens linger long after a company stops paying for the tool, and DNS almost never gets cleaned. So count each token as a lead, not a receipt, and confirm it against a live signal before you trust it.

How does an SPF record expose the email stack?

An SPF record starts with v=spf1 and lists mechanisms that authorize senders. The include: entries are the interesting part, because each one names a service that sends mail for the domain. include:_spf.google.com is Google Workspace. include:spf.protection.outlook.com is Microsoft 365. Then the transactional and marketing layer shows up: include:sendgrid.net, include:mailgun.org, include:amazonses.com, include:servers.mcsv.net (Mailchimp), include:_spf.salesforce.com, include:spf.mandrillapp.com.

That is the outbound half of the email stack, spelled out in one record. Transactional, marketing, CRM, and support senders all declare themselves so their mail passes authentication. Chained includes expand to more hosts, so a short record can unfold into a long sender list.

Read the tail of the record for posture. -all is a hard fail (strict), ~all is a soft fail (lenient), ?all is neutral. A company on -all with a tidy include list runs email on purpose. A sprawling record near the 10-lookup limit is a company that bolted on tools over years. SPF is faster and cleaner than inferring the stack from MX alone, because MX shows only who receives mail, while SPF shows who sends it.

What does a DMARC record tell you?

DMARC lives at _dmarc.<domain> as its own TXT record, and it leaks two things at once: a security posture and a vendor relationship. The p= field gives the policy. none means monitor only, quarantine means suspect mail goes to spam, and reject means fail closed. That single value tells you how mature the company’s email security is. A brand on p=reject has done real work. A brand on p=none set DMARC up and moved on.

The rua= field gives the aggregate-report mailbox, and it frequently points at a DMARC processor. rua=mailto:...@dmarc.postmarkapp.com is Postmark. Addresses at rua.dmarcian.com, Valimail, or Agari name the vendor the company pays to read its DMARC reports. So one record hands you the enforcement level and a paid relationship in the same string.

The sp= (subdomain policy) and pct= (rollout percentage) fields add nuance about how far the company has taken enforcement. A domain on p=reject, sp=reject, pct=100, with a named processor is a company that invested in deliverability and knows why. Read alongside the SPF record, DMARC fills in how seriously the company runs email.

Where do TXT records stop being reliable?

Be honest about the gaps. A TXT record proves a tool was configured once, not that it is live today. Verification tokens outlive the products that placed them, so a docusign or atlassian string can name a vendor the company dropped two years ago. Treat every token as a lead and corroborate it against a live signal: a loaded client script, the MX host, a response header.

DKIM adds a second gap. Keys live at selector._domainkey.<domain>, and you need the selector to fetch the key. Common selectors (google, k1, s1, default, selector1, selector2) are guessable, but a custom selector hides the key from a blind lookup. SPF carries its own noise: flattening and macros can obscure the true sender list, and chained includes can blow past the 10-lookup limit and break silently.

And TXT tells you nothing about server-side integrations that never touch DNS. A payment processor called from the backend, an internal API, a proxied service: none of them leave a TXT trail. The record set opens the investigation. It does not close it. Any tool that reports TXT signals as certainty is overselling.

How do TXT records sharpen the rest of the dossier?

On their own, TXT records are a list. Fused with the other four layers, they become a picture. An include:sendgrid.net in SPF, plus a SendGrid client in the tech stack, plus a support contact in the firmographics, tells you where and how the company runs email and who owns it. A google-site-verification token, plus Google Analytics in the loaded scripts, plus a Workspace MX record, confirms a Google shop three ways instead of guessing once.

That correlation is the moat. Five separate lookups (WhoisXML for DNS, BuiltWith for the tech stack, Apollo for firmographics) hand you five disconnected lists and leave the join to you. The agent that fans out to five MCPs still has to reconcile them, and reconciliation is the expensive part. Bassethound performs the join inside one call and reports which signals agree and which conflict.

The conflict handling is where it earns its keep. When no live signal backs a verification token, Bassethound marks it stale instead of scoring it as a hit. A DMARC rua vendor confirms an email-security posture the SPF record only hinted at. One read, five layers, cross-checked.

Bassethound perspective

Most tools that touch DNS stop at retrieval. WhoisXML and DomainTools hand you the raw TXT strings and call it a feature. The firmographic vendors go the other way: Apollo and ZoomInfo sell you a contact record scraped from somewhere else and never query the domain at all. Both leave the interesting work undone.

A verification token beats a tracking pixel as a buying signal, and the reason is friction. A pixel loads because someone dropped a tag once. A token exists because someone logged into a vendor, hit a wall demanding proof of ownership, opened DNS, and pasted a string to clear it. The more work a company put into standing a tool up, the more it leans on that tool day to day. Rank the TXT set by effort and you read a company’s load-bearing software straight off its DNS.

Staleness is the honest caveat, and Bassethound prints it in the dossier: a token records a setup, not a live subscription. So the tool names the vendor, then checks that vendor against the tech stack and the MX host in the same call. It marks any token no other layer confirms as stale. That cross-check is what a single-layer lookup cannot sell you, because it has nothing to check against.

Sources

Frequently asked questions

Are DNS TXT records public?

Yes. Any resolver returns them with no auth, no key, and no account. A TXT lookup is one of the cheapest signals you can pull on a company.

Can a TXT verification token be stale?

Often. A token proves a tool was set up once, not that it is still in use. Nobody cleans DNS after churn, so treat each token as a lead and corroborate it against a live signal.

Do TXT records show which email provider a company uses?

Partly. The SPF record's include mechanisms name every service authorized to send mail for the domain, which reveals the ESP and marketing stack. The MX record confirms the inbound provider.

Can you read a company's DKIM keys from TXT records?

Yes, but you need the selector. DKIM keys live at selector._domainkey.<domain>. Common selectors (google, s1, default, selector1) are guessable. A custom selector hides the key.

Does Bassethound read TXT records?

Yes. TXT parsing sits in the infrastructure layer of the five-layer dossier, correlated with the MX record, the tech stack, and the TLS certificate in a single call.

Keep reading

Sniff a domain.

Run sniff_domain on any site and read its five-layer dossier in one call.

Sniff a domain