Email security is assessed for the domain submitted to the scan. SSLBoard inspects its mail routing and the returned mail-endpoint observations; it does not repeat the domain-policy assessment for every discovered web subdomain.
Mail routing results
| Result | Interpretation |
|---|---|
| Mail service found through MX records | DNS identifies receiving mail hosts. |
| Implicit MX delivery | Delivery uses the domain’s address fallback rather than an explicit MX list. |
| Domain explicitly does not receive mail | A null MX policy declares no receiving mail service. |
| No resolvable receiving mail service found | A usable receiving destination could not be established. |
| Mail routing needs review | The MX configuration was reported as invalid. |
| Status could not be confirmed | Evidence was insufficient to classify routing. |
Finding a route is not proof of successful message delivery. A domain that intentionally receives no mail should not be treated as a broken mail server solely for that reason.
Delivery and submission are different
The endpoint details distinguish delivery service on port 25 from submission services on ports 465 and 587. STARTTLS upgrades an existing protocol connection; implicit TLS starts with encryption. A submission port that is not listening is not evidence that inbound delivery on port 25 is broken.
Listener states include listening, not listening, filtered, protocol mismatch, and error. Each probe can separately succeed, time out, fail, remain unattempted, or be not applicable. STARTTLS and post-quantum probes can explicitly report unsupported. Do not collapse those states into a single pass/fail label.
Transport findings
The report highlights delivery endpoints without STARTTLS, deprecated TLS versions, weak cipher suites, forward secrecy gaps, and certificates that are expired, untrusted, or do not match the expected name. It also reports post-quantum readiness gaps where evidence is available.
The details can include the negotiated cipher, supported versions, certificate chain state, and authentication mechanisms advertised by the service. These are observations of public mail transport behavior, not an assessment of mailbox access or the contents of messages.
Investigate and retest
Give your mail operator the affected MX hostname, address, port, and exact probe result. Managed mail providers may control these settings on your behalf. Check all receiving routes rather than only the highest-priority MX server.
Retest after a change and distinguish a successful probe from one that was not attempted. Review email policies as well: transport encryption and sender-authentication policies answer different questions. Email findings currently appear separately from the numerical TLS score.