Are DNS records public?

Yes, and by design. RFC 9076 records the operating assumption that public-facing authoritative name servers respond to usual DNS queries for any zone they are authoritative for, without further authentication or authorization of the client. The same document states that DNS data and the results of a DNS query are public and may not have any confidentiality requirements. What RFC 9076 does treat as private is the transaction itself: who queried what, and when. The answers are public; the questions should not be.

What can someone learn from my DNS records?

Mostly which vendors you use. MITRE ATT&CK T1590.002 names MX, TXT and SPF records as revealing third-party cloud and SaaS providers. An MX names the host willing to accept your mail, so it identifies the gateway operator. An SPF include chain is a published, recursive list of organisations allowed to send as you. NS names your DNS provider, CNAMEs name hosting, CDN and SaaS endpoints, SRV records name collaboration platforms with their ports, DMARC rua names your reporting vendor, and CAA names your certificate authority. What none of it establishes is spend, seat counts, contract terms, renewal dates or roadmap, or even that a listed vendor relationship is still active.

Can I hide my DNS records?

Essentially no, and you should be skeptical of anyone who says otherwise. MX, SPF, NS and A records have to resolve publicly to function; removing or obscuring them breaks mail delivery and name resolution. The one mitigation MITRE recommends for T1590.002 is a zone transfer policy that limits which servers may pull a full copy of the zone, which defends against bulk dumps rather than ordinary lookups. What you can genuinely do is publish less: remove records pointing at resources you no longer own, delete MX records for a mail platform you migrated away from, and drop verification tokens for vendors you left.

What is Certificate Transparency and what does it expose?

Certificate Transparency is a certificate-auditing system defined in RFC 6962, separate from DNS. It provides publicly auditable, append-only logs of issued certificates so that misissuance can be detected. Two properties make it consequential. First, RFC 6962 states that log operators MUST NOT impose any conditions on retrieving or sharing data from the log, so access cannot be gated. Second, the append-only property is enforced with Merkle trees, and the Certificate Transparency project states that certificates can only be added to a log, not deleted, modified, or retroactively inserted. Peer-reviewed work by Roberts and Levin at WPES 2019 found CT logs facilitate subdomain enumeration and can leak business relationships, user growth measurements and the existence of internal projects prior to their public announcements, along with names, usernames and email addresses embedded in certificate domain names.

Can competitors see which email provider I use?

Yes, in most cases from a single MX lookup. RFC 1035 defines the MX EXCHANGE field as a host willing to act as a mail exchange for the owner name, and providers publish their target shapes in their own documentation. Microsoft documents the Exchange Online target as an MX token followed by .mail.protection.outlook.com. Even where MX is fronted by a filtering vendor, Microsoft instructs customers to publish an autodiscover CNAME pointing at autodiscover.outlook.com, which confirms the platform. The caveat matters: a record shows a route exists, not that a contract is active. Microsoft itself tells customers to delete MX records for their previous system after migrating, which is direct evidence that stale mail routes are common.

Is looking up another company's DNS legal?

Reading published DNS is not an attack and is not a technical violation of anything. Authoritative name servers are specified to answer ordinary queries from any client without authentication or authorization, and RFC 6962 forbids Certificate Transparency log operators from imposing conditions on who retrieves log data. Both channels are public interfaces serving data their owners deliberately published. MITRE classifies the activity as reconnaissance, but that is a description of adversary behaviour and of the fact that it happens outside a defender's visibility, not a claim about legality or wrongdoing. Bulk zone transfers are a different matter, since operators commonly restrict which servers may request them. This is not legal advice.

August 6, 2026 DNSai Security

What Your DNS Records Are Telling Your Competitors

Open a terminal. Ask any domain's name servers for its MX record. You will get an answer.

No key. No account. No approval step, and nothing the domain owner can see or refuse. That is not a defect in DNS. It is the operating assumption the protocol was specified on.

"the DNS operates under the assumption that public-facing authoritative name servers will respond to "usual" DNS queries for any zone they are authoritative for, without further authentication or authorization of the client (resolver)."
— RFC 9076: DNS Privacy Considerations, Section 4.1, IETF, July 2021

