Why Port 25 Is Blocked on Your VPS and What to Do About It

You installed Postfix, DNS looks right, and outbound mail still goes nowhere. Nine times out of ten the mail server isn't broken — the provider's network is quietly dropping every outbound connection on port 25 before it leaves the datacenter.

This is deliberate, not a bug you introduced. AWS, DigitalOcean, Google Cloud, Azure, Linode and most other cloud and VPS providers block outbound port 25 by default on new accounts, specifically to stop their IP ranges from becoming spam cannons. The fix is either a request to your provider or a relay that never touches port 25 in the first place.

Why do cloud providers block port 25?#

Port 25 is the protocol port SMTP servers use to hand mail to each other directly, server to server, with no authentication required by the protocol itself. That's exactly what makes it useful to spam operations: spin up a cloud instance, blast mail from a fresh IP, abandon the instance before the IP gets blocklisted, repeat.

M3AAWG, the industry group that coordinates anti-abuse policy among ISPs and mailbox providers, has recommended blocking outbound port 25 by default on dynamic and cloud IP ranges for years. Every major provider follows some version of that guidance because the alternative is their entire IP block getting blocklisted by Spamhaus and similar services — which would break mail delivery for every other customer sharing that range, not just the spammer.

So the block isn't about your server specifically. It's a standing default applied to the IP range you were assigned, and it stays in place until you ask for an exception or route around it.

Before you start: confirm it's actually port 25#

Don't assume. A stalled outbound connection can also be a firewall rule you set yourself, a missing PTR record, or an ISP-side block if you're on a home connection rather than a real VPS. Rule out the provider block first with a direct test.

• From the VPS itself, run: `telnet gmail-smtp-in.l.google.com 25` (or any known mail server). A hang with no response, versus an immediate refusal, points to a network-level block rather than a misconfigured server.
• Check port 587 and 465 the same way — most provider blocks are scoped to port 25 only, leaving submission ports open.
• Check your provider's own status/abuse pages first; several publish the exact policy and request form rather than making you find support.

Steps: requesting a port 25 exception#

1. 1

   Confirm you actually need outbound port 25

   If you're only sending transactional or bulk mail — not running server-to-server SMTP relay yourself — a smart host (below) is usually less work than an exception request and gets you sending today.

2. 2

   Find the provider's specific unblock process

   AWS requires an EC2 support case with justification and expected volume. Google Cloud requires a request through the Cloud Console. DigitalOcean and Linode have web forms tied to your account. None of these are automatic — expect a manual review, sometimes 24–72 hours.

3. 3

   Set up reverse DNS (PTR) before you ask

   Most providers want a matching PTR record for your instance's IP before they'll even consider lifting the block, since a missing PTR is itself a strong spam signal to receiving mail servers. Set this in your provider's DNS panel, not your domain's.

4. 4

   Publish SPF, DKIM and DMARC before you send anything

   This isn't part of the unblock request, but skipping it means your first real send gets junked anyway. Do it while you're waiting on the support ticket.

5. 5

   Test with a small, real send once approved

   Send to a mailbox you control at Gmail and Outlook first. Check the raw headers for SPF/DKIM pass before you consider the exception 'done'.

Platform differences: who blocks port 25 and how you unblock it#

What to do when the provider says no#

Some providers, Google Cloud most explicitly, will decline the exception outright and tell you to use an email service instead. That's not a dead end — it's the more common outbound path anyway, even for people who never hit a block.

A smart host is an authenticated relay that accepts your outbound mail on port 587 (or 465) with a username and password, then delivers it onward for you using its own IPs, which are already warmed up and not on your provider's blocked range. Your mail server never opens a direct port 25 connection to the recipient at all.

Setting up a smart host with Postfix#

If you're running Postfix, the relay config is a handful of lines in `main.cf`. You add the relay host, tell Postfix to authenticate against it, and point at a password file.

A faster way to send reliably without managing SMTP at all#

Requesting an exception, warming an IP, and keeping SPF/DKIM/DMARC aligned is real ongoing work even after the first send succeeds — bounce handling, reputation monitoring and blocklist checks don't stop once the ticket closes. If what you actually need is mail that lands, not a self-hosted SMTP stack to maintain, that's a narrower problem than the one port 25 makes you solve.

AI Emaily is an AI-native email client — it sits on top of Gmail, Outlook, IMAP and other providers you already have deliverability sorted on, rather than asking you to run your own outbound mail server. It triages, drafts and can send with approval before anything goes out, so the sending infrastructure problem doesn't come up at all. We build AI Emaily. If you're evaluating this as a founder or small team managing your own inbox rather than running mail infrastructure for a product, a 7-day free trial on the Pro plan (card required, $0 if you cancel before day 7) is on aiemaily.com — worth a look if the self-hosted SMTP path above sounds like more plumbing than you signed up for.