DNS Security TXT, Five Years On
Five years after we proposed publishing your security contact in DNS, the standard has one canonical home, a required freshness field, an Internet-Draft, and 181 domains found in the wild.
When someone finds a security issue in one of your systems, the first question is not "how bad is it?" It is "who do I tell?" Five years ago, we proposed answering that question in the one place every organization on the Internet already maintains: DNS.
DNS Security TXT is a simple standard for publishing your security contact, and optionally your disclosure policy, as DNS TXT records. A researcher, or an automated tool, can discover the right reporting channel before they ever load your website:
$ dig _security.example.com TXT +short
"security_contact=mailto:security@example.com"
"security_policy=https://example.com/security-policy"
"security_expires=2027-01-01T00:00:00Z"
security.txt (RFC 9116) solved this problem well for individual websites. DNS Security TXT extends the same idea to the layer above: DNS records speak for the whole domain rather than a single host, they are centrally managed, and interrogating DNS is already a standard first step in every pentest and asset scan. The two standards complement each other. Publish both, and keep them consistent.
A lot has happened since the 2021 proposal. Here is where things stand in 2026.
One canonical home: _security
The standard now defines _security.<yourdomain> as the sole normative location for these records, following the same underscored-name convention as _dmarc, _mta-sts, and _domainkey (RFC 8552). The original proposal allowed records at the domain apex as a fallback, and plenty of early adopters deployed there. Those records still resolve, and nothing breaks. But apex TXT record sets are crowded with unrelated protocols, so new deployments should go straight to _security, and existing apex deployments can migrate at their own pace: add security_expires, copy your records to _security, and retire the apex copies after a transition period.
Freshness is now required: security_expires
Stale contact information is worse than none. It can misdirect sensitive vulnerability reports, or lose them entirely. The standard now requires a security_expires field: an RFC 3339 timestamp, appearing exactly once, that marks the point after which the record set must no longer be used. It follows the freshness model RFC 9116 established for security.txt, and we recommend setting it less than a year out. A longer DNS TTL cannot extend it.
A proposed Standards Track Internet-Draft
The standard is now written up as a proposed Standards Track Internet-Draft, draft-ellis-dns-security-contact, maintained in the open in the GitHub repository. The draft makes _security the normative owner name, requires security_expires, and requests registration of the _security node name in the IANA underscored-names registry as it is prepared for submission to the IETF. Review and feedback are welcome via GitHub issues.
It is being deployed in the wild
For the first time, we measured deployment rather than asserting it. On July 11 we swept the Tranco top one million domains plus the domains in the disclose.io VDP directory, resolving _security.<domain> and apex TXT records for each. The sweep found 181 domains publishing DNS Security TXT records: 108 already at _security and 73 at the legacy apex. That is a count of what the sweep could see, not a claim about the whole Internet, and it does not include subdomain-level deployments.
A sample of the organizations publishing records today, each verifiable with a single dig:
- gov.uk, routing reports to the UK government's central vulnerability reporting service
- ethereum.org, the Ethereum Foundation, pointing at bounty.ethereum.org
- fortinet.com, FortiGuard PSIRT at Fortinet
- a16z.com, Andreessen Horowitz
- shodan.io, the Shodan search engine
- defcon.org, DEF CON
You can resolve any domain's security contact yourself at lookup.disclose.io, which chains DNS Security TXT alongside security.txt and a stack of other attribution strategies.
We hold ourselves to it
The zones we operate now practice what the standard preaches. Both _security.disclose.io and _security.dnssecuritytxt.org publish all three fields, including the new security_expires. And because the standard now ranks an authenticated source above an unauthenticated one when valid results disagree, both zones are DNSSEC-signed, so the records validate all the way down from the root:
$ dig @1.1.1.1 _security.dnssecuritytxt.org TXT +dnssec
;; flags: qr rd ra ad
That ad flag is the resolver telling you the answer is cryptographically authenticated, not just present.
Deploy it in five minutes
Add TXT records at _security.<yourdomain>:
| 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 |
Publish one or both security_contact forms. The policy is optional but strongly recommended, and the expiry is required.
Two things worth saying plainly. First, publishing these records does not authorize anyone to test your systems: authorization and safe harbor live in the policy you link, and the dioterms repository has boilerplates to get you started. Second, this is not a replacement for security.txt: keep both mechanisms, and keep them consistent.
Get involved
The standard has a refreshed home at dnssecuritytxt.org, with deployment guidance, live adopter examples, and the full FAQ. Deploy the records, then check your work at lookup.disclose.io. Read the draft and file feedback at github.com/disclose/dnssecuritytxt. And if you deploy, tell us. The "in the wild" section grows by evidence.
DNS Security TXT was created by John Carroll and Casey Ellis for the disclose.io Project.
