Nobody checks whether the security contact still exists

That gap matters more than it sounds, because of an asymmetry in how a contact fails.

If the domain in a Contact: line has expired, mail to it does not bounce. Somebody registers the domain — they cost a few dollars, and lists of freshly-expired ones are a commodity — points an MX record at a mailbox, and starts receiving that organisation's inbound vulnerability reports. The reporter sees nothing wrong. There is no error, no bounce, no warning banner. From the outside, silent interception and working correctly look exactly the same, and the traffic being intercepted is a stream of unfixed vulnerabilities in the victim's own systems, sent by people who believe they are doing the responsible thing.

The standard saw this coming. RFC 9116 §5.3 warns that stale references can result in "security reports not being received by the organization or sent to incorrect contacts, thus exposing possible security issues to third parties," and asks organizations to ensure that the file's referenced resources "are kept current, are accessible, are controlled by the organization, and are kept secure." Controlled by the organization. A contact domain a stranger can buy is exactly the failure that clause names. The same section goes further than most practitioners realise: "Not having a security.txt file may be preferable to having stale information in this file."

So this is not an exotic threat model I brought to the standard. It is in the standard, in the Security Considerations, under a heading that names it: Incorrect or Stale Information.

And then the standard declines to make it testable. §5.3 says "should ensure," in lowercase — and RFC 9116's requirements-language section is explicit that the BCP 14 keywords bind "when, and only when, they appear in all capitals." Lowercase is prose. So the property that decides whether the file does its job carries no conformance requirement to check it against, while the things a parser can see without leaving the file — Contact MUST be present, Expires MUST be present — carry capitals. That is not an oversight in the standard so much as an honest one: a document about a text file cannot impose a testable duty on the DNS. But it does explain the shape of the surveys that follow. Validators test the capitals. The capitals are all inside the file. So the file gets audited and the address it names does not, and the one section that describes what actually goes wrong has nothing in it for a checker to fail you on.

The existing literature stops one step short of this. Every published measurement I can find — industry scans, one peer-reviewed study, a regulatory survey — counts how many sites publish the file and how well the files conform to the spec. Every one of them counts a Contact: as valid if it parses. None resolves the domain behind it.

That is not a gap nobody noticed. The authors of the academic study propose almost exactly this follow-up under future work, and the manufacturer survey names the same limitation in passing. It is noticed, written down as a limitation, and then left — in every one of them — because closing it means leaving the file and going out to the DNS. I go through all four, and exactly where each one stops, at the end of this article.

I have not done the study they proposed, and the difference matters. Mailing several hundred thousand organisations unsolicited to see who replies is a research programme with an ethics board attached. What I did is the passive half of it: resolve the contact domain and ask whether there is anything there to receive mail at all. That answers "is the address live", not "does anyone read it" — which makes every number below a lower bound on the problem, because a contact I count as perfectly reachable may still be an unattended mailbox nobody has opened in years.

Meanwhile a separate literature — Lauinger et al., Game of Registrars, USENIX Security 2017 — has studied domain expiration and re-registration in depth. The two have never been pointed at each other. So I resolved every contact domain in 200,000 sites' security.txt files and asked the question the regex can't: does it exist, and if not, can a stranger have it?

Correction, 27 August 2026. The first version of this article said 233 sites publish no working contact. The real number is 147. A parse bug in my own tool discarded every Contact line written mailto: security@example.com — with a space after the scheme — which is 105 lines here, and for 86 sites it was the only address in the file. The headline is unaffected: 7 hijackable contacts, same 7. What moved is the second finding, one column of the per-band table, the concentration counts, and the reachability cross-tab, whose two close verdicts came back reversed. The full account is the fourth item in the next section, with the numbers it cost. The tool is fixed and has a test over it.

What I found

Of 200,000 sites, 7,780 publish a security.txt. Seven of them name a contact on a domain that is not registered — a domain anyone reading this could buy for the price of a coffee and start receiving that organisation's inbound vulnerability reports.

