Mail server present #
Without MX records, the domain receives no email; the mail server tests are then skipped.
RatingInformational (weight 0).
How to fix itIf mail reception is desired, set MX records.
Sources: RFC 5321 (SMTP) ↗
✉️ Mail server TLS & DANE checks explained
What the mail module tests against your MX hosts over port 25: STARTTLS, negotiated TLS and ciphers, certificates, FCrDNS and DANE/TLSA – with scoring and fixes.
Check your domain →
Need a DANE record? The free TLSA/DANE generator can fetch your live certificate and build the recommended 3 1 1 record for you.
Last updated: July 2026 · 9 checks documented
Null MX (mail explicitly declined) #
A Null MX record (MX 0 ., RFC 7505) declares that a domain does not accept mail at all. Senders get an immediate, clean bounce instead of long timeouts, and the domain is harder to abuse as a spoofed sender (together with SPF -all and DMARC p=reject).
Ratingpass – a deliberate "no mail" declaration is a correct, secure configuration. STARTTLS/DANE probes are skipped for the Null MX pseudo-entry.
How to fix itNo action needed. If the domain SHOULD receive mail, replace the Null MX with real MX records pointing to your mail servers.
Sources: RFC 7505 (Null MX) ↗
STARTTLS on the MX #
STARTTLS encrypts the SMTP connection between mail servers. An MX that accepts only cleartext transmits mail unprotected.
RatingEach MX is probed over every published address family (IPv4 and IPv6) – one connection per family. pass if every reachable connection offers STARTTLS; warn if a published address family is unreachable while the other works; otherwise fail + Cap C. Weight 3. (skip if port 25 is unreachable.)
How to fix itEnable STARTTLS on all MX hosts.
Sources: RFC 3207 (STARTTLS) ↗
Mail server TLS version & cipher strength #
For mail transport, too, only modern TLS versions (1.2/1.3) and strong ciphers should be used. Besides the best-case handshake (run separately over IPv4 and IPv6 where published), two downgrade probes per MX check whether obsolete TLS ≤ 1.1 or a weak cipher (RC4, 3DES, DES, export, NULL) is still on offer – an attacker could otherwise force a downgrade. The downgrade probes run on each host’s primary connection (the TLS configuration is per server, not per address family).
Ratingpass with TLS 1.2+ and no obsolete fallback; warn if TLS ≤ 1.1 is offered; fail + Cap C if a weak cipher is accepted. Weight 2.
How to fix itEnforce TLS 1.2/1.3 on the MX hosts, disable 1.0/1.1, and remove RC4/3DES/DES/export/NULL cipher suites.
Sources: RFC 8996 (TLS 1.0/1.1 deprecated) ↗
Cipher suites per TLS version #
Lists the cipher suites the mail server actually accepts, grouped by TLS version (TLS 1.3 / 1.2 / 1.1 / 1.0) – the same view a sending MTA negotiates against. To keep the outbound port-25 footprint small (blacklist protection), only one representative MX is enumerated: the reachable host with the lowest preference. The other reachable MX are compared by certificate fingerprint and negotiated suite – if identical, the list applies to them too; if they differ, that is stated instead of enumerated.
Ratingpass when suites were enumerated and none is weak; warn if a weak suite is offered (the strength cap itself lives on the TLS version & cipher strength check). Weight 1, informational. (skip if nothing could be enumerated.)
How to fix itPrefer AEAD suites (AES-GCM, ChaCha20-Poly1305) with ECDHE key exchange; disable CBC-only and static-RSA (no forward secrecy) suites where compatibility allows.
Sources: SSL Labs Rating Guide ↗ · RFC 8446 (TLS 1.3) ↗
Mail server certificates #
For MTA-STS enforce and PKIX-anchored DANE-TA, the MX certificates must be valid, match the hostname, and chain to a publicly trusted CA. (With pure opportunistic STARTTLS, an untrusted/self-signed chain is tolerable; a verified DANE-EE match pins the certificate via TLSA, so PKIX checks then do not apply – RFC 7672 §3.1.1.)
Ratingwarn with an expired/non-matching certificate or an untrusted chain (unless DANE-EE pinned); otherwise pass. Weight 1.
How to fix itServe valid certificates that match the MX hostname and chain to a trusted CA (or set up DANE-EE) if you rely on MTA-STS/DANE.
Sources: RFC 7672 (SMTP DANE) ↗
Reverse DNS of the mail servers (FCrDNS) #
Forward-confirmed reverse DNS means each MX IP has a PTR record whose hostname resolves back to that same IP. Receiving mail servers widely require this as an anti-spam signal; without it, mail from these hosts is more likely to be rejected or greylisted.
Ratingpass if every checked MX address is forward-confirmed; warn if any lacks a PTR or fails to forward-confirm. Checked are the IPv4 and IPv6 addresses of each probed MX host (up to 4 per family; the drill-down notes when only a sample of even more published addresses was checked). Weight 1. (Pure DNS – runs even when port 25 is blocked.)
How to fix itSet up a matching PTR record for each MX IP (via your hosting/ISP) whose hostname resolves back to the same IP.
Sources: RFC 1912 §2.1 (DNS errors) ↗
DANE / TLSA #
DANE binds the mail server certificate to a TLSA record via DNSSEC, protecting against TLS downgrade/MITM. DANE is only secure if the TLSA response is DNSSEC-authenticated.
Ratingpass if the certificate matches the (DNSSEC-secured) TLSA; fail on mismatch; TLSA without DNSSEC → fail + Cap C; missing → warn. Weight 2.
How to fix itEnable DNSSEC and publish TLSA records under
_25._tcp.<mx> (recommended: usage 3, selector 1, matching 1).Sources: RFC 7672 (SMTP DANE) ↗ · dane.sys4.de ↗
DANE configuration #
The certificate usage field encodes two independent choices. PKIX (0/1) still requires the certificate to validate against a public CA – the TLSA record only adds a pin on top; DANE (2/3) replaces the public CA and uses the DNSSEC-signed record itself as the trust anchor, so a private or self-signed certificate works. TA (0/2) pins the issuing CA and lets leaf certificates rotate freely; EE (1/3) pins the certificate itself. For DANE-TA, pin an intermediate rather than the root: the server must include the pinned trust-anchor certificate in its TLS handshake (RFC 7671 §5.2), and roots are normally not sent, so a DANE-TA record pointing at a not-sent root will not validate. To pin the root, use PKIX-TA (0), which validates against the client's own trust store (the exception is a 2 0 0 record that carries the full root in DNS). For SMTP DANE, usage 3 (DANE-EE) or 2 (DANE-TA), selector 1 (SPKI, survives certificate changes), and matching 1 (SHA-256) are recommended – RFC 7672 §3.1.3 says PKIX usages (0/1) SHOULD NOT be published for the port-25 SMTP service, and clients may treat them as unusable. DANE also only protects delivery when every MX host is covered: senders fall back to unauthenticated TLS for MX without TLSA (RFC 7672 §2.2.1). For the key rollover, two TLSA records should exist temporarily.
Ratingwarn with PKIX usage (0/1) or when some MX hosts lack TLSA records (weight 1 in the latter case); info if only one TLSA record is present. Weight 0–1.
How to fix itUse usage 3, selector 1, matching 1 on every MX; during a rollover, temporarily publish two TLSA records.