All checks in detail

Name servers answer DNS queries for your domain. At least two, reachable over both IPv4 and IPv6, improve resilience and reachability.

The A record maps your domain to an IPv4 address so IPv4-only clients can reach it.

The AAAA record maps your domain to an IPv6 address so IPv6-only clients can reach it and the site stays reachable as networks move to IPv6.

MX records tell other mail servers where to deliver e-mail for your domain.

CAA records declare which certificate authorities may issue TLS certificates for your domain, reducing the risk of mis-issuance.

DNSSEC cryptographically signs DNS answers so resolvers can detect tampering and spoofing.

Without working DNS resolution the domain is effectively offline — no website, no mail, nothing. Every other check builds on this.

If the only nameserver fails, the whole domain stops resolving. Multiple nameservers — ideally in separate networks — are the simplest, most effective protection against outages (RFC 2182).

A delegated but dead nameserver slows down resolution for every visitor — resolvers must hit a timeout before trying the next server. If only one working server remains, redundancy is effectively gone.

A server that is delegated but not authoritative (e.g. because zone transfer fails or the zone was never set up there) returns errors or stale data depending on the resolver — a partial outage that is hard to diagnose.

Different serials mean the servers deliver different zone states — changes (new records, changed IPs) reach only part of your visitors. Most common cause: a stuck zone transfer to a secondary.

An authoritative nameserver that doubles as an open resolver can be abused for DNS amplification attacks against third parties and endangers its own availability. Authoritative servers should refuse recursion (RFC 5358).

An NS record pointing to a private address is unreachable from the internet and causes timeouts at every resolver. It may also leak internal network structure.

Nameservers in the same network share routers, location and usually the provider — a single failure then hits all of them at once, and nominal redundancy is void (RFC 2182 recommends topologically separate locations).

For IPv6-only clients to resolve a domain at all, the nameservers themselves must be reachable over IPv6 — ideally at least two, so redundancy survives a single outage.