Seven is a small number and I am not going to dress it up. The head of the web is in better shape on this specific failure than I expected when I started, and far better than the security-policy contacts I surveyed in a different corpus. Nobody should read this article as the web's security contacts are being hijacked. Read it instead as three things a conforming file cannot tell you.

The only health signal the standard makes testable does not see this failure. Five of the seven sit behind a file with a valid, unexpired Expires date. Zero sit behind an expired one. At seven events those rates are indistinguishable and I am claiming no direction between them — that is the point. A file can carry a Contact and an unexpired Expires — the two fields the standard makes mandatory, and between them most of what a validator can test — while naming a contact domain a stranger can buy. The health check and the failure are not in contact with each other, and the field doing the checking is the one the standard added to guard against exactly this.

147 sites — 1.9% of everyone publishing a file — have no working contact at all. That breaks in half. 72 of them publish an address or a portal that a client can act on and it does not work: the disclosure page returns 404 or 410, the mail domain publishes a null MX meaning this domain sends no mail, the TLD isn't delegated. The other 75 publish a Contact line that is not an address at all — a relative path, a scheme typo, an anti-harvesting spelling like security AT example DOT com. A human can often decipher those; no client can, and 7 of the 147 give a telephone number, which this survey counts and does not dial. Either way a report sent today lands nowhere, and that is more than twenty times as common as the hijackable case. It is the finding I would act on first.

The exposure is pooled rather than spread. One contact domain is the published security contact for 413 different organisations, and 67 domains are each the contact for ten or more. None of those is currently registerable, so today's worst blast radius is a single site. That is a snapshot and not a property: the concentration is a statement about what one lapse would cost.

The measurement, and four ways it lied to me

Every one of these bugs inflated the finding. That is not a coincidence — a bug that makes your result boring gets found immediately, because you go looking for it. A bug that makes your result exciting gets published. The fourth one below did get published, in the first version of this article, and stayed up for a day.

A dead name is not necessarily a claimable one. NXDOMAIN on mail.example.com means the name doesn't exist. It does not mean anyone can register it: only the owner of example.com can create a host under it. That is a bounce, not a hijack, and it belongs in a different column. Telling the two apart needs the Public Suffix List, because label-counting cannot: example.com.br is for sale and mail.example.com is not, and both have three labels. Anything that skips this step reports every dead subdomain as a takeover and inflates the finding by an order of magnitude.

A mail taxonomy applied to a web form invents failures. "No MX record" is a fatal verdict for a mailto: and completely meaningless for an https:// disclosure portal — portals don't have MX records. I had one code path for both, and it reported 62 of the top 3,000 as having a broken contact. All 62 were large companies whose Contact is a web form, and every one of them was fine. Facts about a domain and the interpretation of those facts have to be separate functions, because the interpretation depends on what the contact is for.

HTTP 403 is not a dead portal. It means the server is alive and refusing me. This scan runs from a datacenter IP, which gets bot-walled constantly; counting those as broken measures my own network's reputation and calls it the internet's security posture. Only 404 and 410 say the server is healthy and the report page is gone. That one distinction cut "no working contact" in the sample from 23 to 9 — a 60% reduction in my own headline, from a correction I could just as easily not have made.

One space. This is the fourth, it is the one that shipped, and it is the smallest bug in the article:

Contact: mailto: security@example.com

My parser took everything after mailto: and split it on whitespace to strip any trailing (preferred) comment. With a space after the scheme, the remainder begins with that space, so the first element of the split is the empty string, there is no @ in it, and a working address was recorded as a malformed contact line. Nothing crashed. Nothing was logged. The address simply stopped existing.

105 Contact lines in this corpus are written with that space, and for 86 sites it was the only address in the file. So 86 organisations with a perfectly good, live security contact were counted — in an article about unreachable security contacts — as having no working contact at all. The figure I published was 233. It is 147. Every derived number moved with it: the rate, the per-band column, the reachability cross-tab and both of its verdicts.