Be precise about what RFC 9076 is a privacy document about. Its stated focus is "the study of privacy risks for the end user (the one performing DNS requests)." The person asking. Not the zone answering. On published records the document is untroubled: "DNS data and the results of a DNS query are public… and may not have any confidentiality requirements." Then it draws the line that matters: "However, the same is not true of a single transaction or a sequence of transactions; those transactions are not / should not be public."

The questions are private. The answers never were. Nobody at the IETF is alarmed about this, and there is no reason for you to be either. But it does mean your zone is competitive intelligence published on an interface with an uptime requirement.

What can competitors learn from DNS records

Mostly one thing, repeated across record types: which vendors you bought.

Public DNS records answer any client without authentication

Authoritative name servers answer ordinary queries from any client. That is the design, not a misconfiguration.

MITRE ATT&CK catalogues the activity as reconnaissance technique T1590.002, and it is unusually blunt about which records give the game away: "DNS MX, TXT, and SPF records may also reveal the use of third party cloud and SaaS providers, such as Office 365, G Suite, Salesforce, or Zendesk."

The fingerprints are published by the vendors, not leaked by you. Microsoft's own DNS documentation prints the exact shapes an outside observer matches against.

; shapes documented by the vendors themselves example.com. 3600 IN MX 0 <MX token>.mail.protection.outlook.com example.com. IN TXT "v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all" example.com. IN TXT "google-site-verification=abcdef123_456wx789yz" autodiscover.example.com. IN CNAME autodiscover.outlook.com _sipfederationtls._tcp.example.com. IN SRV 100 1 5061 sipfed.online.lync.com

MX. RFC 1035 defines the EXCHANGE field as "a host willing to act as a mail exchange for the owner name." A hostname willing to accept your mail is, necessarily, a hostname operated by whoever runs your mail. Microsoft Learn documents the Exchange Online target as <MX token>.mail.protection.outlook.com at TTL 3600. One lookup, one attribution.

SPF. The include mechanism exists, per RFC 7208 §5.2, "to make it possible for one domain to designate multiple administratively independent domains" — which is to say, it is a published list of the organisations allowed to send as you. It is also recursive. An include "triggers a recursive evaluation of check_host()," so what you disclose is a tree, including sub-vendors nobody at your company chose. Microsoft's guidance notes you get exactly one SPF record per domain, so the whole roster lands in a single readable string. The tree does have a depth limit: RFC 7208 §4.6.4 caps evaluation at 10 DNS-lookup terms. We covered that ceiling, and how to stay under it, in SPF Records: The 10 Lookup Limit and How to Optimize.

Verification TXT tokens. Microsoft 365 asks for a TXT record that exists only to prove ownership and, in its own words, "doesn't affect anything else." Google Workspace uses google-site-verification=, which names the vendor inside the token. We took that pivot apart in detail (tenant fingerprinting, federation URLs, stale-token cleanup) in From TXT Record to Tenant ID: DNS Recon Into Entra OAuth, and for the raw mechanics of reading these there is TXT Records in DNS: What They Are and How to Look Them Up. The short version: the token is inert, and it keeps announcing the onboarding forever.

NS and CNAME. RFC 1035 defines NSDNAME as "a host which should be authoritative for the specified class and domain," so the delegation names your DNS provider. It usually implies the registrar relationship as well. CNAME publishes "the canonical or primary name for the owner," which is why CNAMEs are the clearest disclosure of hosting, CDN and SaaS endpoints in the whole zone. Microsoft tells administrators to point an autodiscover CNAME at autodiscover.outlook.com, which confirms the mail platform even when the MX is fronted by a filtering vendor.

SRV. RFC 2782 puts service, protocol, priority, weight, port and target in one record at a predictable owner name. Microsoft documents Teams federation as _sipfederationtls._tcp, priority 100, weight 1, port 5061, target sipfed.online.lync.com. Collaboration platform and federation posture, read off a single line.

