Questions
How the scanning works, where it is deliberately cautious, and what the results do and don't mean.
No. There is no signup, no login, and no email required. Enter a domain and you get a report.
The "My domains" list is saved in your own browser's local storage — it never reaches a server, so there is nothing to sign into and nothing for us to lose. Clearing your browser data clears the list.
Yes. Every check reads information that is already published to the world — DNS records, the TLS certificate your server hands to any visitor, and ordinary HTTP response headers. Nothing about a scan requires permission, because nothing about it is privileged.
This also means a scan is indistinguishable from a normal visit. It is one DNS batch, one TLS handshake, and two HTTP GETs.
A report is cached for one hour. Loading a report page within that window shows the cached result; after it, a fresh scan runs automatically.
The Rescan button on your domains list, and Re-run scan on a report, always force a fresh check regardless of the cache.
Yes, per IP address, to keep the service responsive. Normal use will not hit it. If you do, the page tells you plainly rather than showing a broken report.
Because DKIM selectors are not discoverable. A key lives at <selector>._domainkey.yourdomain.com, and the selector name is chosen by whoever configured your mail — there is no DNS query that enumerates them.
Veritsu probes twenty selectors used by the common providers. Finding one proves DKIM is configured. Finding none proves only that you are not using those twenty names, so reporting it as a failure would be dishonest. It is flagged as inconclusive instead.
Some domains answer every *._domainkey lookup with the same record, often a null key (p= with nothing after it) that means "this key is revoked".
A naive scanner probing common selectors would get an answer every time and report a confident pass. Veritsu first queries a selector nobody would ever publish; if that returns a record, it knows the domain answers everything, and reports the result as inconclusive rather than claiming a key it cannot actually verify.
The version your server prefers is not the same as the versions it will accept. Veritsu makes a second connection that offers only TLS 1.0 and 1.1 — if the handshake succeeds, those protocols are still reachable by anyone who asks for them, and the check fails even though normal traffic uses TLS 1.3.
Yes. The scan requests your site the way a browser does, so whatever your CDN or load balancer adds is exactly what gets measured. If you set headers only at the origin and your CDN strips them, the scan will correctly report them as missing — which is the real state visitors experience.
Two common causes. First, single-page apps often answer every unknown path with the HTML app shell; Veritsu detects an HTML response and rejects it, because a researcher's tooling would too.
Second, RFC 9116 requires both a Contact and an Expires field. A file missing Expires, or carrying a date in the past, is reported as a warning — an expired policy signals an unmaintained disclosure process.
Only that, at the time shown, the listed number of external checks passed for that domain. It is a snapshot of publicly observable configuration.
It is not a certification, an audit, a penetration test, or a compliance attestation. It says nothing about your application code, your internal network, or your data handling.
Yes, and this is a deliberate, documented limitation. Veritsu does not verify domain ownership, so the badge reflects public scan results without implying that whoever embedded it controls the domain.
Because the badge always links back to the public report for the domain it names, a mismatch is visible to anyone who clicks it.
No. It is generated at request time from the most recent scan, and a badge for a domain that has not been scanned recently triggers its own fresh scan. If a check starts failing, the badge changes colour and text on its own — there is no way to freeze it on a good result.
Scan results for the domains that have been scanned — the same public information the report displays — plus a short-lived per-IP counter for rate limiting.
No accounts, no email addresses, no analytics or third-party trackers. Your saved domain list lives only in your browser.
Yes. A report at /r/<domain> is readable by anyone with the link, by design — that is what makes the badge verifiable. Since every result is derived from public data, a report exposes nothing that was not already visible.
Or read what each check tests in the check reference.