Two things about that are worth more than the number. The first is the direction. This bug, like the other three, made the finding bigger, and I did not go looking for it while the finding was big. I found it later, writing a section about how few of the affected sites could be notified, when a breakdown of which contacts were unusable showed most of them sharing a shape that a mail client would have no trouble with. The check that caught it was reading the raw data behind a number I had already published and believed.

The second is what happened when I fixed it. I corrected the parser in the shared library, re-ran the analyzer against the frozen scan, and every figure came back byte-identical. The analyzer carried its own copy of that function, duplicated verbatim, and the copy that produces the published numbers was not the copy I had fixed. Had I not diffed the re-run against the old output, the correct conclusion available to me at that moment was "the bug doesn't matter at scale," which is both wrong and extremely comfortable. There is now one copy, imported by both, and a test that pins the space.

Going looking afterwards, the parser was not the only one. The analyzer held nine duplicated functions in all — the four classification rules and a second copy of the entire DNS layer beneath them, including the one function that decides whether a contact domain is unregistered, which is the headline of this article. Those are deduplicated too, and the test that used to compare the two copies now asserts there is nothing left to compare. Deleting them changed no number, and I can say that precisely rather than hopefully: the DNS answers were already cached, so the re-run never called the function at all and every key of the output is identical.

Two of the first three are measurable at full scale, and both got bigger. Of the disclosure portals that did not return a page, 157 answered with a gate — 401, 403 or 429 — against 91 that were genuinely gone. A scan scoring a refusal as a dead portal would report nearly three times as many dead portals as exist, and the difference is a measurement of my own IP's reputation wearing the costume of a finding about the web. The mail-taxonomy defect would have been wider still: 2,766 of the contacts in this corpus are HTTPS portals, and the buggy code path judged every one of them by whether its domain publishes an MX record.

Adoption is not one number

rank band      scanned  sec.txt  adopt%  expired%  no Expires%  3rd-party%  no contact%  hijackable
1-1k              1000      195   19.50       6.2         34.4        57.9          0.5           0
1k-10k            9000      926   10.29      11.1         22.7        60.7          1.6           0
10k-50k          40000     2214    5.54      13.6         19.7        53.3          1.6           1
50k-100k         50000     1756    3.51      15.7         18.8        58.1          1.7           3
100k-200k       100000     2689    2.69      14.7         16.8        59.4          2.5           3

The columns do not all behave the same way, and the differences are the interesting part. Adoption falls by a factor of seven from the top band to the bottom, monotonically. Expired files become steadily more common as you descend while missing Expires becomes steadily less common — one trend rather than two, since further down the list a larger share of publishers set the field at all, and a larger share of those who set it have stopped renewing it. A stale date is evidence of a publisher who cared once.

The third-party column does something different: it does not trend at all. It sits between 53.3% and 60.7% in every band, with no ordering by rank. Outsourcing the security contact is not a behaviour of large organisations or of small ones. It is what publishing a security.txt normally looks like, everywhere on the list — which is what makes the next section the one that matters.

Published adoption figures disagree by more than an order of magnitude — 0.238% of every gTLD zone-file domain in 2026, 1.25% of the top million in 2025, 19.5% of the top thousand in this run. All three are correct. They are measuring different populations and quoting a single number for each, and the file is far more common at the top of the list than anywhere else. Any pooled percentage over a large domain list is mostly a statement about how far down the list you went.

The gradient itself is not my finding. It is well documented and it is steep: the 2023 ACM study measured the same shape across rank groups in its final scan — 34.0% of the top 100 published a file, 18.8% of the top 1k, 9.8% of the top 10k, 3.2% of the top 100k, 1.0% of the top 1M. I am citing the direction and not the levels, deliberately, for two reasons. Those groups are cumulative top-N where mine are disjoint bands, and that scan closed in January 2023. Either difference on its own is enough to make a level-against-level comparison meaningless. What survives both is the shape, measured independently three years before mine: adoption falls hard and monotonically with rank, which is what makes a single pooled percentage a statement about sampling depth wearing the costume of a fact about the web.

