You SSH into your VPS, fire off a test email from your PHP script or a plain sendmail command, and — nothing. No bounce, no error in the application log, just a message that never arrives. Check the mail queue and it's sitting there stuck, or the connection times out after thirty seconds with something like Connection timed out in the mail log. Nine times out of ten on a fresh VPS, this isn't a WordPress problem, a DNS problem, or even a Postfix misconfiguration. It's a blocked port.

The Symptom

A few patterns make this one easy to recognize once you know what to look for:

  • Local mail (server to server on the same box, or webmail-to-webmail on the same host) works fine, but anything going out to Gmail, Yahoo, or a client's inbox never lands.
  • mailq shows messages sitting in the queue for hours, retrying and failing.
  • /var/log/maillog or /var/log/mail.log shows entries like connect to mx.google.com[...]:25: Connection timed out repeated over and over.
  • A quick manual test confirms it outright — more on that below.
  • It usually shows up right after provisioning a new VPS, or after moving from shared hosting (where the host manages outbound mail for you) to your own unmanaged server.

Why It Happens

Most cloud and VPS providers block outbound traffic on port 25 by default on new servers. This isn't a bug and it isn't specific to SkyServer — it's an industry-wide anti-spam measure. Port 25 is the classic port spam botnets use to blast mail directly from compromised servers, and providers that don't block it end up with their entire IP ranges landing on real-time blacklists within days. So the block goes on by default, and legitimate customers who genuinely need to send mail have to either request it lifted or route around it.

There's a second, related cause worth ruling out at the same time: even where port 25 is open, some destination mail servers reject connections from IPs with no reverse DNS (PTR) record, or from IP ranges with a poor sending reputation. That's a different problem with a different fix (a missing or mismatched PTR record, which we've covered separately), but it produces a similar symptom — mail that leaves your queue and never arrives — so it's easy to mix the two up.

Confirm It's Actually a Port Block

Before changing any config, prove the diagnosis. From the VPS, try connecting straight to a known mail server on port 25:

telnet gmail-smtp-in.l.google.com 25

or, if telnet isn't installed:

nc -zv gmail-smtp-in.l.google.com 25

Two outcomes tell you two different things:

ResultWhat it means
Connection hangs, then times out after ~30-60 secondsOutbound port 25 is blocked at the network level — either by your provider or an upstream firewall.
Connection refused immediatelySomething local is closing the port — check your own firewall (UFW, firewalld, CSF) first.
Connection succeeds, mail still doesn't arrivePort 25 is open; the problem is reputation, PTR records, or SPF/DKIM — not a block.

If you get the timeout, you've confirmed it. Now you've got two real options.

Fix 1: Ask for Port 25 to Be Unblocked

This is the right move if you genuinely need to run your own full mail server — Exim, Postfix, or Sendmail delivering directly to recipient mail servers rather than through a third party. Open a support ticket with your hosting provider and ask specifically for outbound port 25 to be unblocked on your VPS's IP. Expect to be asked a few things:

  • What the server will be used for (a legitimate site, an application sending transactional mail, etc.)
  • Confirmation you're not planning to send bulk or unsolicited mail
  • Sometimes basic KYC details, since providers are cautious about exactly the abuse this block prevents

Once it's unblocked, you'll still want a matching PTR record for your VPS's IP pointing back to your mail hostname, and SPF/DKIM/DMARC records set correctly — without those, an open port 25 just gets you a different kind of rejection at the far end.

Fix 2: Route Through an SMTP Relay (Usually the Better Option)

If you don't strictly need to run your own outbound MTA — and most sites don't — relaying through a dedicated transactional email service is faster to set up, doesn't depend on a support ticket, and comes with reputation management already built in. Providers like SendGrid, Mailgun, Amazon SES, and Brevo all accept mail on port 587 or 2525, which typically isn't blocked, and handle delivery to Gmail/Outlook/Yahoo on your behalf.

Here's the Postfix side of it, assuming you're relaying through SendGrid as an example:

apt install postfix mailutils libsasl2-modules -y

# /etc/postfix/main.cf
relayhost = [smtp.sendgrid.net]:587
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_use_tls = yes
smtp_tls_security_level = encrypt
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
# /etc/postfix/sasl_passwd
[smtp.sendgrid.net]:587 apikey:YOUR_SENDGRID_API_KEY
postmap /etc/postfix/sasl_passwd
chmod 600 /etc/postfix/sasl_passwd*
systemctl restart postfix

Test it with:

echo "Test message body" | mail -s "Relay test" you@example.com

Then watch /var/log/mail.log for a status=sent line. If your app sends mail through PHP's mail() function or a framework's default mailer, this Postfix relay setup covers it transparently — nothing in the application needs to change, since it's still handing mail to the local Postfix, which now forwards it onward through the relay instead of trying (and failing) to deliver it directly.

Fix 3: App-Level SMTP (No Server Config at All)

If it's really just one application — a WordPress site, say — that needs to send mail, and you don't want to touch Postfix or your VPS's mail stack at all, skip the server-wide relay and configure SMTP directly in the app instead. On WordPress, a plugin like WP Mail SMTP pointed at the same SendGrid/Mailgun/SES credentials does the job without ever touching port 25. This is the lighter option when only one site on the box needs outbound mail.

Prevention

  • Set up SPF, DKIM, and DMARC for your sending domain regardless of which fix you use — a relay service can deliver the mail, but a receiving server can still spam-fold it without proper authentication.
  • Keep API keys and SASL passwords out of version control; store them the way you'd store any other production credential.
  • Monitor the mail queue (mailq) periodically or set up an alert for a queue that isn't draining — a growing queue is the earliest sign something changed upstream.
  • If you switch relay providers later, remember to update both main.cf and the sasl_passwd map, then re-run postmap — a stale password file is a common cause of relays quietly breaking after a credential rotation.
  • Don't use a single relay account to send high volumes of cold or unsolicited mail. That's exactly the pattern that gets accounts suspended, and it's a different problem from the one this article solves.

Frequently Asked Questions

Is port 25 blocked on all SkyServer VPS plans?

Outbound port 25 ships blocked by default on new VPS instances as a standard anti-abuse measure. It can be unblocked on request through a support ticket once we've confirmed the use case, or you can sidestep it entirely with an SMTP relay on port 587.

Will an SMTP relay work with cPanel's Exim on a VPS?

Yes. Exim can be configured with a remote smarthost router the same way Postfix uses relayhost — you point it at your relay provider's host and port and supply the same SASL-style credentials, and Exim hands outbound mail off to the relay instead of attempting direct delivery.

Why does mail work between accounts on the same server but not to Gmail?

Local delivery never leaves the box, so it's not affected by an outbound port 25 block. The moment your server has to connect out to another mail server's port 25, the block (if there is one) kicks in — which is exactly why this symptom pattern is such a strong signal.

Do I still need a PTR record if I use a relay service?

No, not for the relay's own delivery — the relay sends from its own IPs, which already have PTR records and reputation set up. You only need a PTR record on your VPS's IP if you're sending directly from it after getting port 25 unblocked.

How do I know if the timeout is my firewall and not the provider's block?

Temporarily check your local firewall rules (ufw status, firewall-cmd --list-all, or your CSF config) for an outbound rule on port 25. If outbound 25 is already allowed locally and you still get a timeout connecting to an external mail server, the block is upstream at the network level, not on the VPS itself.