Connection timed out on port 25 — how to fix it

PowerMTA logs full of connection timeouts usually mean one unglamorous thing: your server can't reach the outside world on port 25. It's the single most common surprise when standing up an MTA on a cloud box — and it's a network problem, not a PowerMTA one. No configuration change fixes a blocked egress, so the first job is to prove that’s what you’re facing, and the second is to decide between getting 25 opened and routing around it.

Why this happens

Most cloud providers block or throttle outbound TCP/25 by default, because open 25 is what spam operations abuse. New accounts and fresh IPs get the restriction automatically. So the connection never completes, PowerMTA reports timeouts, and the queue backs up — even though your configuration is fine.

Confirm it really is the egress block

Before assuming anything, prove the port is blocked outbound with a manual test from the server. Open a raw TCP connection to a couple of well-known MX hosts on 25 — if every one hangs and times out rather than returning a 220 banner, your egress on 25 is blocked:

nc -vz aspmx.l.google.com 25
nc -vz gmail-smtp-in.l.google.com 25
# open  → “Connection ... succeeded” / a 220 banner
# blocked → hangs, then “Connection timed out”

The matching symptom in your logs is a deferral such as dsn=4.4.1, status=deferred (connect to …:25: Connection timed out) across many destinations at once. If you run tcpdump you’ll see SYN packets leave and nothing come back — the connection attempt is being dropped upstream of your server. The giveaway is that it fails for every recipient MX, not one: a single destination timing out is that server’s problem, but all of them timing out is your own outbound path.

Rule out what's yours to fix

Before contacting anyone, check the layers you control: the OS firewall (firewalld / iptables) and the provider's security-group or egress rules. A self-inflicted egress block on 25 is common and quick to fix. If those are open and it still times out, the restriction is upstream at the provider.

Work outward through the layers. On the host, check the active firewall — ufw, firewalld, nftables or a control-panel firewall like csf — for a rule that drops outbound 25, and confirm there’s no blanket “deny all egress” policy quietly catching it. One level up, check the provider’s network controls: an AWS security group or VPC rule, an Azure NSG, a GCP firewall rule, a DigitalOcean cloud firewall. These you can change yourself, and a surprising number of “provider blocks” turn out to be a security group nobody opened. Only once every layer you control is open should you conclude the block is the provider’s platform-level egress filter — the one you can’t edit directly.

Why 587 and 465 won't save you

A tempting wrong turn is "just send on 587." But 587 and 465 are submission ports — for a client handing mail to its own server. Delivery to a recipient's MX happens on port 25, the only port their MX accepts mail on. If you can't open 25, the supported answer is to relay through a smarthost that has 25, not to change ports.

Get 25 open, or relay

Check your provider's policy: some lift the outbound-25 block after you request it and demonstrate legitimate, authenticated sending; others don't allow 25 at all and expect a relay. Either path is fine — what isn't is hopping from provider to provider to dodge the block, which just spreads fresh IPs around the same unsolved sending problem.

Provider policies vary widely

The platform-level block isn’t uniform, and which provider you’re on largely decides your options. Treat each provider’s own current documentation as the source of truth — policies change — but the broad pattern looks like this:

Provider	Outbound 25 by default	Can it be opened?
AWS EC2	Blocked	Request form + valid use case; often declined
Microsoft Azure	Blocked	Enterprise agreements only; non-enterprise can’t
Google Cloud	Blocked	Exception on request in some cases
DigitalOcean	Blocked (25/465/587)	Support may lift; not guaranteed
OVH / Hetzner	Open or on request	Generally yes, with anti-spam monitoring
Dedicated / many VPS	Usually open	Yes — the usual home for direct-to-MX sending

The honest summary: some providers gate 25 but will open it for a clear, legitimate use case; some never will and expect you to relay; and some leave it open from the start. Knowing which camp you’re in tells you immediately whether to file a request, plan a relay, or simply move the workload somewhere that fits direct sending.

The deeper point: pick a host that allows port 25

Here’s the thing many guides skip: the whole point of running your own PowerMTA or KumoMTA is direct delivery to recipient MX servers on port 25. That’s where your control over IPs, throttling and reputation comes from. If you’re on a host that permanently blocks outbound 25 — AWS, Azure, DigitalOcean — you can’t do that at all, and no amount of configuration changes it. So for a serious self-hosted sender, the real fix usually isn’t fighting the block; it’s running the MTA somewhere that permits outbound 25 in the first place.

That points you toward dedicated servers and the many VPS and bare-metal providers that allow port 25 (often with anti-spam monitoring rather than a hard block), instead of the big clouds whose default posture is built around not letting customers send mail directly. Choosing the right home for the MTA at the start avoids the whole problem: you get clean outbound 25, dedicated IPs whose reputation is yours to build, and none of the relay compromises below. If you’re planning a build or a migration, make “does this host allow outbound 25?” one of the first questions, not something you discover on launch day.

When relaying is the right answer

Sometimes you can’t move the workload — the application has to live on a specific cloud for other reasons — and the provider won’t open 25. In that case the supported path is to relay outbound mail through an authorized smarthost that does have port 25 open, connecting to it on the submission port (587) with authentication. You point the engine’s delivery at the relay rather than straight at recipient MX, and the relay handles the final hop on 25.