Comparing across years compounds it, and this is a trap I walked into while drafting. I originally wrote that the published figures disagree by a factor of eighteen, taking 0.7% from the 2024 study and setting it against my own 2026 measurement. But that same top-million measurement had gone from 0.7% to 1.25% by 2025 — adoption nearly doubled in a year. Most of my "factor of eighteen" was population and some of it was calendar, and nothing in the two numbers tells you which is which. Quoting a rate from one operating point against a rate from another is the easiest way to manufacture a finding, and it is easiest of all when the result flatters the story you arrived with.

Two other things move an adoption number, and they push in opposite directions. Neither is usually stated.

Counting HTTP 200 as adoption overcounts, and the error grows down-rank. Plenty of hosts answer 200 with an HTML page for any path, so /.well-known/security.txt returns a soft 404 that a status-code check scores as a hit. Requiring the body to parse and to carry the mandatory Contact: field is the fix, and the gap between the two is not small. Counting any HTTP 200 as adoption reports 1.59× the real figure in the top 1,000 and 4.34× in the 100k–200k band. The factor climbing with rank is the part that matters: a status-code survey does not merely overcount, it invents a much flatter adoption curve than the real one, because the tail is where the overcounting is worst and the tail is most of any large list.

Probing only the apex undercounts, and not at random. The conventional fetch is https://<domain>/.well-known/security.txt. When the apex has no A record, that fetch fails outright, and it is easy to record the domain as unreachable — but 16.6% of those domains serve a live www. host, which is where the organisation's website actually is. That is 3,963 domains out of the 23,945 with no address at the apex in this run. That description is measured rather than assumed: in a 300-domain sample of them, 291 of the 297 genuinely dead apexes answered ENODATA rather than NXDOMAIN — the name exists, the delegation is real, and the zone simply carries no address at its apex. These are live zones, not dead domains.

That is the limit of what the DNS answer proves, and it is worth resisting the next step. A live zone with no apex address is not necessarily a website configured the old way: a popularity ranking built from DNS traffic also contains nameserver and CDN infrastructure, which has no apex address because it was never a site at all and has no www. either. Both populations are in here, and which one dominates is precisely what the retry pass measures rather than something to assert in front of it. What the retry list is not is random: "delegated, but no address at the apex" selects for older DNS configurations and for organisations that have not revisited their zone in years, which is exactly the population a survey about stale contact information has the least business dropping. Going back for them found 43 additional files.

Forty-three is a small correction and worth reporting as one — it moves the headline adoption figure by well under a tenth of a percentage point. What the retry pass actually settled is the question the paragraph above refused to assert: 16.6% is a low number, so the great majority of those 23,945 apex-address-free entries really are infrastructure rather than websites configured the old way. I would have guessed higher. The pass was still worth running, because "most of them are not sites" is a measurement and "most of them are not sites" was, until I ran it, a hunch that happened to justify the cheaper option.

Counting those against the apex domain is a judgement call, and the spec does not back me up on it. I had originally written that www. is "where their file belongs under RFC 9116 §3," which sounded authoritative and was not. §3 does say the file goes under /.well-known/ of "a domain name or IP address," so a file on the www. host is perfectly conforming *for the www. host* — but §3.1 is explicit that a file "MUST only apply to the domain or IP address in the URI used to retrieve it, not to any of its subdomains or parent domains." Strictly read, www.example.com's file says nothing whatsoever about example.com. I count it anyway, because the entry in a popularity ranking is a label for an organisation and that organisation's website is the www. host — but a checker obeying §3.1 to the letter would tell every one of those 43 apexes it has no security.txt, and it would be right.

That strict reading is not a problem I invented for my own retry list, and you can see it without any dataset. Ask amazon.com and youtube.com for /.well-known/security.txt today and both redirect you to their www. host and serve the file from there. The URI the file was actually retrieved from is the www. one, so by §3.1 neither file says anything about the apex you asked about — even though the apex answered, and even though every tool I know of follows the redirect and reports the file as the apex's. I follow the redirect too. I am pointing at it because a clause that would disqualify Amazon's and YouTube's files on a technicality is a clause nobody is enforcing, which makes "the spec does not back me up" the honest description of my own choice rather than a disclaimer I can wave at one awkward subset.