A records for identity. Microsoft's single sign-on guidance has customers publish a public A record for their AD FS federation server proxies, described as "the endpoint for your off-premises users… to connect to your Active Directory Federation Services (AD FS) federation server proxies or load-balanced virtual IP (VIP)." An identity-provider footprint, in public DNS, by instruction.

DMARC. The current DMARC core specification is RFC 9989, published May 2026, which obsoletes RFC 7489 and RFC 9091. Its rua tag holds "addresses to which aggregate feedback reports are to be sent," normally mailto: URIs. That is a public list of your reporting vendor and, often, an internal mailbox name. RFC 9990 §4 adds a second-sided confirmation: when reports go to a third party's domain, that third party must publish an authorising TXT record at <yourdomain>._report._dmarc.<vendordomain>. Both ends of the relationship are queryable.

BIMI and CAA. BIMI is published at default._bimi.example.com; its l= tag gives an HTTPS logo URL and its a= tag, when present, points at a publicly retrievable evidence document, disclosing brand-verification posture and the issuing CA. Note what BIMI is: an IETF Internet-Draft, currently revision -14, an individual submission and not an RFC. RFC 8659 CAA is a real standard, and it does the same job for certificate authorities: it "allows a DNS domain name holder to specify the Certification Authorities (CAs) authorized to issue certificates for that domain name." Your CA, named by you, on purpose.

Read Your Own Zone The Way An Outsider Does

DNSai resolves A, AAAA, MX, TXT, SOA, NS, DMARC, BIMI and SRV records live, matches MX against about 279 email-gateway vendors, and NS, TXT and DMARC against roughly 1,131 technology vendors. Lookups run against live name servers with a short cache; we do not build an index of the domains you check.

Look Up A Domain →

What none of this proves

Here is where most writing on this subject goes wrong, and it goes wrong in the direction of alarm.

A record proves that a record exists. It does not prove that a contract is active, that the service is in use, that anyone is paying for it, or that the team who created it still works there. Microsoft's own documentation is the evidence. It instructs customers to remove old MX records after migration: "Once email is flowing to Exchange Online, you should remove the MX records that are pointing to your old system." It says to delete CNAMEs for deprovisioned resources too. Vendors would not need to write that guidance if records did not routinely outlive the relationships they describe.

The same caution applies to that DMARC authorisation. RFC 9990 §4 permits a bulk approach: "A Report Consumer that is willing to receive reports for any domain can use a wildcard DNS record." A positive answer at _report._dmarc may mean nothing more specific than that the vendor accepts everyone.

The bounds are worth stating plainly, because they are wide. Your zone reveals vendor category and platform. It does not reveal spend, seat counts, contract terms, renewal dates or roadmap. A single MX tells an observer that mail fronts on a given gateway; it says nothing about the policy tuning behind it, the architecture it protects, or what else sits on that path.

DNS also cannot be browsed. RFC 9076 is explicit: "Due to the lack of search capabilities, only a given QNAME will reveal the resource records associated with that name… one needs to know what to ask for in order to receive a response." There is no directory. Every wide enumeration you have read about comes from somewhere other than the DNS query protocol. The same RFC lists DNSSEC NSEC zone walking and passive DNS aggregation among the ways "supposedly "private" resources currently leak."

And the biggest source of enumeration is not DNS at all.

Certificate Transparency is a different mechanism, with a worse property

Certificate Transparency has nothing to do with the DNS protocol. It is a certificate-issuance auditing system, defined in RFC 6962, and its purpose is deliberate publicity:

"Certificate transparency aims to mitigate the problem of misissued certificates by providing publicly auditable, append-only, untrusted logs of all issued certificates."
— RFC 6962: Certificate Transparency, Section 1, IETF, June 2013

Publicity is the mechanism. It is how misissuance gets caught. RFC 6962 puts it plainly: "The logs are publicly auditable so that it is possible for anyone to verify the correctness of each log and to monitor when new certificates are added to it." Section 3 removes any question of who counts as "anyone": "Log operators MUST NOT impose any conditions on retrieving or sharing data from the log."

You cannot ask a log to gate access to your hostnames. There is no mechanism for it, by specification.

