SPF
What we look for: a TXT record that lists who can send email for your domain.
Bad condition: no SPF, or +all, which allows anyone.
Good condition: a narrow SPF record using only real mail providers with ~all or -all.
Security is built to teach website owners what public security signals say about their domain. This guide explains every major area we check, what bad conditions mean, and what a healthy website should show.
DNS tells the internet where your website and email live. Bad DNS or missing email records can make your brand easier to spoof and can hurt email deliverability.
What we look for: a TXT record that lists who can send email for your domain.
Bad condition: no SPF, or +all, which allows anyone.
Good condition: a narrow SPF record using only real mail providers with ~all or -all.
What we look for: a policy at _dmarc.yourdomain.com.
Bad condition: no DMARC, or monitoring forever with no plan.
Good condition: reports enabled, then a move toward p=quarantine or p=reject.
What we look for: certificate authority authorization records.
Bad condition: any certificate authority can issue certificates unless restricted.
Good condition: CAA records limited to the certificate authorities you actually use.
What we look for: multiple authoritative nameservers.
Bad condition: one nameserver or broken delegation.
Good condition: two or more reliable nameservers with public records resolving correctly.
HTTPS protects visitors by encrypting traffic and proving the site is really the domain they intended to visit.
Bad condition: expired, expiring soon, untrusted, or unreachable certificate.
Good condition: valid certificate with enough renewal runway and a trusted chain.
Bad condition: weak or old certificate key.
Good condition: RSA 2048+ or modern ECDSA keys.
Bad condition: certificate does not cover the names users visit.
Good condition: Subject Alternative Names include the relevant domain names.
Bad condition: visitors can land on insecure HTTP.
Good condition: all HTTP traffic redirects cleanly to HTTPS.
Security headers tell browsers how to safely handle your site. They are small configuration choices that can block whole classes of attacks.
Forces browsers to use HTTPS in the future. Good when every subdomain supports HTTPS reliably.
Limits which scripts, frames, images, and connections the browser should trust. Helps reduce XSS impact.
Prevents browsers from guessing file types. Good value: nosniff.
Controls how much URL/referrer data leaks to other sites. A common good value is strict-origin-when-cross-origin.
Disables browser features your site does not need, like camera, microphone, geolocation, payment, or USB.
Uses X-Frame-Options or CSP frame-ancestors so attackers cannot invisibly frame your site.
Public trust signals help visitors and security researchers understand how to contact the right people without exposing unnecessary personal details.
What we look for: /.well-known/security.txt or /security.txt with a Contact field.
Good condition: a standard security contact and expiration date.
What we look for: public same-domain emails on the homepage.
Good condition: use role-based addresses and spam protection when possible.
The score is a public posture baseline. It weighs DNS/email protection, TLS, browser headers, and trust signals. The report turns the raw findings into a plain-English explanation, priority plan, concrete provider request, and retest checklist.
Security checks public signals only. It does not log into your website, scan source code, test payment flows, verify server patch levels, detect malware, or replace a full penetration test. It is a fast education and readiness tool, not a complete security audit.