Mail Server (MX) Health Check
Enter a domain and SysGlass resolves its MX records, then connects to each mail exchanger to check the things a receiving server actually judges before it accepts your email. For every MX host it verifies forward-confirmed reverse DNS (the PTR resolves back to a name whose A/AAAA points to the same IP), opens an SMTP session to read the greeting banner, and upgrades with STARTTLS to inspect the certificate's validity, hostname match and negotiated TLS version. It's the inbound counterpart to the SPF/DKIM/DMARC checks: those prove who may send as your domain, while this proves the hosts that receive (and often relay) your mail are reachable, identified, and encrypted — and it works just as well when your MX is Microsoft 365 or Google Workspace.
Reviewed by the SysGlass team · Updated July 21, 2026
What it checks
- Resolves every MX record for the domain, in preference order, and tests each mail exchanger (not just the primary)
- Forward-confirmed reverse DNS (FCrDNS): the MX IP has a PTR record, and that PTR hostname resolves forward (A/AAAA) back to the same IP
- Whether the PTR/HELO identity looks like a real mail host rather than a generic ISP/dynamic-pool name
- The SMTP greeting banner each MX returns on connect (the 220 line and the HELO/EHLO name it announces)
- STARTTLS support on port 25 and the TLS version actually negotiated (TLS 1.2 / 1.3, and a warning on deprecated 1.0 / 1.1)
- The MX certificate: validity dates / days left, whether it's expired, and whether it covers the MX hostname
- A per-host pass / warn / fail verdict plus the equivalent commands (dig MX, openssl s_client -starttls smtp) to reproduce the check
How to read the result
- Pass: every MX resolves, has matching FCrDNS, answers with a banner, and offers STARTTLS with a valid, in-date certificate and a modern TLS version.
- Warn — no/!mismatched PTR (FCrDNS fails): the MX IP has no reverse DNS, or its PTR doesn't forward-confirm. Many receivers distrust or greylist mail from a host whose IP can't be tied to a name, so fix the PTR with your IP provider (for self-hosted MX) so it matches the host's forward record.
- Warn — STARTTLS missing or deprecated TLS: the MX accepts mail in plaintext or only negotiates TLS 1.0/1.1. Enable STARTTLS and require TLS 1.2+ so inbound mail can be encrypted.
- Fail — expired or wrong-host certificate: the MX presents an expired cert, or one that doesn't cover the MX hostname; senders enforcing strict TLS (MTA-STS enforce / DANE) will refuse to deliver. Renew or reissue the certificate for the MX name.
- Fail — MX unreachable or no banner: the host didn't accept the SMTP connection on port 25 or never returned a greeting — it may be down, firewalled, or misconfigured, and mail to it will bounce or defer.
- Each MX host is graded independently — a single bad backup MX is a real weakness, because a sender (or an attacker steering delivery) can use the weakest exchanger you publish.
Frequently asked questions
What is FCrDNS and why does it matter for a mail server?
Forward-confirmed reverse DNS means an IP's PTR (reverse DNS) record points to a hostname, and that hostname's forward A/AAAA record points back to the same IP — the two directions agree. Receiving mail servers use it as a basic trust signal: a sending or receiving MX whose IP can't be matched to a real name looks like a hijacked or dynamic host, so mail is more likely to be greylisted, scored as spam, or rejected. This check confirms each MX passes FCrDNS so your mail hosts aren't penalised for a missing or mismatched PTR.
Does this work for Microsoft 365 or Google Workspace?
Yes. The tool tests whatever MX hosts the domain publishes, so for a Microsoft 365 domain it inspects the *.mail.protection.outlook.com exchangers and for Google Workspace the *.google.com / *.googlemail.com ones. Those providers normally pass FCrDNS, STARTTLS and certificate checks cleanly — running it confirms your MX records actually point at the provider correctly and that nothing in between (a relay, a security gateway) is breaking TLS or reverse DNS.
How is this different from the SMTP Server Test or the email-auth checker?
The email-auth, SPF, DKIM and DMARC tools check who is allowed to send as your domain (outbound authentication). This Mail Server (MX) Health check looks at the receiving side — the actual MX hosts other servers connect to — across all of them at once, focusing on FCrDNS, STARTTLS/TLS and certificate validity per host. The SMTP Server Test drills into one server in depth (capabilities, open-relay probe); this gives you the health of the whole MX set in a single pass.
Why does a missing PTR or reverse DNS hurt deliverability?
Reverse DNS is one of the cheapest anti-abuse signals receivers have. Legitimate mail infrastructure almost always has a PTR that forward-confirms; spam sources and compromised hosts frequently don't. So a mail server with no PTR, or a PTR that doesn't match its forward hostname, is widely treated as suspicious — increasing the chance of greylisting, spam-foldering, or outright 5xx rejection. If you run your own MX, ask whoever owns the IP block (your host or ISP) to set the PTR to a name that resolves back to that IP.
Does it check STARTTLS and the certificate on the MX?
Yes. For each MX it issues EHLO, looks for the STARTTLS capability, performs the TLS upgrade, and records the negotiated TLS version and the certificate it presents — including the validity dates, days remaining, whether it's expired, and whether it covers the MX hostname. Plaintext-only delivery or a deprecated TLS version is flagged as a warning, and an expired or wrong-host certificate is a failure because senders enforcing MTA-STS or DANE will refuse to deliver to it.
Is it free, and does it send any email?
It's a free public tool at sysglass.com/tools/mail-server-health with no sign-up. It performs read-only DNS lookups plus an SMTP handshake (connect, EHLO, STARTTLS) to each MX — it never issues DATA and never sends a message. You can reproduce it with dig MX <domain> and openssl s_client -starttls smtp -connect <mx>:25.