Email deliverability.
Everything a receiving mail server looks at before deciding whether your message is real: who is allowed to send for the domain, whether messages are signed, what to do when they are not, and whether the mail servers themselves speak TLS. Each finding is explained, not just flagged.
About this tool
Every check is a live DNS query from this server (via Cloudflare's resolver) plus a short connection to each mail server on port 25 to see whether it offers STARTTLS and what certificate it presents. Nothing is sent and no mail is involved; the SMTP session stops after EHLO and STARTTLS.
SPF says which servers may send mail for the domain. The record is parsed into a tree so you can see what each include pulls in, and the DNS-querying mechanisms are counted against the limit of ten that receivers enforce. Over ten and the whole record is ignored, which is the most common reason SPF "stops working" after adding a new SaaS provider. DKIM signs each message with a private key whose public half is published under a selector; the selector name is chosen by the sender, so this tool probes the ones common providers use and cannot see custom ones. DMARC ties the two together: it tells receivers what to do when a message fails both and where to send reports. Without it, SPF and DKIM are advisory.
MTA-STS and TLS-RPT harden the connection itself: STARTTLS on its own can be stripped by anyone in the path, and MTA-STS lets you tell big senders to refuse unencrypted delivery. BIMI is the logo shown next to your messages in supporting clients, and only works with an enforcing DMARC policy.
Useful for: working out why mail lands in spam, checking a new provider's records before switching, confirming the last step to p=reject is safe, and auditing a domain you are about to send on behalf of. Only public domains can be checked and nothing is stored.
From a terminal: curl "kirkdiamond.com/tools/mail?domain=example.com" or add &format=json.