How to resolve a 'connection refused' network error when sending emails?
Updated on 5 Oct 2026: We clarified SMTP connection refused errors and added checks for multiple MX addresses, IPv6, and queued mail recovery.
A 'connection refused' network error when sending email is resolved by first identifying whether the failed TCP connection was to a recipient MX on port 25 or a configured SMTP relay on port 587, 465, or another documented port. Then fix the endpoint, listener, or network path. Changing DMARC, SPF, or DKIM will not fix a pre-SMTP refusal. Request blocklist (blacklist) delisting only for a confirmed listing.
Use this order: confirm the configured SMTP host and port, decide whether the sender uses direct MX delivery or a relay, test that endpoint from the real sending host, compare the failure scope, then check the listener, routing, firewall, NAT, and provider limits. A response received directly from the destination SMTP service proves TCP connected; a 4xx or 5xx code shown only in a delivery report does not.
- Fast answer: Test the configured SMTP endpoint from the same host that sends mail. Use the recipient MX on port 25 for direct delivery, or the configured relay port for submitted mail.
- First split: Distinguish a failed TCP connection from a response received directly from the destination SMTP service. A delivery report can describe either failure.
- Best proof: Keep the destination host and port, source IP, timestamp, command output, route trace, and expected TLS mode.
What a connection refused error means
A true connection refused result means the TCP connection attempt was actively rejected, usually with a TCP reset (RST). Common causes are a stopped SMTP service, a listener on a different port or interface, a listener bound only to localhost, an actively rejecting firewall, or the wrong hostname or IP. A timeout is different: the sending host did not receive a useful response before the connection attempt expired. A reset can come from a firewall or intermediary, so it does not prove that the SMTP server itself received the attempt.
Many mail applications compress both cases into a plain network error. Logs often label a refusal ECONNREFUSED, error 111 on Linux, or socket error 10061 on Windows. SPF, DKIM, and DMARC are checked after an SMTP conversation has started. If the sending server never reaches the SMTP service, those authentication records have not been evaluated yet.
A sending relay can include a downstream refusal in a delivery status notification (DSN), such as 421 service not available or 450 4.4.316 Connection refused. Read the nested socket error and attempted destination IP before classifying the failure as an SMTP policy rejection.
Do not start with delisting
A blocklist (blacklist) problem usually appears as an SMTP rejection after the remote mail server accepts the TCP connection. A network refusal appears before the SMTP banner. Treating a pre-SMTP failure as a blacklist problem wastes time and gives the recipient team weak evidence. A gateway can also reject a source IP before SMTP; confirm its firewall or access logs before treating that as a public blacklist listing.
- Network clue: A TCP probe reports refused or times out before an SMTP session starts.
- Block clue: A response received directly from the destination SMTP service states a policy reason.
Troubleshoot SMTP connection refused step by step
Flowchart for checking MX records, SMTP port 25, routing, and connection refused errors.
The fastest fix comes from separating a few questions. Is the configured SMTP endpoint correct? Can the sender open a TCP session to its required port? If the connection works, does TLS or SMTP fail next? Each answer points at a different owner.
- Check the endpoint: For direct delivery, resolve the recipient domain's current MX. For submitted mail, read the relay host and port from the running application.
- Test TCP: Connect to that endpoint and port from the production sending host, not your laptop.
- Compare scope: If every relay attempt fails, focus on the application, server, or provider. If direct delivery fails for one domain, focus on that route or recipient gateway.
- Collect proof: Save the exact socket error, destination IP and port, TLS mode, UTC timestamp, public source IP, and connection or packet-capture output. Include a route trace as supporting evidence.
- Escalate clearly: Ask the network, relay, recipient, or gateway team that owns the failed endpoint to check its listener, firewall, route, or sender deny rule.
Test the correct SMTP endpoint and port
Start with the lowest-level test that matches the real sending path. A mail transfer agent delivering directly to a recipient tests the MX on port 25. An application using authenticated submission tests its configured relay, commonly with STARTTLS on port 587 or implicit TLS on port 465. Run the test from the actual sending host because another machine can have a different route, NAT address, firewall, or provider policy. Replace the example hostnames and IPs in all commands with your actual endpoints.
SMTP reachability tests on Linux or macOSBASH
dig +short MX example.com dig +short A mx1.example.net nc -vz -w 5 mx1.example.net 25 openssl s_client -starttls smtp -connect mx1.example.net:25 -crlf nc -vz -w 5 smtp.example.net 587 openssl s_client -starttls smtp -connect smtp.example.net:587 -crlf openssl s_client -connect smtp.example.net:465 -crlf
|
|
|
|---|---|---|
Connected | TCP works | Read banner or TLS |
Refused | Port rejected | Check endpoint, listener, and rejecting firewall |
Timed out | No timely connection response | Trace route and filtering |
No route | Network or host unreachable | Check routing |
TLS error | TCP works | Match port and TLS mode |
4xx or 5xx received directly over SMTP | Temporary (4xx) or permanent (5xx) SMTP failure | Read the full reply and fix its stated cause |
Read the first network result before changing email policy.
If the command connects and shows a banner such as 220 mail.example.net ESMTP, TCP reachability works for that attempt. On port 465, a TLS handshake must complete before the SMTP banner appears. On port 587, the server normally presents an SMTP banner before STARTTLS. A TLS or certificate error after TCP connects needs investigation of the TLS mode or certificate trust. OpenSSL s_client continues after certificate verification errors by default; for strict relay verification, add -verify_return_error -verify_hostname smtp.example.net. Correct the certificate or trust configuration rather than disabling verification.
On Windows, use Test-NetConnection and read TcpTestSucceeded rather than PingSucceeded. A false result confirms a failed TCP test; application logs or a packet capture identify refusal versus timeout.
SMTP TCP tests on WindowsPOWERSHELL
Test-NetConnection -ComputerName mx1.example.net -Port 25 -InformationLevel Detailed Test-NetConnection -ComputerName smtp.example.net -Port 587 -InformationLevel Detailed
Check application SMTP submission settings
When an application, website, printer, or scheduled job sends through an SMTP relay, the recipient's MX is not the first destination. The application connects to the host in its own mail settings. Some libraries default to localhost or 127.0.0.1, which produces an immediate refusal when no local mail service is listening.
- Loaded configuration: Confirm the running process has loaded the intended relay hostname and port, including any environment variable or secret override. Verify that the hostname resolves to the mail server rather than the web application or an old server.
- Port and TLS: Use STARTTLS when the relay documents port 587, and implicit TLS when it documents port 465. Do not assume changing the port alone changes the application's TLS mode.
- Listener binding: If the relay is local, verify that the mail service listens on the address and port the application uses, not only on another interface.
- Container routing: Inside a container, localhost refers to that container. Use the reachable service name or network address for a relay running elsewhere.
- Authentication stage: Wrong credentials produce an SMTP authentication response after a connection and banner. They do not cause a TCP connection refused result.
Application relay checksBASH
getent hosts smtp.example.net nc -vz -w 5 smtp.example.net 587 openssl s_client -starttls smtp -connect smtp.example.net:587 -crlf openssl s_client -connect smtp.example.net:465 -crlf ss -ltnp | grep -E ':(25|465|587)\b'
Compare a shell test with the application's effective settings and logs. If the shell connects but the application still reports a refusal, check its runtime network namespace, proxy or egress rules, DNS resolver, and whether a worker restart is required to load the corrected settings.
Check DNS, routing, and the sender path
For direct MX delivery, MX records decide which host the mail server tries first. A stale DNS cache, old route, or resolver issue can send traffic to an IP that the recipient no longer uses. Check the MX answer, the resolved A or AAAA record, and the path from the sending server. For relay submission, perform the same address and route checks against the configured relay hostname instead.
Route and packet path checksBASH
traceroute mx1.example.net mtr -rwzc 20 mx1.example.net ping -c 4 mx1.example.net ip route get 203.0.113.10 sudo tcpdump -ni any 'host 203.0.113.10 and tcp port 25'
Traceroute and MTR show responses to their probes; missing hops do not prove a broken route because routers also filter or deprioritize probes. When supported, use TCP probes for the actual SMTP port. Ping is weaker because many mail gateways ignore ICMP. Packet capture shows whether the sender transmits SYN packets and receives a reset, completes a handshake, or gets no reply. Compare captures with firewall and endpoint logs to identify the rejecting device.
Check the sending domain's DNS and authentication posture while the network owner investigates. Suped's domain health checker helps identify DMARC, SPF, and DKIM configuration issues to address after the TCP problem is fixed. Passing DNS checks does not guarantee message acceptance.
Check every MX host and IPv4 or IPv6 address
For direct delivery, test every published MX host, starting with the lowest preference number. Resolve each host's A (IPv4) and AAAA (IPv6) records and test each returned IP on port 25. One failing address can explain intermittent refusals. Compare the results with the exact destination IP in the sending logs.
Compare MX hosts and address familiesBASH
dig +short MX example.com | sort -n dig +short A mx1.example.net dig +short AAAA mx1.example.net nc -4 -vz -w 5 mx1.example.net 25 nc -6 -vz -w 5 mx1.example.net 25 nc -vz -w 5 203.0.113.10 25 nc -6 -vz -w 5 2001:db8::10 25
The -4 and -6 hostname checks compare address families; repeat the literal-IP tests for every returned address and MX host. For a relay, use its configured port. If only IPv6 fails, check its route, firewall rules, and SMTP listener. Confirm the MTA tries alternative destinations according to its configuration instead of stopping at the first refusal.
Tell network failure apart from blocking
The phrase 'refused' is easy to misread. A network refusal means the TCP connection attempt failed. An SMTP policy rejection is a reply received over an established connection. A gateway firewall can also reject connections based on source-IP policy before SMTP starts. A TLS negotiation error happens after TCP connects but before message transfer. Each case needs different evidence and a different owner.
Network failure
- Signal: The TCP connection fails with a socket error before SMTP starts.
- Layer: TCP, routing, firewall, provider policy, or remote listener.
- Owner: Sender network, hosting provider, relay operator, recipient gateway, or transit path.
SMTP or reputation block
- Signal: The destination SMTP service returns a reply over an established connection, with a stated SMTP or policy reason.
- Layer: SMTP policy, authentication, reputation, rate limit, or content filtering.
- Owner: Sender admin, recipient postmaster, or gateway policy team.
If an SMTP rejection names a blacklist or states an IP reputation problem, check Suped's blocklist monitoring and review the cited evidence before contacting the recipient. Access denied also describes authentication or relay-permission problems, so follow the full reply. If TCP never connects, focus on reachability and connection-level access rules.
Fix issues on your sending side
When the same sender fails against many unrelated domains or cannot reach its configured relay, the fault is usually local or provider-side. Common causes include outbound SMTP restrictions, a stopped or misbound local MTA, firewall changes, NAT changes, a missing route, DNS resolver failures, or rate controls at the hosting provider.
- Outbound port: Confirm your hosting provider allows the required SMTP port. Direct MX delivery requires port 25. If it is restricted, request a provider-approved exception or configure a submission relay on its documented port, commonly 587 or 465. Changing to port 587 on a recipient MX is not a substitute for a relay.
- Local MTA: Check that the mail process is running and listening on the address and port the application expects.
- Firewall: Review host firewall, cloud security groups, egress ACLs, and network appliances.
- NAT path: Confirm the public source IP is the IP you expect recipients or the relay to see.
- DNS resolver: Compare the application's resolved address with the authoritative answer and check local hosts-file overrides. Clear the relevant cache only if it is stale.
- Volume control: If failures started after a traffic spike, check per-IP connection limits and SMTP listener capacity, especially when jobs share one NAT IP. Reduce concurrency to the documented limit and use normal retry backoff.
Local sender checksBASH
systemctl status mail-relay ss -ltnp | grep -E ':(25|465|587)\b' journalctl -u mail-relay --since today ip route get 203.0.113.10 sudo nft list ruleset
The exact commands change by operating system and MTA, but the intent is stable: prove the mail service is running, prove the host can route to the destination, and prove no local policy blocks the required SMTP port. Replace mail-relay with the actual SMTP service unit on your host. Review the complete firewall ruleset, since broad deny rules do not have to mention SMTP ports.
Escalate recipient-side or gateway-side failures
If direct MX delivery fails for only one recipient domain, and your sender can reach other domains on port 25, the recipient's MX endpoint or the route to it is the likely area to investigate. Many domains use a third-party gateway, so the team that can fix the refusal is often the gateway operator rather than the visible recipient domain. If an application cannot reach its configured relay, send the same evidence to the relay operator instead.
Send evidence, not guesses
A useful escalation says exactly what public source IP tried to connect, which host, destination IP, and port refused or timed out, and when it happened. Include the exact socket error and any packet-capture evidence. Request delisting only for a confirmed blacklist listing.
|
|
|
|---|---|---|
Source IP | Firewall lookup | 198.51.100.24 |
SMTP host | Endpoint owner | mx1.example.net |
Port | Listener lookup | 25 |
Time | Log search | UTC timestamp |
Result | Error layer | ECONNREFUSED before SMTP |
Trace | Path check | MTR output |
Keep escalation evidence short and precise.
Short escalation template
Subject: SMTP TCP connection refused to mx1.example.net Public source IP: 198.51.100.24 Destination host: mx1.example.net Destination IP: 203.0.113.10 Destination port: 25 Time: YYYY-MM-DD HH:MM UTC TLS mode: plain SMTP initially, STARTTLS if supported Result: TCP connection refused before SMTP banner Socket error: ECONNREFUSED Packet capture: SYN followed by RST, if captured Trace: attached traceroute or MTR output
This gives the recipient, relay, or gateway team enough information to check deny rules, route changes, listener health, and source IP policy. It also prevents the case from bouncing between support teams because the layer is clear.
Where Suped fits after the network test
DMARC, SPF, and DKIM do not fix a pre-SMTP connection refusal. They matter immediately after the connection works because the next failure can involve authentication, sender identity, or reputation. Continuous DMARC monitoring keeps that second layer visible. DMARC reports describe authentication for mail a receiver processed; they cannot diagnose a connection that never reached SMTP.
Suped's DMARC reporting and email authentication platform groups aggregate reports by sending source, with SPF and DKIM results and alerts. Teams can use those reports to investigate authentication gaps after SMTP delivery resumes.
Email tester sample report showing total score, email preview, issue summary, and per-section results
For a real message check after the route is healthy, Suped's email tester gives a practical report covering authentication, headers, content signals, and delivery risks. That keeps the TCP issue separate from the next set of fixes.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
For MSPs and multi-domain teams, review the affected sending source across domains and assign any SPF or DKIM DNS changes to the team that manages those records.
Views from the trenches
Best practices
Test the actual SMTP host and port before treating a refusal as a blacklist problem.
Record the source IP, destination MX, timestamp, and exact TCP result for escalation.
Compare one failing recipient with several working recipients before changing sender settings.
Common pitfalls
Requesting delisting without a confirmed listing delays listener and network troubleshooting.
Testing only through an application log misses firewall, NAT, and routing failures upstream.
Assuming every timeout is a block delays checks for port 25 restrictions and route loss.
Expert tips
Run traceroute or MTR from the actual sending host, not a laptop on another network.
If the MX points at a gateway provider, send evidence to that gateway support team first.
Keep authentication healthy so the message is not rejected after the connection works again.
Marketer view
Marketer from Email Geeks says a plain connection refused or timeout result is a network error, not a normal SMTP rejection.
2024-01-26 - Email Geeks
Marketer view
Marketer from Email Geeks says the first manual test should be a direct port 25 connection to the recipient MX.
2024-01-26 - Email Geeks
The port 25 observation applies to direct MX delivery. For an application using an SMTP relay, test its configured submission port instead.
Confirm delivery and retry queued mail
Resolve a 'connection refused' email sending error by treating it as a network endpoint problem first. After correcting the endpoint or network path, send a test message from the real application and confirm that the SMTP server accepts it with a 250 response after message data. Confirm recipient delivery separately, since SMTP acceptance establishes the handoff.
Check the outgoing mail queue for deferred messages and allow the MTA's scheduled retries. If needed, retry the affected queue through its documented controls after fixing the cause; avoid repeated forced retries. For an application without an SMTP queue, use its job retry mechanism and check whether a message was already accepted before resending.
