Port 25 Blocked on Your VPS? Test It in 10 Seconds, Then Stop Fighting It
Run this. It takes ten seconds and needs nothing installed:
timeout 5 bash -c 'exec 3<>/dev/tcp/gmail-smtp-in.l.google.com/25' && echo OPEN || echo BLOCKED
timeout 5 bash -c 'exec 3<>/dev/tcp/smtp.gmail.com/587' && echo OPEN || echo BLOCKED
If 25 is BLOCKED and 587 is OPEN, the block is your provider’s, not yours. No firewall rule you wrote produces that pattern — your own ufw doesn’t know the difference between two outbound ports on the same host. Stop debugging your server.
What we measured
We ran exactly that test from two servers on two continents — one in Nuremberg, one in Ashburn, Virginia:
| Port | Purpose | Nuremberg | Ashburn |
|---|---|---|---|
| 25 | Server-to-server mail | BLOCKED | BLOCKED |
| 465 | SMTPS (implicit TLS) | BLOCKED | BLOCKED |
| 587 | Mail submission | OPEN | OPEN |
| 2525 | Common alternate | BLOCKED | not tested |
Both machines are Hetzner, and that result matches Hetzner’s published policy exactly — which is a useful thing to see confirmed rather than assumed.
What the two best-documented providers actually say
Hetzner blocks 25 and 465 by default and says so plainly, along with the escape route:
“As an alternative, you can also use port 587 to send emails via external mail delivery services. Port 587 is not blocked and can be used without sending a limit request.”
Unblocking is a real, documented process:
”…to unblock these ports for a valid use case. In your request, you can tell us details about your use case. We make decisions on a case-by-case basis.”
And one detail that catches people out: “Port blocking is enforced per account. If a server is transferred to a project that is owned by another account, the port-blocking rules of the new owner will apply.” Your unblock doesn’t travel with the server — it belongs to the account.
DigitalOcean is stricter, and this is the finding that changes the standard advice:
“SMTP ports 25, 465, and 587 are blocked on Droplets to prevent spam and other abuses on our platform. This block applies to all Droplets by default.”
Read that port list again. DigitalOcean blocks 587 as well — so “just use port 587 with a relay”, which is the advice on nearly every page about this, does not work on a DigitalOcean droplet out of the box.
DigitalOcean is also unusually direct about its position:
“Even if SMTP were available, we strongly recommend against running your own mail server, as self-hosted mail servers are difficult to secure and maintain, frequently get flagged as spam, and require constant monitoring to protect your IP address.”
Why every provider does this
Port 25 is how mail servers talk to each other, and it’s unauthenticated by design. A compromised box with open outbound 25 can spray mail directly at the world’s mail servers — which is why the block is close to universal on cloud and VPS platforms, and why it’s applied by default rather than on suspicion.
The consequence for you isn’t just the port. Even with 25 open, a fresh VPS IP starts with no sending reputation, in an address range that receiving mail servers already associate with bulk traffic. You’d then need reverse DNS, SPF, DKIM and DMARC configured correctly, and a warm-up period — the mechanics of SMTP delivery are the easy part; the reputation is the hard part.
The strategic answer: stop fighting for port 25
For transactional mail — password resets, receipts, notifications — you do not want port 25 at all. You want a relay on 587.
The pattern: your application hands mail to a third-party sending service over port 587 with authentication. That service owns the IP reputation, the DKIM signing and the deliverability monitoring. Your VPS never talks to a recipient mail server directly, so the port 25 block is irrelevant.
This is what DigitalOcean tells you to do in the quote above, and it’s what we’d recommend regardless of provider. It’s also less work, not more.
Check 587 before assuming, though — as measured above, it’s open on Hetzner and blocked by default on DigitalOcean.
You genuinely need port 25 only if you’re receiving mail on that server, or running a mail server as the point of the exercise. Both are legitimate; both mean requesting an unblock.
If you’re requesting one: providers ask what you’re sending, to whom, and at what volume — Hetzner’s wording is “tell us details about your use case”, decided case by case. There is no magic phrasing. A specific, honest description of a legitimate use case is the request; anyone selling you a script is selling you nothing.
The providers
Hostinger — $11.99 renewal for 4GB with one-click templates and a well-documented refund window that covers renewals. We could not verify its port 25 policy — its knowledge base renders client-side and we couldn’t read it. Run the test above on day one, inside the 30-day refund window.
Hetzner — the clearest documentation of the six, and the policy we confirmed by measurement: 25 and 465 blocked, 587 open with no request needed, unblocks granted case by case, enforced per account. The best pick if you’ll relay over 587, which is most people. Note cloud instance availability has been limited since June.
AccuWeb Hosting — policy not verified by us. Test before committing.
UltaHost — $15.87 for 4GB with 3 vCPU. Policy not verified by us.
Cloudzy — $17.37 for 4GB billed monthly with no term, which makes it the cheapest way to test a provider’s actual port behaviour before committing to a year. Policy not verified by us.
DigitalOcean — the strictest of the six and the most transparent about it: 25, 465 and 587 all blocked on all droplets by default, with published guidance to use a third-party sending service instead. Don’t pick it for a mail server; it’s an excellent choice for everything else at $24 for 4GB.
The honest summary: for five of these six, the answer is “run the test.” We’ve given you the command, and any provider’s real behaviour beats any article’s table — including this one.
How we checked this
The port measurements are ours, taken on 18 August 2026 using the bash /dev/tcp test shown above from two servers: one in Nuremberg, Germany and one in Ashburn, Virginia. Both are Hetzner Cloud instances — we confirmed that from the instance metadata service and the public IP’s ASN (AS24940 and AS213230, Hetzner Online GmbH). Port 465 was tested twice on the Nuremberg host to rule out a transient failure.
This means our measurements cover one provider, not six. They confirm Hetzner’s documented behaviour on two continents, which is worth something, but they are not a survey. We do not have servers at the other five providers.
The Hetzner policy quotes are from its cloud documentation and the DigitalOcean quotes from its own support documentation, both read the same day.
Four providers in the list above carry no verified policy from us, and we’ve labelled each one rather than filling the gap. The brief for this article asked for a provider-by-provider table — blocked by default, blocked permanently, open with rate limits, or open — and we can only fill two rows of it honestly. Publishing a six-row table with four guessed entries would be worse than useless on a page whose entire purpose is telling you which host to buy.
It also asked for the request wording that gets approved at each provider, plus the account-age and spend conditions they apply. We have Hetzner’s published description of its process and nothing more. We have not submitted an unblock request anywhere, so we don’t know what gets approved, what gets refused, or what thresholds exist — and we’re not going to invent a template, because a page that coaches people on phrasing for bypassing anti-abuse controls is a page that helps spammers more than it helps you.
A note on the test itself: a blocked result means the connection did not complete within the timeout. That’s consistent with a provider block but not proof of one — a transient network fault looks identical in a single run. The signature to trust is the pattern: 25 failing while 587 succeeds, repeatedly, from the same host.
What we did not do: run a mail server, send a message, configure SPF/DKIM/DMARC, test any relay service, or measure deliverability.
The host links above are affiliate links. The article’s main recommendation is to use a third-party sending service we earn nothing from, and it tells you not to buy the most expensive option on the list for this purpose.
FAQ
Why is port 25 blocked on my VPS?
Because your provider blocks it by default, to stop compromised servers sending spam. Test with the two commands above: if 25 fails and 587 succeeds, it’s the provider, not your firewall.
How do I know if it’s my firewall or my host?
Your own firewall doesn’t distinguish between outbound ports 25 and 587 unless you told it to. If 587 works and 25 doesn’t, the block is upstream.
Does DigitalOcean block port 25?
Yes — and also 465 and 587, on all Droplets by default, per its own documentation. It recommends using a third-party email service rather than self-hosting mail.
Does Hetzner block port 25?
Yes, along with 465. Port 587 is open with no request needed. Unblocks are granted case by case, and the rules are enforced per account rather than per server.
Can I get port 25 unblocked?
At providers that allow it, yes — by describing a specific legitimate use case. Hetzner decides case by case. There’s no magic wording, and any “template that always works” is nonsense.
What’s the alternative to port 25?
Relay through a third-party sending service on port 587 with authentication. They own the IP reputation and DKIM signing, which is the genuinely hard part of email delivery.
Do I actually need port 25?
Only if you’re receiving mail on that server or running a mail server deliberately. For sending transactional email, a relay on 587 is both easier and more deliverable.
