We Scanned Fortune 500 DNS TXT Records. Here's What They Expose

DNS is often thought of as little more than a way to route traffic, but modern domains rely on far more than just A, AAAA, and CNAME records.

TXT records stopped being niche a long time ago. In fact, in a large-scale analysis of one million domains published by APNIC, more than half of all domains exposed at least one TXT record, with many publishing multiple entries used for configuration and verification. What that research highlights at an internet-wide level becomes far more concrete at the enterprise level, where TXT records often map directly to internal tooling, vendors, and long-lived operational decisions.

At the same time, phishing remains the dominant initial access vector for cyberattacks, with over 90 percent of successful breaches starting from a phishing email, according to multiple industry reports. Since email authentication and sender trust are implemented at the DNS layer, email-related DNS signals become particularly relevant for security analysis.

In this research, we examined DNS TXT records across Fortune 500 domains to understand what these email and service-related DNS signals expose at the DNS layer. Without touching subdomains, web content, or authenticated systems, TXT records alone reveal email infrastructure, SaaS platforms, security tooling, and long-standing integrations that define how large enterprises actually operate.

This visibility exists because many vendors depend on TXT records during onboarding and validation workflows.

Why DNS TXT Records Expose So Much About an Organization

TXT records are flexible by design. They store arbitrary text and can be queried by anyone, which is why vendors rely on them for ownership verification and configuration during onboarding, migrations, and service validation. This usage model is explicitly described in RFC 1464, which documents TXT records as a mechanism for publishing descriptive and service-related information in DNS.

From a practical standpoint, TXT records are attractive because they:

• Do not require hosting or application changes
• Continue working even if a website is offline
• Can be validated from anywhere
• Are easy for vendors to automate

As a result, TXT records are widely used for:

• Email authentication (SPF, DKIM, DMARC, BIMI)
• SaaS and cloud platform ownership verification
• Marketing and analytics tooling
• Identity, federation, and SSO services
• Certificate validation and security tooling

Over time, these records accumulate. Services are added, migrated, tested, or abandoned, but the DNS artifacts often remain. As a result, TXT records become one of the densest sources of external service discovery available without authentication, which is why they are a core signal in the DNSAudit.io DNS security scan.

Because these records are created for operational reasons and tend to persist, they form repeatable patterns that can be detected reliably across large datasets.

How TXT Records Support Service Discovery

In practice, reliable TXT-based detections follow a small number of repeatable patterns.

Explicit vendor verification tokens

Many platforms intentionally publish recognizable prefixes to confirm ownership or integration. When these appear, there is little ambiguity about which service was involved.

Examples include:

• google-site-verification=
• facebook-domain-verification=
• apple-domain-verification=
• stripe-verification=
• cisco-domain-verification=

Email authentication records that reveal providers

Email-related TXT records are standardized, but their contents often expose the underlying services directly.

Common indicators include:

• _spf.google.com for Google Workspace
• spf.protection.outlook.com for Microsoft 365
• sendgrid.net for SendGrid
• mailgun.org for Mailgun

A single SPF record frequently references multiple providers, revealing complex or transitional mail workflows and expanding the trusted sender surface.

For example, Zoom includes a lot of information, including services related to Google Workspace, Mandrill, Amazon, and Salesforce, exposed in their SPF configuration:

[email protected] ~ % dig TXT zoom.com | grep spf -i
zoom.com.               3586    IN      TXT     "Account Engagement emails pass SPF automatically, but we recommend setting it up as a best practice."
zoom.com.               3586    IN      TXT     "v=spf1 mx include:%{ir}.%{v}.%{d}.spf.has.pphosted.com include:_spf.google.com include:amazonses.com ip4:52.38.191.241 include:spf.mandrillapp.com include:stspg-customer.com exists:%{i}._spf.mta.salesforce.com ip4:13.111.2.177 ~all"
esteban@192 ~ %

This is a good example of how email configuration and service discovery overlap, since a single SPF record can expose multiple third-party providers involved in message delivery and processing.

DKIM and delegated records

DKIM public keys are published under _domainkey, often using CNAME delegation. While selector names vary, the delegated target domain frequently identifies the vendor, making TXT and CNAME analysis complementary.

Certificate and ACME-related TXT records

DNS-based certificate validation uses TXT records under _acme-challenge. While often short-lived, repeated observations across domains can reveal automated certificate tooling and operational patterns.

Combined, these signals make it possible to perform service discovery remotely and passively, without brute forcing or guessing. The challenge isn't access to the data. It's parsing it correctly and consistently at scale.

