Deeper TLS snapshots, robots.txt, and more passive DNS signals in every scan

Why we extended the same public scan

Teams still want one URL in and one prioritized list out, but they also asked for a bit more transport and discovery context without turning Scorifya into a penetration test or a full TLS lab. The new checks stay inside that contract: outbound-only, rate-limited, and documented so you can quote what fired and what did not.

Category weights and caps are unchanged; one new TLS finding can apply a small penalty when a legacy-heavy client profile still negotiates a weak cipher even though the default browser path looked fine. Exact numbers stay on the methodology page next to the other finding ids.

TLS: multiple views, still bounded

After the main HTTPS probe and the existing TLS 1.0/1.1 acceptance checks, we now record separate TLS 1.2-only and TLS 1.3-only handshake snapshots when the server allows them. A short set of additional handshakes proposes narrow legacy cipher lists to see whether the edge would still pick a weak suite for that kind of client.

Results are intentionally limited: a handful of connections with timeouts, not an exhaustive matrix of every suite and client. The goal is explainable signal for hardening programs, not a replacement for deep configuration review.

robots.txt and richer security.txt

On the same HTTPS origin we already used for headers and security.txt, we now fetch `/robots.txt` as a crawler-policy hygiene signal: missing or non-200 responses, empty files, blanket Disallow: / for User-agent: *, or a declared Sitemap line. These are informational findings, not claims about access control.

When security.txt includes a Contact field, we also surface optional RFC 9116 fields in technical output—Expires, Canonical, Encryption, Preferred-Languages—and informational notes if Expires is absent or Canonical does not match the scanned origin. Missing Contact or an empty file still map to the same scored incomplete findings as before.

DNS: CAA, mail hardening TXT, BIMI

We resolve CAA at the scan hostname and at the parent label when one exists, and record issue and issuewild tags in technical output. If no CAA is observed, you will see an informational finding; a wildcard issuewild still allowed gets its own note.

When the hostname has MX records, we look for MTA-STS (TXT at _mta-sts) and TLS-RPT (TXT at _smtp._tls) and flag absent records as informational context for inbound mail transport, not as a verdict on deliverability.

For BIMI we check default._bimi on the apex label (parent domain when the scan target is a subdomain, otherwise the host itself) and record whether a v=BIMI1 record appeared. That remains informational; inbox logo display still depends on providers and DMARC enforcement.

For background on the older SPF/DMARC/DKIM slice of the model, the DMARC and SPF blog post is still the right deep dive on what passive email DNS can and cannot prove.

Exports, API shape, and what did not change

Successful scans still return the same JSON shape: score, categories, findings with guidance, and a technical map that now includes the extra keys above. Pro exports pick those fields up automatically; the public scanner behavior and SSRF controls are the same idea as before, with more rows in technical when the probes succeed.

If you need the formal boundary list—no exploitation, no authenticated crawl, no compliance sign-off—start from the FAQ and treat anything new the same way: observable configuration, plain-language impact, copy-ready fixes where we already had patterns.