The general idea

Each of the three categories - TLS & Certificate, Security Headers, Email - starts at a score of 100 and findings deduct points. A handful of findings additionally ceiling the score outright, regardless of how few points were actually deducted: an expired certificate ceilings at 39 (an F), a self-signed certificate at 69 (a C), TLS 1.0/1.1 still being accepted at 79 (a B). A great cipher suite does not excuse a certificate no browser would trust - the weakest link decides, the same principle every reputable scanner uses. The letter grade is derived directly from the final score, so the two can never disagree.

Findings are also tagged danger or warning depending on how serious they are, shown as red or amber in the report - a rough guide to what to fix first, separate from the numeric deduction.

The overall score is a weighted average of the three category scores (TLS weighted heaviest, then headers, then email), skipping any category that doesn't apply or wasn't selected to run - a domain with no email hosted isn't penalized for not having SPF/DMARC, and unchecking a category on the form simply excludes it rather than scoring it zero.

TLS & Certificate

• An expired certificate, or one that doesn't cover the scanned hostname, ceilings the score at 39 (F).
• A self-signed certificate, or a chain not trusted by common trust stores, ceilings at 69 (C).
• The server still accepting TLS 1.0 or TLS 1.1 ceilings at 79 (B).
• No support for TLS 1.2 or TLS 1.3 at all ceilings at 39 (F).
• Every cipher suite in our catalogue is probed individually - a real TLS 1.2 handshake pinned to exactly that one suite, the same technique openssl s_client -cipher uses - and classified secure, weak or forward-secrecy-less/broken. Any accepted insecure suite (RC4, 3DES, NULL) ceilings the score at 54 (D); any accepted weak suite only deducts.
• Further deductions: a certificate expiring within 14 days, an RSA key under 2048 bits, no TLS 1.3 support, a negotiated cipher without forward secrecy, and a missing or short-lived HSTS header.

Known limitation:we don't score the certificate's signature algorithm (e.g. flagging a legacy SHA-1 signature) - Node.js, which this scanner runs on, doesn't expose that field without a manual ASN.1 parse, and it's vanishingly rare on certificates issued in the last decade.

Security Headers

Deductions for a missing Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options: nosniff, clickjacking protection (X-Frame-Options or a CSP frame-ancestors directive), Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy - plus a smaller deduction for a Server or X-Powered-By header that discloses software/version detail, and for any cookie missing the Secure or HttpOnly flag.

Email

• Only port 25 is probed on each MX host - that's the port a sending mail server actually uses to deliver to the domain, which is what "is inbound mail protected" needs.
• At least one reachable mail server not supporting STARTTLS caps the grade at C.
• No SPF record, or no DMARC record, each cap the grade at B and deduct points; a DMARC policy of "none" (monitoring only, not enforced) deducts further.
• Port 25 being unreachable from our scanner is reported plainly rather than scored as a failure of the target - cloud providers commonly block outbound port 25 by default, including ours, so an unreachable result is often about us, not you.

Publishing and privacy

A report is published at a stable, public URL by default - unchecking "publish this result publicly" on the form instead gives it a private, unlisted link only you can share, never listed or indexed.

A domain owner can opt out entirely by publishing a _aethercert-scan-optout TXT record on their domain. This is a stronger refusal than the checkbox above: an opted-out domain is never scanned at all- we don't connect to it, and nothing about it is stored, not even privately. Anyone who tries is told the domain has opted out and nothing more.