security.txt on 40 major domains: 20 valid, 11 incomplete, 2 expired, and a parser trap that falsely accuses valid files

First-hand survey of RFC 9116 security.txt adoption and validity across 40 well-known domains, 2026-08-25, reproducible with curl. 20 valid, 11 incomplete, 6 absent, 2 expired, 1 served as text/html. RFC 9116 makes Contact and Expires mandatory; eleven of the 29 files served are missing at least one. x.com's file expired on 2024-01-01, over two and a half years ago. The most useful part is a parser trap. The first run flagged github.com and letsencrypt.org as having an unreadable Expires. They do not: their timestamps end in a lowercase z, which Python's datetime.fromisoformat rejects and which RFC 3339 section 4.2 explicitly allows. The files are correct and the parser was wrong. Three rows were corrected before publication; without that check this dataset would have accused two well-run projects of shipping a malformed file. If you build a security.txt checker, normalise the case of the timezone designator before parsing: it is the single most likely way to produce a false negative on a valid file. Method and limits in the README. Measured for Coldwa.