Twenty one checks on the domain your mail leaves from
Authentication, transport encryption, DNS, reputation and the web side of the same name. Every one of them runs on every plan, the mail and DNS ones every ten minutes, and each tells you which record to change rather than only that something is wrong.
Authentication that actually holds
SPF, DKIM, DMARC, ARC and BIMI, read the way a receiving server reads them. When a vendor edits an include or a selector disappears, you learn which record moved and when, instead of learning it from a bounce.
- DKIM key length measured per selector
- DMARC policy read as RFC 9989 defines it
- ARC across forwarders
- Every record compared with its last value
Mail that stays encrypted on the way
MTA-STS policy, TLS-RPT, DANE and STARTTLS on every host in your MX. You see an expiring certificate or a downgraded session while there is still time to act, not after somebody reports missing mail.
- MTA-STS policy fetched over HTTPS
- Policy id compared with the TXT record
- DANE matched to the live certificate
- STARTTLS and the certificate on every MX host
The DNS underneath, and the web side of the same name
MX and the path behind it, DNSSEC validated and not merely present, CAA, reverse DNS with forward confirmation, and whether a stranger can download your zone. Plus the web checks on the same domain, because the people judging you do not separate the two.
- DNSSEC, including orphan DS records
- MX, CAA and reverse DNS confirmed forward
- Open zone transfer probed on every name server
- security.txt, headers, redirect, robots, sitemap, cookies
Reports turned into answers
DMARC aggregate and forensic, SMTP TLS reporting and CAA violation reports arrive as XML nobody wants to open. You get sources, volumes and pass rates, and a year of history to compare against.
- DMARC aggregate and forensic
- SMTP TLS reporting
- CAA violation reports
- A year of history to compare against
Point it at a domain and read the answer
One domain, no card, and the first results inside ten minutes.
An SPF record that does not run out of lookups
Include chains are expanded and counted against the ten lookup limit in RFC 7208. You see which vendor spends your budget, and where a loose all inside somebody else record quietly widens your authorization.
- Every include and redirect followed
- Lookups counted the way RFC 7208 counts them
- A loose all found inside a vendor include
- A flattened record when the chain resolves cleanly
Reputation, before it costs you delivery
Your sending IPs and your domain are checked once a day against the 120 blocklists we track, with a direct link to each delisting form. A listing usually shows up as a drop in delivery long before anyone thinks to look for it.
- 120 blocklists, checked once a day
- MX hosts resolved to their addresses
- A direct link to each removal form
- Refused queries told apart from listings
See the checks running on your own domain
Everything above describes what we look at. A free account puts it to work on one domain of yours, so you can watch the results arrive instead of reading about them. Add more domains when you need them.
Questions about the checks
How often things run, what happens when something breaks, and what you need to change in DNS.
The DNS step sets the pace, not us. You create the account, enter the domain, publish one TXT record to prove you own it, and confirm. We read that record through public resolvers, so confirmation works as soon as your change has propagated, which is usually minutes and can be longer on a slow provider. After that the full check set runs by itself every ten minutes.
Your MX records are the one thing we never ask you to touch. We sit outside the mail path and there is nothing to install. Two records do come into it, both TXT and neither an MX. One proves the domain is yours, which is step two of adding it. The other is optional and only if you want report analysis, where you point the rua address in your existing DMARC record at the mailbox we mint for you.
By email, which is the only channel. A check has to fail twice in a row before we write, so a single timeout stays a timeout, and there is a 30 minute pause before we write about the same check again. In practice that puts a real problem in your inbox 10 to 20 minutes after it started. Blocklist listings go into a daily report instead.
FCrDNS checks that forward and reverse DNS match. Providers like Gmail and Microsoft use it to verify senders, and if it fails, mail often lands in spam.
Yes. Manage one domain or hundreds from a single unified dashboard.
See it against a domain you actually own
Reading about checks tells you little. Running them against your own domain tells you whether your authentication holds today, and that takes about ten minutes.