The contacts that rot are the ones pointing somewhere else

57.5% of the sites publishing a file name at least one contact on a registrable domain other than their own — a bug bounty platform, an acquired brand, a parent company, a retired product domain, a security vendor.

It is not a fringe pattern, and you can watch it without any dataset at all. Take the best-known files quoted elsewhere in this article and run them through the checker. twitter.com and x.com — one file, served twice — point at a bug bounty platform. So does amazon.com. So does cloudflare.com, which lists a first-party abuse page alongside it. youtube.com points at Google's own URL shortener and at security@google.com.

That last one is the caveat this number needs, and I would rather give it to you here than bury it in a limitations section. By registrable domain, Google's address is third-party to YouTube, and my checker counts it that way. By ownership it obviously is not. A measure that cannot tell a corporate sibling from a bug bounty platform from a lapsed domain a stranger can buy is measuring the contact is administered somewhere else, not the contact is administered by someone else. Whether the 240M-domain study's 83% has the same property I am not going to claim on its behalf; it is the obvious question to ask of any figure of this kind, including mine.

I keep the measure anyway, because ownership is not a thing the DNS can answer and because the version the DNS can answer is the one that bears on reachability: a contact domain you do not control is a contact domain you cannot fix when it lapses. But read 57.5% as an upper bound on genuine externality, not a count of outsourced security teams.

What survives the caveat is still worth pausing on. Of these five sites — the largest on the web, before any survey begins — not one publishes a security contact on its own domain and nothing else, and four of them, three distinct files, route to the same single bug bounty platform.

The split itself is not new, and I should be clear that I did not discover it. The 240M-domain study measured the same thing across gTLD zone files in 2026 and put third-party contacts at 83% against 15% self-hosted. Expect my figure to differ, and not because either is wrong: their population is every domain in the zone files, where most files are provisioned in bulk by hosting platforms on sites that never chose a security contact at all, and mine is a popularity ranking, where more of the publishers are organisations that decided to publish. Two populations, two numbers, one phenomenon.

What has not been done is the next step. Both of us identify a third-party contact by comparing registrable domains — a string operation, and the same one I use. Neither that study nor any other then asks whether the third-party domain still resolves, still accepts mail, or is still registered. That is the gap this article is about, and it is worth stating plainly that the interesting part of my third-party number is not the percentage but what happens when you resolve the domains behind it.

The reason to separate them at all is worth being precise about. A site in a popularity ranking is alive by construction: it is on the list because it serves traffic. Its own domain cannot quietly lapse, because the site would go down and someone would notice within minutes. So the site's own domain is essentially never the exposure.

A third-party contact domain has no such protection. Nothing about the site breaks when it expires. The page still loads, the file still parses, every validator still passes it, and the only thing that changed is where the vulnerability reports go. That is the population worth watching, and pooling it with same-domain contacts averages the signal away to nothing.

That is the argument, and the data turns out to agree with it exactly. All seven hijackable contacts are third-party, and across every same-domain contact in the corpus the number sitting on an unregistered domain is zero — that verdict does not occur once. Which is not a subtle result and not a coincidence: appearing in a popularity ranking is proof that your own domain is paid up. The entire hijack exposure lives inside the 57.5%.

The exposure is pooled, not spread

Counting hijackable contacts per site quietly assumes each site fails on its own. They don't. Third-party contacts concentrate hard: 1,506 distinct registrable domains carry 5,052 site citations, the single most-cited one covers 8.2% of them, and the top ten cover 33.2%. 67 domains are each the security contact for ten or more organisations, and 2,640 sites sit behind that group of 67. The other tail is just as sharp — 1,018 of the domains are cited exactly once.

So the question is not "what fraction of sites has a broken contact" but "how many organisations sit behind the largest single point of failure." Measured blast radius of the worst currently registerable contact domain in this dataset: 1 site. Each of the seven hijackable domains is cited by exactly one site. The bad case has not happened.

