“SMTP timed out” can describe several different events. A DNS query may have timed out, a TCP connection may not have completed, or an established connection may have waited too long for a greeting or final message response. These stages have different evidence and different duplicate-delivery risks. Identify the stage before choosing a repair.
Resolve the destination before testing it
Record the recipient domain and the MX answer actually used, including preference values and lookup time. RFC 5321 describes MX selection and address resolution, including implicit MX behavior when no MX records exist. When the domain exists but has no MX records, implicit MX handling uses the domain itself with the applicable address records; NXDOMAIN and temporary DNS errors are different results. That is different from an explicit null MX declaration, which signals that a domain does not accept email under RFC 7505. Do not convert every unusual DNS result into a guessed destination. RFC 5321 section 5.
For each selected host, preserve relevant address-family results and the connection outcome. A successful IPv4 test does not establish that the failing sender's IPv6 path works. Likewise, a working public resolver result does not prove what a particular sending system saw earlier. Record DNS errors separately from successful answers pointing to unreachable hosts.
Distinguish refusal from silence
A connection refusal usually indicates an explicit rejection of the attempted TCP connection. A timeout means the expected event was not observed within the allowed interval. Neither observation alone identifies the responsible firewall, service owner or route. Filtering, network faults, listener availability and other conditions can produce similar user-visible symptoms.
After TCP succeeds, note whether the server sent its SMTP greeting. Then identify the exact command awaiting a response. RFC 5321 specifies distinct timeout guidance for several SMTP stages. An operator's short diagnostic timeout is a testing choice, not evidence that a production MTA violates or satisfies those requirements. Do not apply one aggressive timeout to every stage and call the result definitive.
Preserve uncertainty after message transfer
A timeout after the final message data is more delicate than failure to connect. The receiver might have accepted responsibility while its final response was lost. Repeating the transaction can therefore produce a duplicate. Keep the final response status as unknown unless sending and receiving evidence resolves it; do not automatically label the message “never received.” RFC 5321 sections 4.5.3.2 and 6.1.
For connection failures before any SMTP exchange, no message has been transferred on that connection. That narrower conclusion still does not describe previous attempts in the same queue. Correlate all attempts before deciding whether a business transaction needs another submission.
Compare three hypothetical timeout records
Case A never establishes TCP to the selected MX. Keep the diagnosis at the connection stage; no SMTP message crossed that connection. Case B establishes TCP but records no 220 greeting before the diagnostic tool's chosen deadline. Investigate listener behavior and the relevant greeting timeout, rather than calling it the same failure as A.
Case C transmits message data and its terminator but loses the final response. Acceptance is unknown, so check the sender queue and receiver evidence before adding another copy. These invented cases contain no executed socket tests, measured recovery or provider timing claim. A short diagnostic timeout is not a production recommendation.
For a real unavailable-MX incident, retain the resolved hosts and preferences, every attempted address family, failed stage and queue decision. A lower-priority MX working in a standalone test does not prove the affected sender used it; verify the actual attempt history.
Repair and confirm the affected path
Assign DNS, network and mail-service evidence to their respective owners. Retest the same approved destination and address family after one relevant correction, and preserve a comparison from another authorized network only when useful. Confirm queue recovery and aging messages before declaring success. Do not weaken mail authentication because a TCP session could not be established.
Choose the failed-stage owner
- DNS failure: retain the actual resolver result and time.
- TCP failure: record destination, address family and path evidence.
- Greeting or command wait: name the missing reply and configured timeout.
- Final DATA reply missing: reconcile acceptance before manual resubmission.
- Recovery: account for aging and expired queue items, not merely one successful connection.