Separate submission from delivery
First, the website or mail client authenticates to its SMTP service and submits a message. Then the mail server resolves the recipient domain’s MX and attempts delivery. Success in the first connection does not establish network access or acceptance in the second.
Port 587 is the standard submission service. Changing a recipient MX destination to port 587 is not a general delivery solution: any service there may require credentials and sender permissions you do not have. A relay is a separate forwarding service you are authorized to use.
Identify the failing queue stage
| Evidence | Investigate |
|---|---|
| MX or address resolution failure | DNS and destination records |
| TCP timeout or connection error | Network path, filtering or destination availability |
| TLS validation failure | Certificate name, chain and protocol |
| SMTP 4xx or 5xx response | The remote temporary or permanent rejection |
| Accepted message later in spam | Post-delivery classification and reputation |
Evaluate outbound TCP 25 from the right place
- Test from the server and network environment where the mail service runs, not just from another workstation.
- Resolve current MX records for several recipient domains and record TCP 25 outcomes.
- Inspect IPv4 and any usable IPv6 path separately; account for incorrect address records or broken IPv6 routing.
- Compare Windows outbound rules, gateway filtering and provider policy. One timeout cannot locate the blocking device conclusively.
Choose a viable delivery route
Direct delivery requires the necessary network access, DNS and sender operations. If the provider will not allow outbound TCP 25, authenticated relay over an allowed submission port can carry outgoing mail while mailboxes remain on your server.
Check relay domain verification, sender authorization, volume limits, failure reporting and SPF/DKIM/DMARC alignment. Do not introduce a second SPF record when updating the sending policy; account for all legitimate routes together. Keep relay credentials out of logs and support messages.
Verify the correction without deleting the queue
Use a small set of authorized test recipients. Follow connection, TLS and SMTP stages for the new attempt, then record remote acceptance separately from the recipient’s visible result. Also inspect retry behavior for temporary failures.
A repaired TCP connection does not guarantee inbox placement. Authentication, content and recipient policy remain separate factors. Do not disable certificate validation to make a TLS failure appear resolved.
Frequently asked questions
Why can mail fail when port 587 is open?
Port 587 usually covers client submission to your SMTP service. Direct MX delivery additionally needs a working outbound TCP 25 connection.
Can I use port 587 on the recipient MX instead of 25?
Not as a general workaround. Submission services normally require authorization. Use a relay you are entitled to send through.
Does a timeout prove the ISP blocks delivery?
No. A local firewall, gateway, route or destination can also cause it. Compare multiple destinations and network layers.
Does using a relay move my mailboxes?
Outgoing relay routing can be configured while keeping mailboxes on your own server. Plan inbound and outbound mail paths separately.