When the lists differ, it is up to chance which servers a resolver uses — in the worst case queries land on servers that no longer (or don't yet) know the zone. Typical cause: a nameserver change applied only in the zone or only at the registrar.

Without correct glue you get a chicken-and-egg problem: the nameserver's address could only be resolved via the nameserver itself. Stale glue (e.g. after a server move) causes creeping, hard-to-find resolution failures.

A primary missing at the parent suggests an incompletely propagated configuration. Some systems (e.g. dynamic DNS updates) specifically target the MNAME — if it is not publicly delegated, such updates behave unreliably.

Too high a refresh delays propagation of zone changes to the secondaries; an extremely low one creates needless load. With NOTIFY the value matters less but still acts as a safety net.

Too high a retry leaves secondaries running on stale data far too long after a failure; too low a value hammers an already struggling primary.

Too short an expire makes secondaries drop the zone entirely during a longer primary outage — the domain goes offline despite redundancy. Too long a value keeps stale data alive for weeks in a failure case. 1–4 weeks is customary.

Too high a value makes “domain does not exist” answers stick in caches for hours — newly created records become visible late. An extremely low value noticeably increases query load.

Technically any 32-bit serial is valid — the date format is pure convention. But it shows at a glance when the zone last changed and makes debugging sync issues much easier. Many managed DNS providers (e.g. using Unix timestamps) deviate deliberately; that is not an error.

Basic reachability over HTTPS is required before the remaining web checks can run.

IPv6 reachability keeps the site available to IPv6-only clients as networks move away from IPv4.

IPv6 visitors should see the same site as IPv4 visitors. A large difference points to a misconfigured IPv6 server — for example an error page or a stale copy.

Redirecting HTTP to HTTPS ensures visitors who omit the scheme still reach the encrypted site.

HSTS forces the browser to switch straight to HTTPS on later visits, protecting against downgrade and SSL-stripping (machine-in-the-middle) attacks. A cache lifetime of at least one year (max-age=31536000) is considered sufficient. A long lifetime also protects infrequent visitors — but it means that if you ever need to turn HTTPS off again (generally a bad idea), you must wait until the policy has expired in every browser that previously visited.

Whether preloading is used, or the domain is on the HSTS preload list, is not evaluated here.

A Content-Security-Policy restricts which sources a page may load, mitigating cross-site scripting and injection.

X-Frame-Options prevents the page from being embedded in a frame, protecting against clickjacking.

nosniff stops browsers from guessing a response's content type, which can turn benign files into executable scripts.

A Referrer-Policy controls how much of the visited URL is shared with other sites, protecting user privacy.

HTTP compression (gzip/Brotli) noticeably speeds up loading and is standard. The theoretical BREACH attack only concerns secret- and input-reflecting responses and is mitigated by other means — compression itself is not a fault. (TLS compression / CRIME is checked separately.)

A security.txt file gives security researchers a clear, machine-readable way to report vulnerabilities to the right contact, which speeds up responsible disclosure.

HTTP/2 multiplexes several requests over one connection and noticeably speeds up loading, especially with many resources. It is widely supported today and should be enabled for public websites.

HTTP/3 runs over QUIC (UDP) instead of TCP and avoids its head-of-line blocking; this improves load time particularly on flaky mobile links. It is a worthwhile addition, but not (yet) a must.

Secure prevents transmission over unencrypted HTTP, HttpOnly protects against reading via JavaScript (XSS), and SameSite hinders cross-site request forgery. Without these flags, session cookies are easier to attack.

Sub-resources loaded over HTTP on an HTTPS page can be tampered with in transit and partly undermine the protection of the encrypted connection. Browsers now block active mixed content (scripts) but do not always warn visibly.

SRI stores a cryptographic hash of the expected file; the browser only loads the resource if it matches exactly. This protects against a compromised CDN or third-party host silently serving malicious code.

HTTPS encrypts traffic between visitors and the server and is the basis for every other TLS check.

TLS secures the connection between visitors and the server. Older versions have cryptographic weaknesses. The security level of each version:

Only TLS 1.2 and 1.3 should be offered.

Forward secrecy ensures recorded traffic cannot be decrypted later even if the server's private key is exposed.

A valid certificate proves the server's identity: it must chain to a trusted authority and match the requested host name.

The public key protects the key exchange. RSA keys should be at least 2048 bits and ECDSA at least 256 bits.

The signature algorithm secures the certificate against forgery. SHA-1 and MD5 are broken and must not be used.

OCSP stapling lets the server prove its certificate is not revoked without the visitor contacting the authority, improving speed and privacy.

DANE binds your certificate to DNSSEC, letting clients that support it detect a forged or mis-issued certificate a public authority might otherwise accept. A published but non-matching record is worse than none, because strict clients will refuse the connection.

When the server decides the preferred cipher suite, it can always enforce the strongest mutually supported one. Leaving the choice to the client would let a tampered or outdated client force a weaker suite.

An ephemeral key exchange (ECDHE or DHE) provides forward secrecy: even if the server's private key is later compromised, past connections stay protected. Static RSA key exchange does not.

Rating:

• Good: ECDHE with a modern curve (X25519, secp256r1/384r1), hash SHA-256/384
• Sufficient: DHE with ≥ 2048-bit parameters
• Insufficient: static RSA key exchange, DH parameters < 2048 bit, hash SHA-1/MD5

Active TLS compression enables the CRIME attack: the compressed message size leaks information about encrypted content (e.g. session cookies). TLS-level compression must therefore be off.

Without secure renegotiation (RFC 5746) a prefix-injection attack is possible, where an attacker prepends data before the real request. Additionally, client-initiated renegotiation should be disabled as it can be abused for DoS — TLS 1.3 removes renegotiation entirely, and modern TLS 1.2 servers supporting RFC 5746 refuse client renegotiation by default.

Extended Master Secret binds the master secret to the entire handshake, preventing triple-handshake attacks that chain TLS sessions across connections. It should be active for TLS 1.2.

0-RTT speeds up returning connections by letting the client send data before the handshake completes. The catch: this early data can be replayed by an attacker. Without server-side anti-replay protection — which can't be reliably verified from outside — that is a risk, especially for state-changing requests.

RPKI (Resource Public Key Infrastructure) lets network operators cryptographically authorise which ASN may announce an IP prefix. A valid entry protects against route hijacking and BGP misconfiguration.

Rating:

• Valid: a ROA covers the route and the announcing ASN matches
• No ROA: no RPKI authorisation published yet — recommended, but not an acute fault
• Invalid: a ROA exists but the announcement violates it (possible misconfiguration or hijack)

RPKI (Resource Public Key Infrastructure) lets network operators cryptographically authorise which ASN may announce an IP prefix. A valid entry protects against route hijacking and BGP misconfiguration.

Rating:

• Valid: a ROA covers the route and the announcing ASN matches
• No ROA: no RPKI authorisation published yet — recommended, but not an acute fault
• Invalid: a ROA exists but the announcement violates it (possible misconfiguration or hijack)

MX records are the entry point of the mail configuration. Without them the domain does not receive e-mail, and the mail-transport checks below do not apply.

SPF lists which servers may send mail for your domain. A strict policy (-all) tells receivers to reject mail from any other source, which reduces spoofing. A soft-fail (~all) only marks such mail; a missing or permissive policy offers little protection.

DKIM adds a cryptographic signature to outgoing mail so receivers can verify it was authorised by your domain and not altered in transit. Custom selectors cannot be discovered from DNS, so a negative result here does not always mean DKIM is absent.

DMARC ties SPF and DKIM together and tells receivers what to do with mail that fails both — and where to send reports. An enforcing policy (quarantine or reject) actively blocks spoofed mail; p=none only observes.

Sending servers on IPv6-only networks can only deliver mail if your mail servers are reachable over IPv6.

STARTTLS encrypts mail in transit between servers. Without it, messages travel in clear text and can be read or altered along the way. A valid, name-matching certificate is needed for the encryption to be trustworthy.

As with the web server, only TLS 1.2 and 1.3 are considered secure for mail transport; older versions have known weaknesses.

DANE binds your mail servers' certificates to DNSSEC, so a sending server can detect a forged or downgraded certificate that a public authority might otherwise accept. A published but non-matching TLSA record is worse than none, because strict senders will refuse delivery.

BIMI (Brand Indicators for Message Identification) lets supporting mail clients display your brand logo next to authenticated e-mail. It is not a security mechanism but a brand-display extra — yet it requires clean mail authentication (SPF, DKIM, strict DMARC policy), making it a visible bonus of a correct setup.

MTA-STS forces sending mail servers to reach your MX only over an encrypted, certificate-verified connection. This closes a gap in opportunistic STARTTLS, which can be defeated by a downgrade attack. The “enforce” mode provides full protection.

TLS-RPT lets other mail servers send you daily reports about failed TLS connections to your MX. This surfaces certificate or STARTTLS problems before mail is silently delivered unencrypted or stops being delivered — ideal together with MTA-STS.

Receiving mail servers often check whether a sending server's IP has a PTR record (ideally matching the HELO/MX name). Without it, your mail is more likely to be spam-filtered or rejected outright.

An open relay accepts mail from arbitrary senders to arbitrary recipients and is promptly abused for spam and phishing. This severely damages the server IP's reputation and quickly leads to blacklist entries.

Forward secrecy (ECDHE/DHE) ensures that a later compromise of the server key cannot retroactively decrypt earlier, captured mail connections.

A valid, matching certificate is the prerequisite for sending servers to actually verify the TLS connection (especially relevant with MTA-STS/DANE). Opportunistic STARTTLS without enforcement often accepts an invalid certificate, but that undermines the protection.

Keys that are too short (RSA < 2048 bit, ECDSA < 256 bit) are considered insecure and can be attacked with reasonable effort.

Signatures using SHA-1 or MD5 are considered broken and theoretically allow forged certificates. Modern certificates use SHA-256 or stronger.

Active TLS compression enables CRIME-style attacks and must be disabled. TLS 1.3 has no record compression.

Without secure renegotiation, a prefix-injection attack against the TLS connection is possible. TLS 1.3 removes renegotiation entirely.

Extended Master Secret binds the master secret to the entire handshake and prevents triple-handshake attacks. It should be active for TLS 1.2; TLS 1.3 supersedes it with its key schedule.

RPKI (Resource Public Key Infrastructure) lets network operators cryptographically authorise which ASN may announce an IP prefix. A valid entry protects against route hijacking and BGP misconfiguration.

Rating:

• Valid: a ROA covers the route and the announcing ASN matches
• No ROA: no RPKI authorisation published yet — recommended, but not an acute fault
• Invalid: a ROA exists but the announcement violates it (possible misconfiguration or hijack)