While these signals are straightforward to recognize in theory, extracting them accurately becomes much harder once you move beyond a single domain.

Why Manual TXT-Based Discovery Breaks Down at Scale

Most manual TXT inspection starts the same way. On Linux or Unix systems, this usually starts with a simple dig query:

dig TXT example.com

Or, when you want to focus on email-related configuration:

dig TXT example.com | grep -i spf
dig TXT _dmarc.example.com

This works well for a quick look at a single domain. The problems start when you try to do this consistently, across many domains, and interpret the results reliably.

TXT-based discovery looks simple when inspecting a single domain manually. The problems begin once volume, variation, and edge cases enter the picture.

Split and oversized TXT records

TXT values are often split into multiple quoted strings at the DNS level. If those fragments are not properly reconstructed, pattern matching and vendor detection fail silently.

Conflicting and overlapping records

It is very common to find:

• Multiple SPF records at the root domain
• Old verification tokens mixed with active ones
• Artifacts left behind after migrations or tooling changes

From a security perspective, these are misconfigurations. From a discovery standpoint, they introduce noise that is hard to filter manually.

Old or unused verification tokens

A TXT verification record does not necessarily mean a service is in active use today. Many domains still expose tokens for platforms they onboarded years ago. This is rarely a direct vulnerability, but it is consistently poor DNS hygiene and complicates analysis.

Abstraction that hides vendors

SPF flattening services and some DNS providers rewrite records in ways that remove obvious vendor references. This makes it harder to identify the underlying service without additional context or correlation.

Why manual TXT inspection does not scale

At that point, manual inspection becomes slow, inconsistent, and difficult to maintain:

• Dozens of DNS queries per domain
• Hundreds of vendor-specific patterns to recognize
• Constant interpretation of edge cases
• Ongoing updates as services and vendors change

For a single domain, this is manageable. Across dozens or hundreds of domains, it becomes slow, inconsistent, and error-prone, which is why TXT-based discovery benefits from automation. Automation makes it possible to move beyond individual examples and analyze DNS exposure patterns at scale.

What We Observed When Scanning Fortune 500 TXT Records at Scale

We analyzed 500 Fortune 500 root domains using the DNSAudit.io API, focusing exclusively on TXT records at the apex domain. Subdomains, web crawling, and authenticated data were intentionally excluded.

Even with a narrow scope limited to apex domains and TXT records only, several clear patterns emerged immediately.

Note: TXT records indicate integration or configuration at some point in time, not necessarily active usage today.

1. Email infrastructure is the most exposed layer by far

478 out of 500 domains (95.6%) expose at least one email-related service via TXT records.

This makes email the single largest and most consistently exposed operational surface across the Fortune 500.

Top 5 exposed email providers

Important context: These are not mutually exclusive. Many domains reference multiple email platforms at the same time, which leads directly to the next finding.

2. Multi-provider SPF is the norm, not the exception

337 out of 500 domains (67.4%) reference two or more email providers in their SPF records. And 154 domains (30.8%) reference three or more.

Real-world examples observed in the dataset include:

• Google Workspace + Proofpoint
• Microsoft 365 + Mimecast
• Google Workspace + Amazon SES
• Microsoft 365 + SendGrid + Salesforce

This matters because:

• Every additional SPF include expands the trusted sender surface
• Legacy providers often remain authorized long after migrations
• Attackers only need one weakly protected provider to abuse the chain

3. SaaS verification tokens are nearly universal

462 out of 500 domains (92.4%) expose at least one SaaS or platform verification token in TXT.

This includes search engines, collaboration tools, cloud platforms, and automation systems.

For this analysis, we intentionally grouped Google and Bing site verification together and treated Atlassian products as a single platform family to reduce noise and reflect how these platforms are typically deployed in large enterprises.

When we aggregate these verification signals across all domains, a small group of platforms consistently dominates.

4. Top 10 most exposed SaaS platforms

From an attacker's point of view:

• These tokens often confirm active internal tooling
• They help attackers profile an organization's internal stack without scanning hosts
• They provide strong enrichment signals for phishing, social engineering, and supply-chain targeting

5. CI, automation, and developer tooling is widely exposed

268 out of 500 domains (53.6%) expose at least one CI/CD, automation, or developer-facing platform via TXT records.

Commonly observed platforms include:

• GitHub and GitHub Actions
• Atlassian Bitbucket
• Azure DevOps
• Google Cloud build services

This is particularly relevant for:

• Supply-chain risk modeling
• Dependency and credential abuse scenarios
• Targeted developer phishing

6. Legacy and overlapping integrations are extremely common

301 domains (60.2%) expose TXT records tied to services that are:

