What does SMTP connection refused mean?

SMTP connection refused means the sending host reached the destination IP, but the TCP connection to the selected port was rejected before the receiving server opened an SMTP session. No 220 greeting appeared, so this is not an SMTP 4xx or 5xx response. Check the resolved MX host, every advertised IP address, the port, the SMTP listener, and firewalls on both paths. Test from the same network as the sending MTA before changing SPF, DKIM, or DMARC.

Quick takeaways

• Connection refused occurs at the TCP layer, before SMTP begins.
• It is different from an SMTP 550 rejection or a connection timeout.
• Server-to-server SMTP relay uses TCP port 25; ports 587 and 465 are for message submission.
• Test every MX host and every advertised A or AAAA address from the affected sender.
• SPF, DKIM, and DMARC changes cannot open a closed or blocked TCP listener.

What does the failure mean?

The refusal is at the TCP layer. Under RFC 9293's TCP reset rules, if no connection exists for an incoming TCP attempt, the destination can answer with a reset. The sending application then reports connection refused. SMTP has not received a 220 greeting, so there is no reply code to interpret.

A timeout tells a different story: the sender did not receive a usable response before its connection timer expired. Keep refused, timed out, and connected results separate because they point to different network behavior.

One failed address does not mean the whole domain is unavailable. Under RFC 5321's SMTP delivery rules, a client can have several MX hosts or several IP addresses to try. A fully capable client tries the relevant addresses in order and queues mail that cannot be delivered immediately.

Do not begin by editing authentication records. SPF, DKIM, and DMARC matter only after the receiving path accepts enough of the SMTP transaction or message to evaluate them.

What usually causes it?

The destination or port is wrong

The sender may be connecting to a stale IP address, a hostname that is not an MX target, or a message-submission port instead of TCP port 25.

No SMTP service is listening

The receiving MTA may be stopped, still starting, bound only to a private interface, or configured not to listen on the advertised public address.

A firewall or edge service rejects the connection

A host firewall, network firewall, load balancer, or cloud security rule can return a reset before traffic reaches the MTA.

One MX host or address is stale

A migration can leave one MX target, A record, or AAAA record pointing to infrastructure that no longer accepts SMTP.

The sending route cannot use outbound port 25

An egress firewall or relay policy can reject the sender's direct connection even while other networks reach the same MX host.

How do I diagnose the failure?

1. Preserve the exact queue evidence

Record the timestamp, recipient domain, selected MX hostname, destination IP address, port, address family, queue ID, and operating-system error. Do not diagnose from the words connection refused alone.

2. Resolve and test every current destination

Query the authoritative and public MX answers, then expand each target to its A and AAAA addresses. From the affected sender, connect to every advertised address on TCP port 25 and record whether it is refused, times out, or returns a 220 greeting.

3. Check the receiving listener and controls

If you manage the destination, confirm that the MTA is running, bound to the advertised interface, and allowed through host, network, load-balancer, and cloud controls.

4. Compare another network and address family

Test the same destination from a second network. Compare IPv4 with IPv6 only when DNS advertises both. A result that changes by source or address family narrows the problem to that path.

How do I fix it?

Correct stale MX, A, or AAAA records. Restore the SMTP listener or allow the intended server-to-server route through the relevant controls. If direct outbound TCP port 25 is not permitted, configure the sender to use its authorized relay instead of trying to bypass the restriction.

Keep a backup MX record only when that host accepts mail for the domain. An advertised target that always refuses connections is not working redundancy.

How do I validate the repair?

Resolve the route again from authoritative DNS and at least one public resolver. Each intended destination should accept TCP port 25 and return an SMTP 220 greeting.

Send a controlled message through the original production path. Confirm a 250 response after the message data, verify delivery to the test mailbox, and inspect the received headers. If that path sends as your domain, confirm its SPF, DKIM, and DMARC results in subsequent DMARC reporting.

Use Palisade's Email Security Score for a public configuration review, but keep DNS answers, SMTP responses, delivered headers, and provider state as the production evidence.

Make SPF, DKIM, and DMARC easier to manage

Palisade's DMARC Agent turns report data into a prioritized list of sender, SPF, DKIM, and DMARC issues. Your team can see what to fix next and follow a guided path toward stronger authentication and DMARC enforcement. Stronger authentication helps protect your domains and supports better email deliverability. start a Palisade account.