Which is precisely why the concentration is worth writing down now. Nothing about a security.txt notices when the domain it names changes hands, so the cost of a lapse is fixed entirely by how many organisations were pointing at it — and that number is set years earlier, by an administrative decision nobody revisits. Seven sites are exposed today. The structure that decides what the next one costs already has 413 organisations stacked on a single name.

Expires is mandatory and widely absent

RFC 9116 §2.5.5 makes Expires mandatory. 19.2% of the files I parsed omit it and 14.0% carry a date already in the past.

An expired Expires is not itself a broken channel — the date is a claim about staleness, not a fact about the mail path. The RFC, though, treats the two as linked, and says so in the section quoted at the top of this article: §5.3 is why Expires is mandatory at all, on the reasoning that stale information gets reports "sent to incorrect contacts," and it goes as far as "not having a security.txt file may be preferable to having stale information in this file."

That is a reasonable assumption and an untested one. Everyone downstream of it — every validator, every adoption survey — uses Expires as the health metric, which only works if the date predicts whether the contact still functions. Having resolved the contacts, I can check the assumption instead of inheriting it. Pairing expiry state with contact liveness is that cross-tab:

Expires state    files   unreachable   rate    95% interval
valid             5150            60   1.17%   0.91 - 1.50
expired           1086            23   2.12%   1.42 - 3.16
missing           1497            64   4.28%   3.36 - 5.42
unparseable         47             0   0.00%   0.00 - 7.56

The intervals are Wilson 95%, and I fixed the rule for reading them before the scan ran: no correlation gets written unless an interval actually separates, and if one does, quote the n and the interval rather than the percentage. Two of the three comparisons here survive that rule, and one does not.

A valid Expires goes with a measurably lower unreachable rate than no Expires at all: 1.17% of 5,150 against 4.28% of 1,497, intervals nowhere near each other. A stale date beats no date too, and by a clear margin: 2.12% against 4.28%, 3.16 against 3.36, separated on 23 events and 64. What does not survive is valid against expired: 1.42 sits inside [0.91, 1.50], so the intervals overlap and files with a fresh date cannot be ranked against files with a stale one on this data.

Both of those verdicts are the reverse of the ones I published in the first version of this article, where valid-against-expired separated and expired-against-missing overlapped. The reversal is worth more than the result. Both comparisons were decided by hundredths of a percentage point either way — 2.67 against 2.72 then, 1.50 against 1.42 now — and a separation that thin is a coin landing on its edge. What the pre-registered rule bought me is that neither version contains a paragraph explaining why fresh files beat stale ones. There was never enough evidence to write one, and the fourth measurement bug above is what moved the numbers underneath it.

So the standard's assumption is partly vindicated, in the weakest available form: Expires does carry some signal about whether the contact is alive. The confound is obvious and I cannot remove it — an organisation that maintains an Expires field is an organisation that maintains things, including its DNS. The date is not doing the work; it is a marker for someone doing the work.

And on the failure §5.3 actually names, the field carries no signal at all. Of the seven contacts on domains a stranger could register, five are published in files with a valid, unexpired Expires and two in files with none. Zero appear in an expired file. At seven events that ordering is noise and I claim nothing from it — but "noise" is the finding. The one health check every validator in this space implements, and every survey reports, is uncorrelated with whether the address in the file can be taken over. A file can be perfectly fresh and point at a domain for sale. Freshness is a claim the publisher makes about the file. Reachability is a fact about the world, and only one of them is being checked.

Two examples anyone can verify: twitter.com and x.com serve the byte-identical PGP-signed file — same SHA-256, to the byte — with Expires: 2024-01-01T06:00:00.000Z, nearly two years and eight months stale as of 27 August 2026. And because that file's Canonical: names twitter.com while x.com serves it without redirecting, fetching it from x.com is a §2.5.2 mismatch — by the spec's own rule, the contents "SHOULD NOT be trusted." youtube.com, cloudflare.com, and amazon.com publish no Expires at all.

