About the scanner

What this scanner does

• It only runs when a person requests it. There is no crawling, no scheduled scanning and no target list – a scan starts either because someone typed a domain into the form on this site, or because someone opened a link that already carries one (/?domain=example.com). Repeat visits within the hour are answered from the cache and open no new connections to your servers, and crawlers that honour robots.txt do not trigger a scan at all.
• It is read-only. It sends a handful of plain GET requests over HTTP and HTTPS – the homepage, /.well-known/security.txt and, only if that one yields nothing, the older /security.txt; an MTA-STS policy from mta-sts.<domain>; a BIMI logo and mark certificate from the URLs your own record names; and – only when your security.txt names a key or is signed – that key URL plus the Web Key Directory lookup for its contact address, under /.well-known/openpgpkey/ on your domain and on the host openpgpkey.<domain>. It performs TLS handshakes on port 443 and a short QUIC probe on UDP 443 per address family (that is the HTTP/3 check), and connects to the domain's MX servers on port 25 to check STARTTLS – no mail is sent, the session ends with QUIT.
• It does not test for vulnerabilities. It evaluates published configuration (certificates, TLS versions, DNS records, HTTP response headers) against public standards – the same checks tools like SSL Labs, internet.nl, or securityheaders.com perform.
• It is rate-limited, throttled and cached. A full scan opens roughly 50 to 120 short-lived connections to your web server – most of them TLS handshakes, because every cipher suite has to be probed individually and one backend per address family is profiled in full; a server with a long list of enabled suites is at the upper end, a TLS-1.3-only server at the lower one. On top of that come up to about 40 SMTP connections spread over your five best-preferred MX hosts, and one query per authoritative name server on port 53. The TLS and mail probes are throttled so that only a handful run at a time. Results are cached for one hour, so re-checking a domain within that window triggers no new connections. A manual refresh can force a re-check, but only once per minute per section.
• Most DNS lookups do not touch your infrastructure. They go through public DNS-over-HTTPS resolvers (Google, Cloudflare). Two checks are the exception and query your authoritative name servers directly on port 53: one asks whether they answer authoritatively, agree with each other and match the parent delegation, and one attempts a zone transfer (AXFR) against each of them to test for exposure.

How to identify it

HTTP requests carry this User-Agent:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36 (compatible; domainsecuritycheck.de/1.0; +https://domainsecuritycheck.de/scanner.html)

The Chrome prefix makes servers respond as they would to a regular browser (so the results reflect what real visitors get); the (compatible; …) token identifies the scanner honestly, following the same convention as Googlebot or Bingbot.

All connections (HTTP, TLS probes, SMTP) originate from these addresses:

Note: TLS handshakes (protocol/cipher checks) and SMTP STARTTLS probes carry no User-Agent – for those, the source IP and reverse DNS are the reliable identifiers.

Mail sender identity (receive test)

The receive test additionally delivers to a domain's mail servers after that domain has proven control (by sending us an authenticated message from it). Those outbound messages leave from a dedicated pair of addresses on the mail-test.domainsecuritycheck.de subdomain — kept separate from the main scanner IPs above so mail reputation never touches the website IP:

We only ever deliver to a domain that has just proven control, and only to the exact address that contacted us — never to an address you type in. To never receive a probe again, use the opt-out in the message or email abuse@mail-test.domainsecuritycheck.de.

How to block it

If you do not want your domain to be scannable here, block either the User-Agent token (HTTP checks) or the source IPs (all checks). The token domainsecuritycheck.de is stable and will not change.

By User-Agent

nginx:

if ($http_user_agent ~* "domainsecuritycheck\.de") {
    return 403;
}

Apache (.htaccess):

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} domainsecuritycheck\.de [NC]
RewriteRule ^ - [F]

Caddy:

@dsc header_regexp User-Agent (?i)domainsecuritycheck\.de
respond @dsc 403

Cloudflare / WAF: create a custom rule – User Agent contains domainsecuritycheck.de → Block.

By IP address

# Linux (nftables)
nft add rule inet filter input ip saddr 159.195.68.98 drop
nft add rule inet filter input ip6 saddr 2a0a:4cc0:c2:23fb::1 drop

What blocking changes

• A User-Agent block stops every check that goes over HTTP: security headers, the redirect and mixed content – and the security.txt probe together with any PGP key URL and Web Key Directory lookup it triggers. It also reaches two mail-side checks, because they are HTTPS fetches too – wherever your block also covers the policy host mta-sts.<domain> or the host serving your BIMI logo, the report then says the policy is not retrievable and the MTA-STS finding drops from pass to warn. The TLS handshake probes, DNS and DNSSEC are unaffected, and so is the SMTP part of the mail checks: they use neither HTTP nor a User-Agent.
• An IP block additionally stops the TLS and SMTP probes – and, applied on your authoritative name servers, the two direct port-53 checks described above; they then report that no name server answered us. The remaining DNS/DNSSEC/email-authentication data is read through third-party DoH resolvers and cannot be blocked at your servers.
• Either way, a blocked scan typically lowers the displayed grade for anyone testing your domain here – blocking hides your configuration, it doesn't improve it.