DNS provides unusually accessible infrastructure evidence, but it is a deliberately incomplete view of an organization’s technology and security posture.
What DNS can show directly
MX records reveal declared inbound mail exchangers. TXT records can expose SPF and DMARC policies or provider-specific verification values. CNAMEs can indicate supported services such as Autodiscover or DKIM delegation. NS records identify the currently delegated authoritative name servers. Each record expresses a specific DNS relationship at an observation time.
dig +short MX example.com
dig +short NS example.com
dig +short TXT _dmarc.example.com
These lookups can be repeated and audited without logging into the company’s environment. That reproducibility is why domain-level intelligence is useful for scalable account research.
What DNS cannot prove
DNS cannot tell you whether a Microsoft 365 tenant has a working backup, whether an email gateway is configured correctly, whether an API security product is active, who owns a subscription, how many employees use a tool, or when a contract expires. Observing a vendor value is also not proof that the vendor protects every mailbox.
The danger of negative evidence
"No recognized gateway" is a narrower and safer statement than "no email security." A domain could use Microsoft Defender, an API-integrated product, a custom gateway or a service for which the detector has no fingerprint. Similarly, an unanswered DNS query can mean a resolver error rather than no record.
Confidence depends on independent signals
| Signal pattern | What can be supported |
|---|---|
| Direct Microsoft MX | Microsoft in visible inbound mail routing |
| Gateway MX | Gateway vendor in visible routing |
| Gateway + Autodiscover + DKIM | Backend platform hypothesis with stated confidence |
| Entra signal alone | Microsoft identity, not confirmed mail platform |
| SPF include | Authorized sender clue, not necessarily inbound protection |
Do not convert every vendor string to a technology classification. Keep raw observations, recognized signatures, an unknown result where necessary, confidence and timestamp.
Sampling and temporal problems
A crawler might see a DNS migration in progress, cache differences across resolvers or partial records from a multitenant environment. Rescan ambiguous accounts and preserve when a claim was observed. Historic changes can become interesting triggers, but they still need interpretation.
Use DNS as a first-pass research layer
A prospect scan should prepare a salesperson for discovery. Find Leads helps build a potential segment from independently collected observations. Neither route replaces customer interviews, procurement information or permission-aware contact enrichment. The commercially useful output is a better question, not a claimed internal audit.
How to document a defensible finding
A minimal finding includes the queried domain, record type, returned value, resolver outcome, observation timestamp, matching rule and classification confidence. Where the detector made a workspace inference, keep the independent supporting evidence rather than only the final vendor label. This information lets a reviewer distinguish a transient DNS answer from a known provider signature.
For account research, the safest output is often an evidence-backed question. A mail gateway detection can support "Who manages your current gateway?" A monitoring-mode DMARC record can support "Are you already working toward enforcement?" Neither requires pretending to know private configuration. Your sales process gains specificity without crossing the boundary of what public DNS actually proves.
Turn infrastructure signals into a qualified prospect list.
Analyze domains you already know, or find new companies that match the technologies you target. Public DNS observations support discovery, not proof of an internal security weakness.