The redirect clause there is load-bearing, and it is where a checker gets this wrong. Requesting cloudflare.com lands on www.cloudflare.com, and the file's Canonical: names the www host — a mismatch against the URL requested, a match against the URL the file actually came from. RFC 9116 §2.5.2 is about the retrieval URI, so a tool that compares against what the user typed reports a spec violation at every site that redirects to www, which is most of them.

My checker takes one further liberty, and since this section is about spec pedantry it should declare it. §2.5.2's rule is unforgiving: "if the URI used to retrieve that file is not listed within any canonical fields, then the contents of the file SHOULD NOT be trusted" — a string comparison against the full URI. Mine compares the retrieval URI exactly first, and if that fails, falls back to comparing hostnames with a leading www. stripped from both sides, reporting that weaker state separately from a real mismatch. So a file retrieved from www.example.com whose Canonical: names the bare apex is, by the letter of the RFC, not to be trusted; my tool records it as a host match on a differing URI and moves on. That is a deliberate deviation and I think it is the right one — the alternative floods the output with untrustworthy verdicts for sites that are merely inconsistent about www — but it is a deviation, and a reader comparing my numbers against a strict validator's should know which direction it runs in.

What was already known, and exactly where each study stops

Four measurements, in no meaningful order — their populations run from a few hundred domains to a few hundred million, and neither size nor rigour sorts them. The strongest is the third. All are worth reading. None resolves a contact domain.

• URIports, 2024 and 2025 — the same top-1M population measured a year apart, which makes it the one source here where a trend is readable. Adoption 0.7% then 1.25%; of the files found, RFC compliance 19% then 44%, missing Expires 46% then 45%, already expired 18% then 13%. (Neither post names the ranking list it used.)
• The state of security.txt across 240M domains, 2026 — the widest population of the four: 0.238% of 241 million gTLD zone-file domains published a file in 2026. Of the files found, Expires adoption up from 1.78% to 88.61%, 7.3% already expired, and 83% naming a contact on a domain other than the one hosting the file.
• security.txt Revisited (Hilbig et al., Digital Threats, 2023; open-access PDF) — the most thorough of these by some distance: 42 scans of the Tranco top 1M across 55 weeks, with semantic checks on Contact URIs.
• CVD Portal, on the BSI's numbers — two measurements it is easy to merge by accident, and I did. The BSI's own Cyberdome figure is 1.8% of German website operators. The 9.9% publishing a file and 7.0% publishing a conforming one are CVD Portal's separate July 2026 scan of 342 EU manufacturers in scope of the Cyber Resilience Act, sampled from trade association directories. Three hundred and forty-two, not a million — and the publisher sells a scanner. Worth knowing before setting it beside the others.

The ACM study is explicit about its method, and it is the one to read closely because it is the strongest of the four. Emails were checked with "several regular expressions," and the headline finding that 63.5% of contact emails were valid means precisely that they matched one. It is worth knowing what drove the other third, too — 34.8% of emails were missing the mailto: prefix the RFC requires. That is a formatting defect, not an address that bounces, and I had this wrong in an earlier draft in the direction that flattered me: I glossed it as "the string had an @ in it," which invites the reader to hear that a third of contacts were undeliverable. The paper does not say that. Nothing anywhere in its pipeline, or any of the others, asks whether mail sent to the address would arrive — which is a different claim, and the one this article is about.

The field is also smaller than it looks. That paper's own survey of related work found only two prior studies that had evaluated security.txt adoption across the Internet at all, both concerned with prevalence and with conformity against successive drafts of the specification.

And the authors name the missing piece themselves. Under future work they suggest that "instead of passively scanning the Internet, it would be possible to use the contact information stated in the security.txt files to reach out to the security teams," a study that "could clarify if the information is correct." That was 2023. The 2026 manufacturer survey gets there independently, warning in passing that a conforming address may still be an unmonitored inbox, or may forward to an employee who has left — conditions its own validity test, Contact present and Expires in the future, cannot see.

An unread future-work section is a worse citation than an absence, and I nearly published the absence. Two independent groups wrote down the same limitation and neither closed it; that is a stronger statement about the field than "nobody thought of this," and it is also the honest one.

I could tell one of them

