domainsecuritycheck

About the scanner

You found this page because the scanner of domainsecuritycheck.de appeared in your logs – most likely via the link in its User-Agent. This page explains what the scanner does, how to identify it, and how to block it if you prefer not to be scanned.

What this scanner does

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:

IPv4 159.195.68.98
IPv6 2a0a:4cc0:c2:23fb::1
Reverse DNS domainsecuritycheck.de – forward-confirmed: the PTR name resolves back to the same IP (the same verification scheme search engines recommend for their bots).

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:

IPv4152.53.172.28
IPv62a03:4000:20:221::1
Reverse DNSmail-test.domainsecuritycheck.de – forward-confirmed (FCrDNS), with SPF, DKIM and DMARC published for the subdomain.
Envelope senderb-<token>@mail-test.domainsecuritycheck.de (VERP, for bounce correlation). Every probe is a fixed, harmless, clearly-labelled automated test message (Auto-Submitted); the opt-out is in the message body.
Receiving TLSThe subdomain also receives mail (the proof message and any bounces), so it publishes MTA-STS (mode=enforce) and TLS-RPT — inbound delivery to it is TLS-enforced, and we dogfood the same policies we grade.

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