If port 25 is blocked, can't I just send to the recipient on port 587 instead?

No, and this is the single most common misunderstanding. Ports 587 and 465 are submission ports — they belong to *your* outbound mail server (or your provider's smarthost), and they require you to authenticate before sending. The recipient's mail server, the one your domain's MX points at, only listens for incoming mail on port 25. There's no 587 to deliver to on the receiving side. So when your network blocks outbound 25, the fix isn't a different port to the same destination — it's to hand your mail to an authenticated relay on 587 or 465, and let that relay deliver onward over 25 from a network that's allowed to.

Why do ISPs and cloud providers block port 25 in the first place?

Because port 25 was designed for server-to-server relay with no authentication, and for years that made compromised home PCs and rented VMs the perfect spam cannons. A botnet machine could open port 25 to any mail server in the world and inject mail directly. Blocking outbound 25 from consumer and cloud IP ranges kills that abuse at the source. AWS blocks it by default on EC2 and Lambda and only lifts it on request; Google Cloud blocks outbound 25 to external destinations with no removal process at all. It's not a misconfiguration — it's policy.

How do I tell if it's my outbound connection or my inbound mail server that's blocked?

They're two different problems with two different fixes. Outbound: you're trying to *send* and connections to remote port 25 time out — test with `telnet smtp.gmail.com 25`; if it hangs but port 587 connects, your network blocks outbound 25. Inbound: other servers can't *deliver to you*, which means port 25 on your own mail server is firewalled or your MX is wrong — and you can't move inbound mail to 587 because the sending world only knows to reach you on 25. Figure out which direction is failing before you change anything.

Views: 19

SMTP Port 25 Blocked: Why It Happens and the Fix

SMTP port 25 blocked usually means your ISP or cloud host bars outbound mail. Tell the cases apart and move to 587/465 in 4 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Mail won’t leave. Your application or server tries to send, the connection to a remote mail server on port 25 just hangs and times out, and everything points at the same thing: port 25 is blocked. The question is who blocked it, and which port 25 — yours or theirs.

Symptoms

Outbound SMTP to remote servers times out on port 25, while DNS and the web work fine.
telnet smtp.gmail.com 25 hangs with no banner; the same test on port 587 connects instantly.
Your app logs show “connection timed out” reaching MX hosts, never “connection refused.”
It started when you moved the workload to a cloud VM (AWS, GCP) or a home/office ISP connection.

What “Port 25 Blocked” Actually Means

Port 25 is the original SMTP port, and it’s for server-to-server relay — one mail server handing a message to the next. In SMTP’s original design it required no authentication, which is exactly why it became spam’s favorite door: a compromised machine could open port 25 to any mail server on earth and inject mail directly. So networks that have no business running a mail server — residential ISP ranges, cloud compute — block outbound port 25 by default to cut off that abuse.

This is where people get stuck. The fix for a blocked outbound 25 is not to use port 587 to reach the recipient. Submission ports — 587 (RFC 6409, which mandates SMTP AUTH) and 465 (implicit TLS, reinstated by RFC 8314 in 2018) — are for talking to your own outbound server or a provider’s smarthost, with authentication. The recipient’s server, the one your MX record advertises, only accepts incoming mail on 25. So you authenticate to a relay on 587/465, and the relay — running on a network that’s allowed to — does the final delivery over 25.

Top 3 Causes

Cloud provider blocks outbound 25 by default — AWS blocks port 25 on EC2 and Lambda for accounts not on an allowlist, removable only via a request form. Google Cloud blocks outbound 25 to any external destination and offers no removal process — their guidance is to send through a partner relay (SendGrid, Mailgun, and the like). If you spun up a VM and direct sending stopped working, this is almost certainly it.
Residential or office ISP blocks outbound 25 — Consumer ISPs have blocked outbound 25 for two decades to stop infected machines from spamming. You can run a mail client, but you cannot deliver mail directly from that connection. The fix is the same: authenticated submission through a smarthost.
Inbound 25 to your own server is firewalled — The mirror image. You’re trying to receive, but a host firewall, security group, or upstream filter drops inbound 25, so the sending world can’t reach you. This is not the same problem as outbound blocking, and you cannot work around it by moving to 587 — incoming mail only arrives on 25.

Diagnose with DechoNet

Port Check tests whether port 25 (and 587, 465) is reachable on a given host from outside your network. Point it at your own mail server to confirm inbound 25 is open; the result tells you the receiving side independent of your local firewall.
Email Check reads your MX records and mail setup, so you can confirm where mail is supposed to be delivered before you chase a port that may not be the real fault.
DNS Check verifies the MX records themselves — a missing or wrong MX looks like a delivery failure but has nothing to do with port 25.

Resolution Checklist

Establish the direction: are you failing to send (outbound) or failing to receive (inbound)? They have different fixes.
For outbound: test with telnet smtp.gmail.com 25 versus port 587. If 25 hangs and 587 connects, your network blocks outbound 25 — stop trying to fix 25.
Switch sending to authenticated submission: configure your app or server to relay through a smarthost on 587 (STARTTLS) or 465 (implicit TLS) with SMTP AUTH credentials.
On a cloud VM, either request the port 25 block be lifted (AWS) or route all outbound mail through a relay service (GCP has no opt-out).
For inbound: confirm port 25 is open on your mail server from the outside, and that your MX records point at the right host. Inbound mail cannot move off port 25.

When to Escalate

If you’ve moved to authenticated submission and mail still won’t leave a cloud VM, escalate to the provider — on GCP especially, direct port 25 egress is a network-level policy you cannot override, and a relay is the only path.
If inbound port 25 is open and MX is correct but mail still bounces, the problem has moved past connectivity into authentication or reputation (SPF, DKIM, PTR, blacklisting) — those are separate diagnoses.