What ZNIMOK checks, and what it does not

How one check runs

You enter a domain. The check then goes through the same steps every time, and the report page shows each step live as evidence comes in. Most checks finish in a few minutes; sites with many subdomains take longer.

• Find hosts: subdomains and related names from DNS, mail (MX) records and public certificate logs.
• Keep the live ones: names that do not resolve are skipped; hosts that answer go on to the next steps.
• Identify the stack: server, language, CMS and CDN from public headers and HTML, so only checks that fit the stack run.
• Run the checks in the areas below: read-only requests, DNS lookups and TLS handshakes.
• Match versions: detected software versions are compared with public vulnerability and end-of-life data.
• Build the report: findings, a score and coverage, written by fixed rules from the evidence. No AI model writes or reviews the report.

A check of one of our own sites on 27 Oct 2026 came to 408 check steps across 8 hosts. The number depends on how many hosts and technologies a site has.

Domain and subdomains

Attackers start by listing the hostnames of a domain, so the check does the same and shows you what it found.

• Subdomains from DNS lookups of a short list of common names (such as www, api, mail, admin), from MX records, from Certificate Transparency logs via crt.sh and from robots.txt.
• Dangling CNAME records: a name that still points to a service you no longer use can sometimes be taken over by someone else.
• CAA records (which certificate authorities may issue certificates for the domain), name server health and DNSSEC.
• Domain registration and expiry date from RDAP, the registries’ public lookup service.

DNS checks only read public records. There is no zone transfer.

TLS and HTTPS

• Whether plain HTTP redirects to HTTPS.
• Certificate validity: expired, expiring soon or not yet valid.
• Whether the certificate covers the hostname it is served for.
• Weak signature algorithms and weak keys.
• Whether the server still accepts TLS 1.0 or TLS 1.1, which RFC 8996 deprecated in 2021.
• Changes of certificate issuer or covered names compared with earlier checks of the same site.

This is not a full TLS configuration audit: the check does not try every cipher suite.

Email security

These DNS records decide whether someone can send mail that looks like it comes from your domain, and how other mail servers protect mail on its way to you. Read more on the email security check page.

• SPF: whether there is exactly one record, whether it is too permissive and whether it stays within the DNS lookup limit.
• DMARC: whether a policy exists, which one (none, quarantine or reject) and whether reports are requested.
• DKIM: keys on a fixed list of common selector names. A key published under another selector name is not visible to an outside check.
• MTA-STS and TLS-RPT: whether mail to your domain should use TLS, and whether failures get reported to you.
• MX records, and SPF published for a domain that has no MX.

For a site without verified ownership, the check does not connect to your mail server. On a site with verified ownership, the active port check can read the mail server software version, and only the verified owner sees it.

Browser security controls

Response headers tell browsers how to protect your visitors. Details are on the security headers check page.

• HSTS (Strict-Transport-Security) and its max-age.
• Clickjacking protection: X-Frame-Options or the CSP directive frame-ancestors.
• X-Content-Type-Options: nosniff.
• Content-Security-Policy: whether it exists, and risky script sources such as unsafe-inline or wildcards.
• Cookie flags on session-like cookies: Secure, HttpOnly and SameSite.
• CORS: we send a request with a foreign Origin and check whether the answer lets any site read it.
• Mixed content, Subresource Integrity on third-party scripts, and headers that reveal server versions.
• Whether these headers are the same on every address of the site, for example with and without www.
• security.txt (RFC 9116): a contact file for people who report security issues.

Exposed files and panels

We request a fixed list of well-known paths with ordinary GET requests and read the answers. First we learn what the site’s own “not found” page looks like, so a site that answers every address the same way does not produce false findings.

• Secret and config files: .env, .git, copies of config files, phpinfo.
• Backups and database dumps left after a deploy.
• Admin and login pages, such as /admin, /wp-admin or webmail, and admin-like hostnames.
• Database tools such as phpMyAdmin, Adminer and pgAdmin, and hosting or DevOps panels such as cPanel, Plesk and Grafana.
• Debug tools left in production, such as Laravel Telescope, Ignition or Spring Boot Actuator, and public log files.
• API documentation (Swagger, OpenAPI, GraphQL) and public source maps.
• Directory listings and public cloud storage buckets.

The check does not log in and does not try passwords on the pages it finds.

Software and known vulnerabilities

We identify server software, languages, CMS, frameworks and JavaScript libraries from headers, HTML and asset paths. Where a version is visible, we compare it with public data. More on the outdated software check page.

• End of life: whether the release line still gets security fixes (data from endoflife.date).
• Known vulnerabilities for that product and version from NVD, OSV and the CISA Known Exploited Vulnerabilities catalog.
• FIRST EPSS scores, which estimate how likely a known vulnerability is to be exploited.
• Whether a newer security release of the same line exists, for example for PHP.
• Checks for WordPress, Drupal, Joomla, Magento, PrestaShop and Ghost, and leftovers of Laravel, Symfony and Node.js or Next.js setups. See the WordPress security check.

A version match means the site may be affected and needs checking. It is not a confirmed vulnerability: banners can be wrong, and Linux distributions often fix a flaw without changing the version number. A hidden version is not proof of safety either.

Network ports

For a site without verified ownership, the check does not scan ports. It shows the ports that a public internet database (Shodan InternetDB) lists for the site’s addresses.

For a site with verified ownership, ZNIMOK also actively checks a curated list of service ports over TCP and UDP: databases, remote access, caches, message brokers and admin services. Only the verified owner sees the results.

Also in the report

• Page speed for mobile and desktop from Google PageSpeed Insights.
• Legal documents: whether a privacy policy, a cookie notice, a consent tool and, for .de and .at sites, an Impressum can be found. We check presence only, not content. This is not legal advice.
• AI crawler access: whether robots.txt lets crawlers such as GPTBot or ClaudeBot read the site, and whether an llms.txt file exists.
• Public domain records: registration data, certificates, hosting network and the first archived copy in the Wayback Machine.

Free check and verified owner

Anyone can run the free check on any public website. Checks that send active probes run only on sites whose owner has proved control of the domain, and their results are shown only to the verified owner.

To verify ownership, add a DNS TXT record znimok-site-verification=…, upload the file /.well-known/znimok-ownership.txt or add a znimok-site-verification meta tag to your home page. The token is shown in your dashboard.

What the check does not do

• It does not scan for malware and does not check blocklists.
• It does not log in, guess passwords or send attack payloads such as SQL injection or XSS.
• It is not a penetration test. It cannot see inside your server, your code or your internal network.
• It cannot prove that a site is secure. No findings in an area means we saw nothing in what we checked, not that nothing is there.
• If a firewall, rate limit or challenge page stops part of the check, the report marks that part as not checked instead of passing it.

How results are rated

Each finding has a level, High, Medium or Low, and says what we saw, why it matters and what to do.

The report also gives a score from 0 to 100, where higher is safer. The score sums everything that was checked. While a High finding is open, the risk rating stays at Elevated or worse, whatever the score.

Coverage shows how many checks finished and how much of the site could be fully assessed. Lower coverage means more blind spots, not more risk.

Data sources