Email security is assessed for the domain you submitted. SSLBoard looks at its mail routing and probes the mail endpoints it finds. It does not repeat the domain-policy assessment for every discovered web subdomain.
Where your mail goes
| Result | What it means |
|---|---|
| Mail service found through MX records | DNS names your receiving mail hosts. Normal |
| Implicit MX delivery | Delivery falls back to the domain’s own address record rather than an MX list |
| Domain explicitly does not receive mail | A null MX policy. Deliberate, and correct if intended |
| No resolvable receiving mail service found | No usable destination could be established |
| Mail routing needs review | The MX configuration was reported as invalid |
| Status could not be confirmed | Not enough evidence to classify |
Finding a route is not proof mail gets delivered. And a domain that intentionally receives no mail is not a broken mail server.
Delivery and submission are different jobs
This distinction causes more misdirected tickets than anything else in the email section.
- Port 25 is delivery. The rest of the internet uses it to send you mail.
- Ports 465 and 587 are submission. Your own users and applications use them to send mail out.
They fail independently. A submission port that is not listening tells you nothing about inbound delivery, and vice versa.
On encryption: STARTTLS upgrades a connection that started in the clear, while implicit TLS is encrypted from the first byte. Port 465 uses implicit TLS; 25 and 587 typically use STARTTLS.
Listener states are listening, not listening, filtered, protocol mismatch, and error. Each probe separately succeeds, times out, fails, remains unattempted, or is not applicable, and STARTTLS and post-quantum probes can explicitly report unsupported. Do not collapse those into pass and fail. A probe that was not attempted is not a probe that passed.
What gets flagged
Delivery endpoints with no STARTTLS, deprecated TLS versions, weak cipher suites, forward secrecy gaps, and certificates that are expired, untrusted, or do not match the expected name. Post-quantum readiness gaps too, where evidence exists.
The details can include the negotiated cipher, supported versions, certificate chain state, and the authentication mechanisms the service advertises. All of this describes public mail transport behavior. None of it touches mailbox access or message content.
Investigate and retest
Hand your mail operator four things: the MX hostname, the address, the port, and the exact probe result. If you use a managed mail provider, several of these settings are theirs to change, not yours.
Check every receiving route rather than only the highest-priority MX. Backup MX hosts are exactly where a TLS upgrade gets forgotten.
After a change, retest and make sure you are looking at a successful probe rather than one that was not attempted. Read this with email policies: transport encryption and sender authentication answer completely different questions. Email findings appear separately from the numeric TLS score.