Port 25 is the only port used for server-to-server SMTP delivery. Nothing else substitutes for it: when a receiving domain publishes an MX record, senders connect to that host on 25. Ports 587 and 465 are *submission* ports — authenticated clients handing mail to their own provider — and no receiving MX will accept anonymous mail on them. That distinction is the whole reason a blocked port 25 is such a hard problem: you cannot simply switch ports and carry on.
Why do providers block outbound 25?
Because a compromised machine on a consumer or cloud network sending directly to receivers is the classic spam delivery path. Blocking outbound 25 at the network edge removes it entirely, costs almost no legitimate user anything (normal mail clients use 587 or 465 to their own provider), and protects the provider's address space from ending up on blocklists. The practice is old enough to have its own BCP, and it is close to universal on residential broadband.
Cloud and VPS providers apply their own variations, and these change, so verify against your provider's current policy rather than anything you read second-hand:
- Residential and mobile ISPs almost always block outbound 25 outright, with no route to an exception. Their address space is also blanket-listed in dynamic-IP blocklists, so even an unblocked connection would rarely be accepted.
- Some large clouds block outbound 25 permanently on standard accounts, with no unblock process at all — the documented answer is to use a partner relay service.
- Others throttle or block it by default but will lift the restriction on request, usually once the account has a payment history and you can name the sending hostname and reverse DNS.
- Many VPS hosts block it for new accounts and open it after a short ageing period or a support ticket describing the use case.
- Almost nobody blocks inbound 25, because that would break receiving mail. Inbound and outbound are separate rules and separate tests.
Outbound and inbound are different problems
This is where most troubleshooting goes wrong. "Port 25 is blocked" describes two entirely unrelated failures, and the test for each runs from a different place.
| Direction | What it means | Symptom | Test from |
|---|---|---|---|
| Outbound 25 | Your server → the recipient's MX | Mail queues locally and never leaves; logs show connection timeouts to remote MX hosts | The server itself, via SSH |
| Inbound 25 | The internet → your MX | Senders get "connection timed out" or delayed-delivery warnings; your logs show nothing at all | Any host outside your network |
| Outbound 587/465 | Your app → your relay provider | Application cannot send through a smarthost | The server itself |
How to test outbound port 25
Run this from the machine that is supposed to be sending, over SSH. Pick a well-known MX host as the target — Google's inbound gateway is a reliable one.
# Simple reachability check with a 5-second timeout
nc -zv -w 5 gmail-smtp-in.l.google.com 25
# Connection to gmail-smtp-in.l.google.com port 25 [tcp/smtp] succeeded!
# Better: actually speak SMTP and read the banner
(printf 'EHLO test.example.com\r\nQUIT\r\n'; sleep 2) | nc -w 5 gmail-smtp-in.l.google.com 25
# 220 mx.google.com ESMTP ...
# 250-mx.google.com at your service, [203.0.113.25]
# 250-STARTTLS
# telnet works too if nc is not installed
telnet gmail-smtp-in.l.google.com 25
# Find a real MX host for any domain to test against
dig +short MX example.comRead the *shape* of the failure, not just the fact of it:
- A `220` banner within a second or two — outbound 25 is open. Note the IP the receiving server echoes back in the
250-line; that is your real sending address, and it is what needs a PTR record. - Hangs until the timeout with no output — packets are being silently dropped. That is a firewall or provider filter, and it is what an outbound 25 block looks like.
- "Connection refused" immediately — something answered and said no. That is usually a local firewall rule or a null route, not an upstream provider block; upstream filters drop rather than refuse.
- Banner arrives but says `554` or names a blocklist — port 25 is fine and your IP's reputation is the problem. Check it with the Email Blacklist Check.
- Works to one host, times out to another — not a port block. Look at IPv6: if the target has an AAAA record and your v6 path is broken, the connection stalls before SMTP starts.
How to test inbound port 25
Inbound has to be tested from outside your network — running nc localhost 25 on the mail server proves only that the daemon is listening, not that anything on the internet can reach it. Use a host on a different network, or use our tester.
Test the hostname your MX record actually points at, not your domain. Get it from the MX Lookup first — a surprising number of "inbound port 25 is blocked" tickets turn out to be an MX record pointing at a hostname with no A record, or at a Cloudflare-proxied name that resolves to the HTTP edge. For a single-port check against an arbitrary host, the Port Checker does the same job on any TCP port.
What to do when outbound 25 is blocked
Option 1: relay through a smarthost on 587
The standard answer. Instead of delivering directly to each recipient's MX, your server authenticates to a relay — your mailbox provider, a transactional mail service, or another server you own — and hands off everything on port 587. The relay does the port 25 delivery from its own IPs, which already have reverse DNS and an established reputation. This also sidesteps the PTR problem entirely, since the connecting IP is no longer yours.
# Postfix: relay everything through an authenticated smarthost
postconf -e 'relayhost = [smtp.example.net]:587'
postconf -e 'smtp_sasl_auth_enable = yes'
postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
postconf -e 'smtp_sasl_security_options = noanonymous'
postconf -e 'smtp_tls_security_level = encrypt'
# Credentials file — one line, then hash it
echo '[smtp.example.net]:587 [email protected]:APP_PASSWORD' > /etc/postfix/sasl_passwd
chmod 600 /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd
systemctl reload postfix
# Watch the next delivery attempt
tail -f /var/log/mail.logThe square brackets around the hostname matter: they tell Postfix not to look up an MX record for the relay and to connect to the A record directly. Confirm the relay is reachable before you reload, with nc -zv -w 5 smtp.example.net 587.
Option 2: ask the provider to unblock it
Worth trying if you genuinely need direct delivery — you are running the MX for a domain, or you have volume that makes a relay expensive. Providers that will lift the block generally want the same things: an account in good standing, the specific IP, the hostname you will use for HELO, and a description of the mail you send. Set the reverse DNS *before* you ask; a request for an IP with no PTR reads as a spammer's request. See Set a PTR Record on Your VPS.
Option 3: accept that you only need inbound
If the box is a receiving mail server, outbound 25 being blocked may not matter much — except for bounces and autoresponders, which are outbound delivery to arbitrary MX hosts and will queue forever. Relay those through a smarthost even when everything else is inbound.
For the difference between the three SMTP ports and when each is correct, read Port 465 vs 587 vs 25. Once mail is flowing again, check the rest of the sending posture with the Email Deliverability Test and confirm reverse DNS with the Reverse DNS Lookup.