SMTP port 25 blocked: "Connection timed out" on AWS, Azure, GCP, VPS

What it means

To deliver an email, your server connects to the recipient's mail server on port 25. If that connection never gets an answer, your network or hosting company is probably blocking outgoing port 25. Messages stay in the queue and are finally returned after several days.

The error usually looks like this, depending on the software:

connect to gmail-smtp-in.l.google.com[142.250.27.26]:25: Connection timed out
Error: connect ETIMEDOUT 203.0.113.50:25
SMTP ERROR: Failed to connect to server: Connection timed out (110)

"Timed out" (no answer at all) points to a block. "Connection refused" or a 5xx answer is a different problem on the other side.

Why it happens

Spammers like to rent cheap servers, so most providers block outgoing port 25 by default. Policies change, so check your provider's current documentation. At the time of writing:

• Amazon EC2 and Lightsail restrict outgoing port 25 by default. You can ask AWS to remove the limit with their request form, explaining your use. Amazon SES on port 587 or 465 is the alternative.
• Google Cloud (Compute Engine) blocks outgoing connections to port 25 on external addresses. Google recommends a mail service on another port.
• Microsoft Azure blocks outgoing port 25 for most subscription types; only some enterprise agreements can send directly. Microsoft recommends an authenticated relay.
• DigitalOcean blocks SMTP on Droplets by default; according to community reports, the block can include ports 465 and 587.
• Home and office internet connections usually block port 25 too. Residential IPs are also on blocklists, so direct sending from home rarely works anyway.

How to check

From the server itself, test port 25 to a big mail server, then a submission port:

nc -vz -w 5 gmail-smtp-in.l.google.com 25
nc -vz -w 5 smtp.gmail.com 587

If 587 connects and 25 times out, the block is on your network or provider, not at Google. Also check your own firewall (ufw status, iptables -L OUTPUT) and your cloud firewall or security group rules for outbound traffic.

On Postfix, postqueue -p lists stuck messages with the reason. Once you have a working route, send a test to the unique address on the Delivmail home page to check the whole path.

How to fix it

Option 1: ask the provider to unblock port 25

Some providers (AWS for example) accept a request. You usually need to explain what you send, set a reverse DNS name, and keep complaints low. Before you do this, read the own mail server checklist: a new cloud IP has no reputation.

Option 2: relay through a mail service on port 587

This is the usual fix. Your server sends to an email service (your mailbox provider or a transactional service) on port 587 with a login, and that service delivers on port 25 from its own reputable IPs. Many services also accept port 2525 or an HTTP API if 587 is blocked too. Postfix example, in main.cf:

relayhost = [smtp.your-provider.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

And in /etc/postfix/sasl_passwd:

[smtp.your-provider.com]:587   username:password

chmod 600 /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd
systemctl reload postfix

In an application (nodemailer, PHPMailer…), use the service's host with port: 587 and STARTTLS instead of a direct connection.

Then authenticate the relay

The relay sends from new IPs, so add it to SPF and enable its DKIM signing for your domain; see authenticate your domain in sending tools. Otherwise you will get an SPF fail: server not authorized.

Check that it is fixed

Flush the queue (postqueue -f) and watch the log: you should see status=sent with your relay host. Send a new Delivmail test and confirm that SPF, DKIM and DMARC pass for the relay, then resend to the address that failed.