Be clear-eyed about the trade-off, though. Relaying through a third-party service (an SMTP relay or ESP) means the relay’s IPs and reputation are now in the delivery path, no longer yours alone — you’ve given up some of the direct control that self-hosting was meant to provide, and you’re back to a per-message relationship with a provider. It’s a perfectly valid architecture, and often the pragmatic one on a locked-down host, but it’s a different model from direct-to-MX sending rather than a drop-in substitute. Decide deliberately which you’re running.

Don’t confuse it with other timeouts

Not every connection timeout is an egress block, and misreading one for another wastes time. If mail fails to one destination while others flow, suspect that destination, not your network: the recipient’s server may be down, may be greylisting you (a deliberate temporary deferral that succeeds on retry), or may be refusing your IP specifically. A DNS or MX-resolution failure looks different again — the error names a lookup problem rather than a connection timeout — and is fixed in DNS, not the firewall.

The clean test remains the manual TCP connection to several different MX hosts. All of them timing out points at your outbound 25; a mix of successes and failures points at the specific failing destinations or their policies toward you. Sorting that out first stops you from filing a port-unblock request for a problem that was really greylisting, or chasing a recipient’s server for a block that was really your own egress.

Requesting an unblock, the right way

If your provider does lift the block on request, the request itself is a small art, because the block exists to filter out spammers and you’re trying to demonstrate you aren’t one. Lead with a clear, specific use case: what you send, to whom, on what basis (opt-in), and roughly what volume. Mention that your domain has SPF, DKIM and DMARC in place and that your lists are permission-based. Vague requests — “I need to send email” — are the ones that get declined; concrete, legitimate ones are what the reviewers are looking for.

Watch the provider-specific gotchas, too. Some platforms scope the unblock to a particular instance or IP, so a request has to name exactly what you want opened; a few will quietly open only one product family unless you spell out the rest. And expect the answer to sometimes simply be no — a handful of providers have effectively stopped granting these at all. If yours is one of them, don’t keep escalating; that’s your signal to relay or to move the MTA to a host built for direct sending.

The SMTP ports, and why only 25 delivers

The confusion behind “can’t I just use another port?” comes from treating all SMTP ports as interchangeable. They aren’t — each has a job:

Port	Role	Used for
25	MTA-to-MTA relay	Server-to-server delivery to a recipient’s MX — the only port their MX listens on
587	Submission (STARTTLS)	A client or app handing mail to its own server with authentication
465	Submission (implicit TLS)	The same submission role over an implicitly encrypted connection
2525	Alternate submission	A common non-standard fallback when 587 is blocked; still submission, not delivery

The key fact: a recipient’s mail server accepts incoming mail on port 25. The submission ports are for the first hop — you to your server, or your app to a relay — not for the final delivery hop to someone else’s MX. That’s why “switch to 587” only works when you’re relaying through a smarthost that itself talks to MX hosts on 25; the 25 hop still has to happen, just somewhere your traffic is allowed.

Why providers block it in the first place

It helps to understand the block isn’t arbitrary. Port 25 is the single most abused port for spam: a large majority of the world’s junk mail originates from compromised cloud instances and hijacked residential connections sending directly to MX servers. Blocking outbound 25 by default is how providers stop a freshly-compromised box on their network from becoming a spam cannon and dragging their entire IP range’s reputation down with it.

That’s also why getting it opened means proving you’re the exception — a known, legitimate, authenticated sender — rather than just asking nicely. Seen that way, the block is a feature working as intended, and the right responses (demonstrating legitimacy, relaying through an authorized path, or hosting where direct sending is expected) all work with that logic rather than against it. The wrong responses — IP-hopping, evasion — are exactly the behaviour the block was designed to catch.

After it’s open, verify and ramp gently

Once 25 is open — by an unblock, a relay, or a move — re-run the same TCP test to a couple of MX hosts and confirm you now get a 220 banner instead of a hang. Then send a seed message and check it actually arrives and authenticates, because an open port only means the connection can leave; placement still depends on reputation and authentication being right. Treat the working connection as the start line, not the finish.

If the IP is new — likely, if you just opened 25 on a fresh host or moved providers — don’t mistake “connection works” for “ready for volume.” A brand-new IP with no history needs warm-up before it sends at target, or you’ll trade a timeout problem for a throttling one. Ramp gradually so the IP builds reputation as it goes, exactly as you would for any new sending address.

The bottom line

A wall of port-25 connection timeouts is a network problem, not a PowerMTA or KumoMTA one, so don’t touch the engine config until you’ve proven the egress. Run a manual TCP test to several MX hosts: all of them timing out means outbound 25 is blocked; a mix means specific destinations are the issue. Rule out your own firewall and the cloud security group first — those are yours to open — then identify the provider’s platform policy.

From there it’s a clean decision tree: request the unblock with a legitimate use case where the provider allows it; relay through an authorized smarthost on 587 where it doesn’t and you must stay put; and, for a serious self-hosted sender, prefer a host that allows outbound 25 from the start so direct-to-MX delivery just works. What you never do is hop from provider to provider burning fresh IPs to dodge the gate — that spreads an unsolved problem rather than fixing it. If you’d rather not navigate egress, firewalls and relays yourself, our setup service sorts the outbound path and configures the engine around it, and the Auto PMTA Configurator builds on infrastructure where port 25 works — so the timeout you started with never reappears once the engine is delivering directly to MX the way it’s meant to, for legitimate, opt-in senders.