What this MX check tests
Unlike pure DNS tools, this check opens a real SMTP connection to the two highest-priority MX hosts and looks at what the server actually offers:
- MX records — every entry with its priority. The lowest value is tried first; the rest are failover.
- IP addresses per host — A and AAAA records of the MX hosts.
- Reverse DNS and FCrDNS — does each IP have a PTR record, and does that hostname resolve forward to the same IP again? Only then is it confirmed reverse DNS, and that is precisely what many receivers test.
- STARTTLS — does the server offer transport encryption at all? Without STARTTLS, delivery happens in the clear.
- TLS certificate — issuer, validity window, days remaining, subject alternative names, whether the hostname matches, whether the chain verifies against the system CAs, key type and strength, and the negotiated TLS version.
- DANE/TLSA — does the domain publish TLSA records at
_25._tcp.{mx-host}to pin the certificate via DNSSEC?
What matters in practice
Missing or unconfirmed reverse DNS is one of the most common reasons a self-hosted mail server gets refused — before the content is even considered. The PTR record is set by whoever operates the IP, meaning your hosting provider, not in your own domain zone.
As for the certificate: for server-to-server delivery an invalid certificate is usually not a hard blocker, because many servers encrypt opportunistically and deliver anyway. The moment MTA-STS runs in enforce mode or DANE is involved, however, that cosmetic flaw becomes a delivery failure.
What this check cannot see
This tests the receiving side of your domain — the servers that accept mail for you. It only says something about your outbound sending if the same machines handle both.
How your mail arrives at the recipient — which TLS version it lands with, which path it takes, whether SPF and DKIM pass — is what the full analysis shows: an email to hello@analyzemy.email is all it takes.