The disclose.io Project
A standard for nominating security contact points and policies via DNS TXT records, discoverable before a researcher even loads your site.
Created by John Carroll and Casey Ellis for the disclose.io Project. Currently a draft standard; feedback welcome via GitHub.
Summary
When people find security issues in Internet-facing systems, the correct channel to report them isn't always clear, and the relevant disclosure policy for the system isn't always apparent. DNS Security TXT extends the work done by security.txt to answer this question using DNS, arguably the most ubiquitous system on the Internet.
When deployed, it gives security researchers, Internauts, and concerned Internet citizens clear and authoritative direction to the correct channels for reporting security issues, and to the policies an organization sets out for all systems under a domain.
Why DNS
Using DNS TXT to establish authorization from a domain is common practice. DNS records speak for the organization, not just an individual server or app owner, which creates confidence in the reporting and policy information they carry. A DNS Security TXT record does not itself authorize testing; authorization or safe-harbor terms must be stated explicitly in the linked policy.
DNS management is centralized, so these records are simple to deploy, update, maintain, and remove. It removes reliance on individual owners to publish and maintain separate files.
DNS is core to how the Internet operates, and interrogating DNS is a fundamental footprinting step in penetration tests and automated scans, so the correct contact and policy details are less likely to be missed.
Fields
Each field is a separate TXT record in the form field_name=value.
https:// for URLs and mailto: for email.https://example.com/report-security-issue, mailto:security@example.comhttps://.https://example.com/security, https://bugcrowd.com/domainZ suffix, and set it in the future when published.2027-01-01T00:00:00ZDeployment
The proposed IETF specification defines _security.example.com as the sole normative owner name. Clients query _security; they do not fall back to the apex or walk toward the DNS root. Per-host HTTP details can still live in that host's /.well-known/security.txt under RFC 9116.
_security at your own pace: add security_expires, copy your records to _security.yourdomain, and retire the apex copies after a transition period.
_security.example.com NormativePros: maintains apex zone hygiene, supports future options without cluttering the apex, and follows the established underscored-name convention (_dmarc, _mta-sts, _bimi) per RFC 8552.
Cons: less visible than the apex, and users need to know about the _security subdomain.
| Description | Type | Content |
|---|---|---|
| Direct email contact | TXT | security_contact=mailto:security@example.com |
| Direct web form contact | TXT | security_contact=https://example.com/report |
| Policy URL | TXT | security_policy=https://example.com/security-policy |
| Expiration timestamp | TXT | security_expires=2027-01-01T00:00:00Z |
The 2021 proposal allowed apex records as a discovery fallback. The proposed IETF specification removes that behavior, because apex TXT record sets commonly contain unrelated protocols and do not provide explicit scoping.
Migrating? Add security_expires, copy all DNS Security TXT records to _security, and remove the apex copies after an appropriate transition period. Clients may offer an explicitly labeled legacy mode, but it should not be enabled by default.
In the wild
A sample of the organizations already resolving to a security contact through DNS Security TXT. Each record below is live and can be verified with a single dig.
Resolve any domain's security contact yourself at lookup.disclose.io.
FAQ
It can be, but it doesn't need to be. security.txt works well for individual hosts or hosts only addressable by IP, with DNS Security TXT providing directions from the parent domain. The two mechanisms have different scopes and authentication properties: security.txt can describe a specific HTTP service, while DNS Security TXT provides information for a selected reference domain.
If valid results disagree, clients should present all applicable contact information and highlight the inconsistency rather than applying a universal precedence rule. Publishers should keep both mechanisms consistent. A DNS record in an unsigned zone remains useful for discovery but is not cryptographically authenticated, and a DNSSEC result of Bogus must not be used.
Stale contact information can misdirect sensitive vulnerability reports or cause them to be lost entirely. The field follows the freshness model of RFC 9116: it appears exactly once, uses an RFC 3339 timestamp, and marks the point after which the entire record set must not be used. Clients check the timestamp whenever they use cached information, and a longer DNS TTL cannot extend it.
No. It provides a place for people to send security reports if they find something. Pair a security_policy with the security_contact to set expectations and rules of engagement. The disclose.io dioterms repository provides boilerplates to get you started.
Yes. While we strongly recommend the root domain, the standard supports subdomains and even individual hosts. That is useful when contact or policy details differ across departments, or when a department has a disclosure policy the parent organization does not.
It depends on the size of your organization and who maintains DNS. The engineering or IT team is usually a good place to start, and the security team will understand the reason for adding the records.
Email is optional. If you are worried about unsolicited mail, set a URI as the value and link to your security policy and a web form for reporting instead.
Searching "how to add TXT records to DNS" together with your DNS provider or system will point you to the right steps.