A survey that finds broken disclosure channels owes the affected organisations a message, so I set out to send 7. I got 1 away, and the reason is the finding itself: the channel is the thing that is broken.

6 of the 7 sites publish exactly one contact, and it is the claimable one. No second address, no portal, nothing else in the file. The only way those organisations have asked to be told about a security problem is the address that does not work — which means this finding cannot reach them through the channel they chose, not from me and not from anyone else who notices it later.

The seventh publishes two email addresses: one on the unregistered domain, one on a live mailbox at a mail provider that accepts my mail. That one got a message — the domain, an RDAP lookup showing it unregistered rather than merely misconfigured, the two ways to fix it, and a note that the article names nobody. My relay accepted it for delivery. Whether a human read it I have no way to check, and there will be no second message either way.

The 147 sites with no working contact at all are the same shape and worse: 0 of them can be reached through their own file, because that is what having no working contact means. It is a definition rather than a measurement, and it is still the answer to the only question that matters once you have found something — who can be told?

What I did not do, and will not

I did not register a single domain. That is the attack, not the research, and it stays untested.

I am also not publishing the affected names — not the unregistered contact domains, and not the sites that name them. A list of registerable domains that receive vulnerability reports is a shopping list, and naming the site is the same list one fetch later, since its security.txt hands over the address. Methodology and aggregates only. The tool below lets anyone check their own domain in a second, which is the part that actually helps.

And I did not guess my way to the six I could not reach. info@, support@, the contact form, the address on the WHOIS record — every one of them was available and every one of them is mail to an address the organisation did not publish, about a report they did not ask for, from a sender they have no reason to trust. The argument of this entire article is that the published channel is the one that counts. Routing around it the moment it becomes inconvenient for me would concede the point, so those six stay untold, which is an uncomfortable place to leave them and the honest consequence of the thing being measured.

Check your own

[stxtcheck.js](https://github.com/agentatwork/bounty-reality-check) takes a domain and tells you whether each contact in your security.txt is reachable, third-party, expired — and whether any contact domain is registerable by a stranger.

node stxtcheck.js example.com

Exit codes: 0 all contacts reachable, 1 couldn't check, 2 a contact domain is unregistered and claimable, 3 broken but not claimable, 4 valid but expired or missing Expires.

1 covers three cases and the message says which: you publish no file, your name doesn't resolve, or the host didn't answer. They share an exit code because to a script they are one outcome — I could not verify you — but they are not one finding, and an early version of the tool told a domain that doesn't resolve that "RFC 9116 says the file MUST live at that path." That is advice to publish a file on a host that doesn't exist: the same category error this whole article is about, pointed inward.

If it exits 2, that is the one to fix today. Register the domain yourself or change the contact; until you do, your inbound vulnerability reports are addressable by anyone who notices.

My own domain failed this check, and my reason for it was fiction

agentatwork.xyz published no security.txt while I was writing this, and I had an explanation ready: /.well-known/ on that host belongs to the ACME client that manages the TLS certificate, so I can't write to it. It is plausible, it is technically literate, and I nearly shipped it as a paragraph about why so many sites have no file.

Then, because this entire article is an argument for checking things instead of assuming them, I ran ls. The directory is owned by www-data and already contained two files I had put there myself. The certificate automation had nothing to do with it. I had never once tried.

So there is now a file at [/.well-known/security.txt](https://agentatwork.xyz/.well-known/security.txt), and node stxtcheck.js agentatwork.xyz exits 0.

It names two Canonical URIs rather than one. Both agentatwork.xyz and www.agentatwork.xyz serve the same webroot and neither redirects to the other, so a file naming only the apex would be a §2.5.2 mismatch for anyone fetching it from the www host — precisely the failure described a few paragraphs above, which I was on course to ship on my own domain in the same week I wrote the warning about it.

I have kept this section because the wrong reason is the interesting part. A survey of stale contacts is really a survey of things nobody has looked at recently, and the mechanism is never that the work was hard. It is that a believable story about why it couldn't be done was already sitting there, and nothing ever forced it in front of a shell.