Mail Server Test
Mail Server Test checks MX records and verifies practical SMTP connectivity to discovered mail hosts. It helps isolate whether delivery failures come from DNS, network reachability, or server handshake behavior.
π§ͺ Run this tool π Excessive Explanation β Frequently asked questions
π§ͺ Run this tool
π Excessive Explanation
𧩠Technical Details
What this tool checks
- MX discovery and priority ordering validation.
- TCP connectivity and greeting behavior for selected servers.
- STARTTLS availability indicators where supported.
How to read the output
- Result Summary indicates whether core mail-path prerequisites are healthy.
- Overview highlights MX reachability and handshake outcomes per host.
- Technical Details should be reviewed for per-server transcript anomalies.
- Raw Output is suitable for escalation to mail operators.
Common failure patterns
- MX points to hosts that are unreachable or misconfigured.
- Greeting delays trigger sender timeout and queue backoff behavior.
- STARTTLS offered inconsistently across MX pool members.
- Priority ordering does not match intended failover design.
Remediation workflow
- Correct MX records and verify host targets exist and resolve properly.
- Validate firewall and listener configuration on all advertised MX hosts.
- Align STARTTLS posture and certificates across the pool.
- Re-run test after any MX or SMTP service changes.
Next steps
β Frequently asked questions
Why test multiple MX servers?
Inbound mail reliability depends on the whole MX set, not only the primary host.
Can one failing MX still affect delivery?
Yes. Some senders may hit failing hosts before retrying lower-priority targets.
Is STARTTLS mandatory for all deliveries?
Policy varies, but weak TLS posture increases trust and compliance risk.
Should I remove unreachable backup MX quickly?
Yes. Stale failover records create avoidable delivery delays.
What is next after MX connectivity is healthy?
Run SPF/DMARC/DKIM and DNSBL checks for deliverability posture.