Now the part that separates CT from DNS. Append-only here is a cryptographic property, not a policy: "The append-only property of each log is technically achieved using Merkle Trees, which can be used to show that any particular version of the log is a superset of any particular previous version." The Certificate Transparency project states the consequence in one line: "Certificates can only be added to a log, not deleted, modified, or retroactively inserted."

Delete a DNS record and it stops answering within one TTL. Nothing equivalent exists here. A hostname that appeared in a certificate in 2019 is in the logs now, and will be in the logs later, whether or not the host, the project or the company still exists.

What researchers actually found in the logs

This is not speculation. Roberts and Levin presented a study of CT information leakage at WPES 2019, the 18th ACM Workshop on Privacy in the Electronic Society. Their finding starts with the permanence:

"Unbeknownst to most users and website administrators, CT logs make all data in all certificates available publicly and permanently."
— Roberts & Levin, When Certificate Transparency Is Too Transparent, WPES 2019

The enumeration point follows mechanically: "CT logs contain certificates for subdomains, which naturally facilitates subdomain enumeration." Every internal-sounding host that ever got a publicly trusted certificate is in a list somebody else maintains.

Then the finding that belongs in a piece about competitors. The paper reports that CT "can leak private enterprise information, such as business relationships, user growth measurements, and the existence of internal projects prior to their public announcements." It also documents user-level exposure: the authors "identify several types of user and enterprise information embedded within the domain names of certificates" and "provide queries for obtaining information such as users' names, usernames, and email addresses."

Business relationships. Growth measurement. Unannounced projects, by name, before the announcement. That is a materially different class of disclosure from "they can see we run Exchange Online," and it arrives through a channel most organisations never think about because it is not part of their DNS estate.

The two channels overlap without containing each other. Internal hosts that never had a public DNS record can appear in CT if someone issued them a public certificate. Hosts that live in DNS never appear in CT if they never got one. Treating CT findings as "DNS exposure" is imprecise, and the imprecision matters when you go looking for the cause.

MITRE files certificate searching as its own reconnaissance technique, T1596.003, and its assessment of your defensive options is refreshingly free of product pitch: "This technique cannot be easily mitigated with preventive controls since it is based on behaviors performed outside of the scope of enterprise defenses and controls." The recommended response is "minimizing the amount and sensitivity of data available to external parties." Reduce what you publish. You cannot block the reading of it.

There is one real lever on name disclosure, and it is a trade. A wildcard certificate covers a label level without naming the hosts inside it. RFC 6125 §6.4.3 specifies that *.example.com matches foo.example.com but not bar.foo.example.com or example.com. Fewer names in the logs. But the same document flags wildcards as a security concern in their own right, because one key then vouches for many hosts. It is a redistribution of risk, not a removal of it, and it should be decided as such.

DNSai's subdomain discovery is passive and works exactly this way: it reads Certificate Transparency, the same public logs any researcher or competitor reads. There is no scanning of your infrastructure, because there does not need to be.

What actually reduces risk, and what is only tidying

Both categories are worth doing. Only one of them is security.

Genuine risk reduction: dangling records. Microsoft's Azure security documentation is direct about the failure mode: "A subdomain takeover can occur when you have a DNS record that points to a deprovisioned Azure resource. Such DNS records are also known as "dangling DNS" entries. CNAME records are especially vulnerable to this threat." Dangling MX is worse than most people assume: those records "could enable threat actors to receive emails directed to legitimate subdomains associated with trusted brands." And the reassurance people reach for does not hold. "A common misconception is that SSL certificates protect your site and your users' cookies from a takeover. However, a threat actor can use the hijacked subdomain to apply for and receive a valid SSL certificate." That certificate then gets logged in CT, permanently, under your brand's name. Microsoft's remediation is one sentence: "From your DNS zone, remove all CNAME records that point to FQDNs of resources no longer provisioned." It also recommends reviewing zones regularly and maintaining a catalogue of FQDN endpoints and their owners. Treat the zone as an inventory.

Genuine risk reduction: old mail routes. Delete the MX records for the platform you migrated off. Microsoft says so explicitly, and a stale MX is precisely the dangling case above.

