.well-known · IANA registry · conformance
Audit your whole
/.well-known/ directory.
There are separate validators for security.txt, mta-sts.txt, Apple/Android 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.
What it checks
One report for the whole directory
security.txt
RFC 9116: a required Contact, a valid non-expired Expires, plus Policy / Encryption / PGP signing.
mta-sts.txt + DNS
RFC 8461: version, mode, mx and max_age in the file — cross-checked against the _mta-sts DNS TXT record it needs to actually work.
App links
apple-app-site-association (valid JSON, correct content-type, no redirect) and Android assetlinks.json.
Identity
openid-configuration and oauth-authorization-server expose the required discovery endpoints; CardDAV/CalDAV auto-discovery.
Privacy & web
gpc.json (Global Privacy Control), change-password, host-meta, traffic-advice and more.
Honest about absence
Missing files are shown as informational, with what each one is for — never counted against you. Only real problems are flagged.
Open methodology
Every rule, in the open
No mystery score. Here is exactly how each file is judged — so you can verify and trust the result.
- ProbeFetch every catalog path at https://<domain>/.well-known/… in parallel (plus the off-root mta-sts.<domain> host), recording status, content-type and whether it redirected.
- Present / absentPRESENT on 2xx (or an expected redirect for change-password / carddav / caldav); ABSENT on 404/410; RESTRICTED on 401/403. Absent files are informational, never errors.
- JSON filesapple-app-site-association, assetlinks.json, openid-configuration, gpc.json, etc. must parse as JSON with the right content-type; FAIL if invalid.
- No-redirect filesapple-app-site-association must be served at the exact path — a redirect is a FAIL (Apple refuses it).
- security.txtRequires a Contact field (FAIL if missing) and an Expires field; an expired date is a FAIL. Notes Policy, Encryption and PGP signing (RFC 9116).
- mta-sts.txtRequires version: STSv1, a mode, and mx patterns; mode "testing"/"none" is a WARN. Cross-checked against the _mta-sts DNS TXT record over DNS-over-HTTPS (RFC 8461).
- OpenID / OAuthopenid-configuration and oauth-authorization-server must expose the required discovery fields (issuer, endpoints, jwks_uri).
Related: for deeper email setup (SPF/DKIM/DMARC + MTA-STS) see spam-check; for AI-crawler access and llms.txt see aicrawlcheck.
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.