• No longer referenced anywhere else
• Duplicated across multiple providers
• Clearly transitional (migration leftovers)

This confirms something many security teams already suspect but rarely measure: DNS often outlives the service it was created for.

7. DNS TXT records quietly reveal the enterprise cybersecurity stack

When isolating security and security-adjacent software signals from DNS TXT records, Fortune 500 domains show a strong pattern of standardization around a small set of vendors responsible for trust, compliance, and perimeter controls. In practice, these records tend to persist across migrations and tooling changes. Once added, they are rarely revisited or removed, which makes DNS a stable source for understanding how large organizations structure security at the infrastructure level.

Cisco-linked security and infrastructure services appear on 202 out of 500 domains (40.4%)

TXT records referencing Cisco-managed services highlight how deeply network security, email security, and infrastructure validation tooling are embedded in enterprise environments.

OneTrust compliance and privacy tooling is exposed on 159 domains (31.8%)

Consent management and regulatory compliance platforms now surface almost as frequently as traditional security vendors, reflecting how compliance has become inseparable from security operations.

GlobalSign certificate validation records are present on 95 domains (19.0%)

DNS-based domain verification for managed certificate lifecycles remains common, with many records persisting long after initial certificate issuance.

Cloudflare-specific DNS verification signals appear on 21 domains (4.2%)

These TXT records usually reflect onboarding or configuration workflows rather than active traffic routing, which means DNS visibility significantly underrepresents actual Cloudflare usage.

Public ACME-based certificate automation is nearly absent at the top end of the enterprise market

Let's Encrypt appears on only 2 domains (0.4%), reinforcing that Fortune 500 organizations overwhelmingly rely on commercial certificate authorities for primary domains.

DNS TXT records make it very clear which third-party providers large enterprises rely on for email, certificates, compliance, and security tooling. That visibility is useful for defenders doing external mapping, but it also works the same way for attackers. With nothing more than simple TXT DNS queries, it is possible to understand a company's security stack, spot common dependencies, and focus phishing or supplier-based abuse where it is most likely to work. No access, no exploitation, just information that is already public.

8. Fully "clean" domains are rare

Only 22 out of 500 domains (4.4%) showed:

• Minimal TXT usage
• Single email provider
• No SaaS verification sprawl
• No legacy indicators

These domains tend to be:

• Extremely tightly governed
• Highly centralized in IT ownership
• Actively maintained at the DNS layer

9. TXT exposure correlates with organizational complexity, not maturity

Some of the most security-mature organizations still expose:

• Multiple overlapping providers
• Redundant verification tokens
• Historical integrations

This level of TXT exposure correlates more closely with organizational complexity than with a lack of security controls.

10. DNS TXT records tend to retain evidence of past enterprise tooling decisions

Across the 500 domains, TXT records often revealed services that were likely added years ago and never removed. Old verification tokens, legacy email providers, and former SaaS or security tools frequently coexist with current configurations. DNS ends up retaining organizational history far longer than applications, cloud resources, or identity systems.

Common patterns we observed include:

• Deprecated SaaS and security vendor verification records still present
• Multiple generations of email or CI tooling referenced in SPF records
• Tokens linked to past migrations, acquisitions, or short-lived experiments

For defenders, this points to DNS as a hygiene gap that rarely gets lifecycle review. For attackers, it provides context: which vendors were trusted, how the organization evolved, and where believable impersonation or supplier-based pretexting becomes easier.

Making this kind of externally observable DNS data usable requires consistent parsing, correlation, and analysis at scale.

Automated Third-Party Service Discovery with DNSAudit.io

This is why the DNSAudit.io scan includes automated DNS-based service discovery, available both in the web scan and through our API. By analyzing TXT records and related DNS signals, DNSAudit.io identifies third-party services that quietly expand a domain's external attack surface.

The detection engine currently covers 300+ service signatures, including:

• Email and messaging platforms
• Marketing and analytics tools
• Cloud and SaaS providers
• Security and certificate services
• Identity and verification systems

All checks are performed remotely. No authentication, no agents, no access to the target environment.

Instead of manually digging through raw TXT records, DNSAudit.io shows:

• Which services were detected
• Where they were detected
• The exact DNS evidence used
• Related misconfigurations that expand the attack surface

This makes it possible to run large-scale DNS service discovery programmatically across hundreds or thousands of domains, using the same logic shown in this Fortune 500 analysis.

This analysis shows what DNS can reveal when it is treated as a source of external intelligence rather than just a routing layer.

If you want to integrate automated DNS service discovery into your security tooling or research workflows, you can request early API access here.