Genuine risk reduction: zone transfer policy. The one DNS mitigation MITRE recommends for T1590.002 is to "consider implementing policies for DNS servers, such as Zone Transfer Policies, that enforce a list of validated servers permitted for zone transfers." Note the scope: that defends against a bulk dump of the zone, not against ordinary lookups. Nothing defends against ordinary lookups.

Tidying: stale verification tokens. Removing a verification TXT for a vendor you left is information hygiene, not vulnerability remediation. Microsoft is clear the record "doesn't affect anything else." It is inert. It is also a permanent public statement that you once onboarded a product, which is not the same thing as a live control-plane weakness. Do not confuse a leftover token with a dangling CNAME.

Tidying: reporting addresses. Pointing DMARC rua at a role address rather than a named individual removes a person's mailbox from a public record. Worth ten minutes. Not a control.

Cannot be fixed, and should not be attempted. MX, SPF, NS and A records have to resolve publicly to do their jobs. Removing or obscuring them breaks mail delivery and name resolution. Any advice implying you can hide them is wrong on the mechanics.

The honest summary

Someone reading your public DNS is not attacking you. They are using a public protocol in the ordinary way, against data you published so that the internet could find you. MITRE classifies it as reconnaissance because that describes the behaviour, not because it describes wrongdoing, and its own notes stress that the activity happens outside your visibility and outside your control. That is a statement about detectability.

So the correct posture is not defensive and it is not anxious. It is inventory. Know what your zone says, because everyone else can already read it. Know which of your hostnames are in the CT logs, because they are not coming out. And spend your actual remediation time on the small subset of this that is a real weakness: records pointing at resources you no longer own.

The rest is not a leak. It is the protocol working.

Sources

RFC 9076: DNS Privacy Considerations, Sections 2 and 4.1 — IETF / RFC Editor, July 2021. rfc-editor.org
RFC 1035: Domain Names — Implementation and Specification, Sections 3.3.1, 3.3.9, 3.3.11 — IETF / RFC Editor, November 1987. rfc-editor.org
RFC 2782: A DNS RR for specifying the location of services (DNS SRV) — IETF / RFC Editor, February 2000. rfc-editor.org
RFC 7208: Sender Policy Framework (SPF), Sections 4.6.4 and 5.2 — IETF / RFC Editor, April 2014. rfc-editor.org
RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record — IETF / RFC Editor, November 2019. rfc-editor.org
RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — IETF / RFC Editor, May 2026 (obsoletes RFC 7489 and RFC 9091). rfc-editor.org
RFC 9990: DMARC Aggregate Reporting, Section 4 — IETF / RFC Editor, May 2026. rfc-editor.org
Brand Indicators for Message Identification (BIMI), draft-brand-indicators-for-message-identification-14 — IETF Datatracker, May 2026. Internet-Draft, individual submission; not an RFC. datatracker.ietf.org
RFC 6962: Certificate Transparency, Sections 1 and 3 — IETF / RFC Editor, June 2013. rfc-editor.org
RFC 6125, Section 6.4.3 (Checking of Wildcard Certificates) — IETF / RFC Editor, March 2011. rfc-editor.org
How CT Works — Certificate Transparency project. certificate.transparency.dev
When Certificate Transparency Is Too Transparent: Analyzing Information Leakage in HTTPS Domain Names (Roberts & Levin) — ACM WPES 2019, November 11, 2019. Linked here to the open University of Maryland author copy; the ACM Digital Library version is gated. cs.umd.edu
Gather Victim Network Information: DNS (T1590.002) — MITRE ATT&CK. attack.mitre.org
Search Open Technical Databases: Digital Certificates (T1596.003) — MITRE ATT&CK. attack.mitre.org
External Domain Name System records for Microsoft 365 — Microsoft Learn, June 26, 2026. learn.microsoft.com
Verify your domain with a TXT record — Google Workspace Admin Help. knowledge.workspace.google.com
Prevent dangling DNS entries and avoid subdomain takeover — Microsoft Learn, July 20, 2026. learn.microsoft.com

Share this article