Mail not sending from your VPS: port 25 and what to do instead

The symptom, in one line

The site's contact form doesn't send the confirmation email, or PHP's mail() doesn't throw an error but the message never arrives. It's not that the site is broken: it's the outbound connection from the server to a mail server that simply never gets off the ground, and the usual cause is that your provider has blocked outbound port 25.

The quickest check: one command, thirty seconds

Before touching any configuration, check whether the port is open. On Ubuntu 24.04, from the command line:

nc -vz -w 5 smtp.gmail.com 25

If the port is open, nc reports a successful connection almost instantly. If it's blocked by the provider, the command hangs for the full five-second timeout and then reports that the connection failed, with no response at all from the remote server (no "220" banner). This is what distinguishes a network block from a configuration problem: if the issue were in your Postfix setup or your local firewall, the connection would usually be refused immediately ("connection refused"), rather than hanging until the timeout.

Repeat the same test on port 587 and port 465:

nc -vz -w 5 smtp.gmail.com 587
nc -vz -w 5 smtp.gmail.com 465

If port 25 stays silent and 587 responds, you've got both the diagnosis and the fix from the same command.

Most common cause: the provider blocks port 25 by default

Almost all low-cost VPS providers block outbound SMTP traffic on port 25 to stop their servers being used for spam. Policies vary widely between providers, and they're often not clearly flagged at the point of purchase.

On DigitalOcean the block is the strictest: according to the official documentation, "Your best bet is to either: Reach out to DigitalOcean support and ask if they can review your account and unblock it (they don't always do it, but worth a try), Or use a service like smtpfa.st, SendGrid, Mailgun, or Postmark". The official support page states that 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 and includes traffic passing through a Reserved IP address. DigitalOcean's direct recommendation is to use a third-party email delivery provider rather than open a support ticket.

On Hetzner the block is temporary and less drastic: new installations have outbound port 25 blocked for the first 24–48 hours as an anti-abuse check, after which the port is unblocked automatically. If the block persists beyond 48 hours, you need to open a support ticket giving a legitimate use case. Several users also report that Hetzner requires you to have been a customer for at least a month and to have paid at least one invoice before it will action an unblock request via the dedicated form.

One thing many sysadmins only discover after hours of troubleshooting: port 587, the one used for authenticated submission, is often left open even when port 25 is blocked. It's always worth checking 587 before opening a ticket.

How to tell whether the problem is yours or the provider's

Look at the Postfix log. On Ubuntu with Postfix, according to the official Ubuntu Server documentation, Postfix sends all log messages to /var/log/mail.log, while errors and warnings are also written to /var/log/mail.err and /var/log/mail.warn. From the command line:

sudo tail -f /var/log/mail.err

If the log shows no attempt at all to connect outbound to the relay or destination server, the problem lies upstream, in the provider's network, not in Postfix. If instead the log shows a connection attempt that closes with "Connection timed out" after several seconds, that's the same symptom seen with nc: the port is blocked by the provider.

On cPanel with Exim, the equivalent log is /var/log/exim_mainlog; on Plesk, the panel changes the default Postfix log path from /var/log/mail.log to /var/log/maillog — if you look for the file in the wrong place it can seem to be missing even though mail is actually flowing.

The fix that almost always works: authenticated relay on port 587

Rather than chasing a port 25 unblock — which on some providers never arrives — the more stable route is to route all outbound mail through an authenticated sending service on port 587, using STARTTLS. The server no longer acts as a fully-fledged mail server: it simply hands the message off to an external relay, which then delivers it.

Configuration at the application level

If the application (WordPress, a CMS, a PHP script) sends mail directly via SMTP, you simply need to change the connection parameters: relay host, port 587, authentication with username and password, and STARTTLS encryption (not implicit SSL/TLS, which usually runs on port 465). Most WordPress SMTP plugins and libraries such as PHPMailer have these as separate fields: don't confuse "port" with "encryption type" — they're two different settings, and getting this wrong produces a different failure to a blocked port (usually an explicit rejection from the server, not a timeout).

Configuration at the system level (Postfix as a relay)

On Ubuntu 24.04 with Postfix, to route all local mail through an authenticated external relay you set the relayhost parameter in /etc/postfix/main.cf to point to the relay and port 587, along with the SASL credentials in a separate file (typically /etc/postfix/sasl_passwd), then reload the service:

sudo systemctl reload postfix.service

On cPanel with Exim, routing through a smarthost is configured via the "Exim Configuration Manager" in the panel, in the delivery routes section. On Plesk, the equivalent option is found in the mail server settings, where you can specify an external SMTP relay with authentication.

How to confirm it's fixed

After making the change, send a test message to an address you can check (a Gmail inbox of your own will do) and follow the log in real time:

sudo tail -f /var/log/mail.log

A successful delivery through the relay ends with a line containing status=sent and the remote server's response code. If instead you see lines with SASL authentication failed, the problem is no longer the port but the credentials you've entered: check the relay's username and password, not the network.

What to tell support if the block is on the provider's side

If, after testing with nc, port 25 does turn out to be blocked and you still want to request an unblock (this only makes sense if you're running an actual mail server, not just sending application notifications), your ticket should include: the machine or droplet ID, the domain you'll be sending mail from, a brief description of the intended use (e.g. "mail server for domain X, with reverse DNS configured"), and confirmation that you'll follow basic anti-spam practices (SPF, DKIM). Without these details, the ticket is almost always sent back asking for more information.

This guide is part of UptimeMag's series on recurring issues faced by server administrators: no SMTP protocol theory, just the right command for each cause.