.well-known · IANA registry · conformance
Audit your whole /.well-known/ directory.
There are separate validators for security.txt, mta-sts.txt, app links and OpenID — but
nobody checks them all at once. wellknownaudit scans every path in the IANA well-known registry in one pass, tells you which
files exist, and runs each file's own conformance rules — including the MTA-STS file against its required DNS record.
One report for the whole directory
RFC 9116: a required Contact, a valid non-expired Expires, plus Policy / Encryption / PGP signing.
RFC 8461: version, mode, mx, max_age — cross-checked against the _mta-sts DNS TXT record it needs to work.
apple-app-site-association (valid JSON, right content-type, no redirect) and Android assetlinks.json.
openid-configuration, oauth-authorization-server, CardDAV/CalDAV, gpc.json, change-password and more.
Honest about absence
Almost no site has all of these — most apply only if you run apps, email or an identity provider. Missing files are shown as informational, never errors. The audit only flags real problems: a file that is malformed, expired, served via a redirect when it shouldn't be, or inconsistent with its DNS record. Open, published methodology — no black-box score.
Frequently asked questions
What is the /.well-known/ directory?
It is a standardized folder at the root of a domain (RFC 8615) where machine-readable files live at predictable paths — security.txt, mta-sts.txt, apple-app-site-association, assetlinks.json, openid-configuration and many more. Browsers, apps, mail servers and security scanners look for them automatically. wellknownaudit fetches every well-known path we know about and tells you which exist and whether each one is set up correctly.
How is this different from a single-file validator?
There are good validators for individual files (a security.txt checker, an AASA validator, an MTA-STS checker). wellknownaudit runs them all at once against the IANA registry, so you get the whole directory in one report instead of testing each file on a different site — and it cross-references related signals (for example the mta-sts.txt file against its required _mta-sts DNS record).
Is it bad if most files are missing?
No. Almost no site has all of these — most apply only if you have an iOS/Android app, run email, or operate an identity provider. Missing files are shown as informational, not errors. The audit only flags real problems: a file that exists but is malformed, expired, served wrong, or inconsistent with its DNS record.
What does it check for each file?
Presence and HTTP status, HTTPS, content-type, and whether it is served via a redirect — plus per-file conformance: RFC 9116 fields and expiry for security.txt; version/mode/mx/max_age for mta-sts.txt (and its _mta-sts DNS TXT record); valid JSON and required keys for apple-app-site-association, assetlinks.json, openid-configuration, gpc.json and others.
Why does the MTA-STS check look at DNS too?
MTA-STS only works if BOTH the policy file (at mta-sts.your-domain) AND a _mta-sts DNS TXT record exist. A file without the record is silently ignored by senders. wellknownaudit checks the DNS record over DNS-over-HTTPS and warns when only one half is present.
Is my data safe?
The audit runs on Cloudflare and only fetches public http(s) URLs at well-known paths; requests to private, loopback, link-local and cloud-metadata addresses are blocked, responses are size- and time-capped, and we keep no logs of the domains you check.
Where does the list of files come from?
From the IANA Well-Known URIs registry and the specs that define each entry (RFC 9116, RFC 8461, RFC 8414, RFC 6764, RFC 7033, OpenID Connect Discovery, Apple/Google app-link specs, Global Privacy Control, and more). Every entry links to its spec in the reference below.