Expert Tools
Expert Tools
In-depth checks for anyone who wants to know exactly how their DNS and mail security is configured. Pick a protocol below to see what it does, why it matters, and to run the check itself. New to SPF, DKIM and the rest? Start here for a short, plain-language overview before diving in.
Every check here reflects what we could observe from our own server, at the moment you ran it. It is not a permanent guarantee, and not a substitute for a full resolver-grade validator where one genuinely matters (mail servers, DNSSEC-validating resolvers, and so on). Where a check has a specific, known limit, the explanation on that page says so directly rather than leaving it implied.
Start here
Mail infrastructure
Mail Health
SPF, DKIM, DMARC and MX read together rather than one at a time, with a blocklist check on the addresses your SPF record names as senders. It reports what those records say about each other, which is the part no single check can see from where it stands.
Check Mail HealthMX
MX records say where mail addressed to a domain actually goes, and in what order. Checks presence, well-formedness (no CNAME or bare IP as a target), whether each target resolves, over which address families, and whether it has reverse DNS.
Check MXMail - (almost) mandatory
SPF
Sender Policy Framework lists which mail servers are allowed to send e-mail for your domain, so receiving servers can spot messages that only claim to be from you.
Check SPFDKIM
DomainKeys Identified Mail cryptographically signs outgoing e-mail, so receiving servers can verify a message wasn't altered in transit and genuinely came from a server your domain has authorised.
Check DKIMDMARC
DMARC builds on SPF and DKIM: it tells receiving servers what to do with mail that fails both, and gives you reports on what's actually happening. It is the piece that turns SPF and DKIM from passive checks into an enforced policy.
Check DMARCMail - nice to have
MTA-STS
MTA-STS publishes a policy over HTTPS that forces incoming mail servers to require verified TLS, closing the gap where STARTTLS can be silently stripped by an attacker on the network path.
Check MTA-STSTLS-RPT
TLS-RPT is the reporting companion to MTA-STS and DANE: it doesn't enforce anything by itself, but turns a silent delivery failure into an actual, readable report about what went wrong and why.
Check TLS-RPTBIMI
BIMI displays a verified logo next to a message once DMARC enforcement is in place. Purely cosmetic, but it rides entirely on the authentication the other protocols provide.
Check BIMIDNS
DANE
DANE publishes a fingerprint of a website or mail server's certificate in DNS, so a connecting client can refuse a certificate that doesn't match, even one issued by an otherwise-trusted CA. Requires DNSSEC to mean anything.
Check DANECAA
CAA names which certificate authorities are allowed to issue a certificate for a domain, restricting mis-issuance in advance rather than only discovering it afterwards.
Check CAADNSSEC
DNSSEC adds digital signatures to DNS responses, so a resolver can verify what it received genuinely came from the zone owner. Verifies the full chain of trust, from this domain up to the root zone's own IANA-published trust anchor, the same validation a resolver performs before trusting a signed answer at all.
Check DNSSECOverall security
Headers
HTTP response headers can tell a visitor's browser to actively defend itself: refuse plain HTTP, restrict where scripts load from, block clickjacking. Explained in plain language here, not scored.
Check HeadersTLS
Checks the certificate chain as actually served, actively probes which TLS versions are accepted (including whether deprecated 1.0/1.1 are still active), whether plain HTTP redirects to HTTPS, and HSTS presence.
Check TLS