DigitalOcean blocks ports 25, 465, and 587. Here is what to do.

If your email suddenly stopped sending from a DigitalOcean droplet, and every SMTP connection just times out, there is a good chance nothing is wrong with your mail server, your credentials, or your application. DigitalOcean blocks outbound SMTP on ports 25, 465, and 587 on droplets. It is their standard anti-spam policy, documented here, and it applies whether you are running a spam operation or a perfectly legitimate newsletter to people who asked for it.

This guide walks through confirming that the block is what you are hitting, getting sending again the same day, and asking DigitalOcean to lift it.

Why it can break after months of working

The block is not always there from day one, which is the part that confuses people. It can arrive on an account that has been sending fine for months, usually because something made the droplet’s traffic look suspicious.

One pattern we have seen: a mail server goes down in the middle of a send, and the sending machine spends a day retrying connections against the dead host. To an abuse detection system, a droplet making thousands of failed outgoing mail connections looks exactly like a spam bot, and the block follows.

If your sending stopped suddenly, check your inbox for a notice from DigitalOcean around the time it broke. They usually email when they restrict an account.

Step 1: Confirm the block from your own server

Run these on the machine that sends your email, not on your mail server and not on your laptop. If your app runs in Docker, run them inside the container.

First, check that the failure is not specific to your mail server. Test your own server, then any well-known one:

nc -vz mail.yourserver.com 587
nc -vz smtp.gmail.com 587

If both time out, the problem is on the sending machine’s side. Your mail server, credentials, and DNS are all off the hook.

Next, rule out your own firewall:

ufw status verbose
iptables -S OUTPUT

If those show no deny rules on outbound traffic, test which ports actually get out. portquiz.net accepts connections on every port, which makes it perfect for this:

nc -vz portquiz.net 587
nc -vz portquiz.net 465
nc -vz portquiz.net 2525

If 587 and 465 time out while 2525 succeeds, you have your answer. The provider is blocking the standard mail ports at the network level, and nothing you change in your application or on your mail server will fix it.

Step 2: Get sending again on port 2525

Port 2525 is the industry’s unofficial spare mail port, and provider blocks almost never cover it. If you run your own mail server, you can have it listen there alongside the standard ports.

On a cPanel/WHM server:

1. In WHM, open Exim Configuration Manager, then the Advanced Editor. Add 2525 to daemon_smtp_ports, so it reads 25 : 465 : 587 : 2525.
2. Open TCP 2525 in the server firewall (CSF, if you have it).
3. In Broadcast, edit the email server and change the port to 2525.
4. Send yourself a test broadcast.

On a plain Postfix server, add a second listener in master.cf:

2525      inet  n       -       y       -       -       smtpd

then open the port in the firewall and reload Postfix.

If you send through an email service provider

The big ESPs know all about blocks like this one, and most of them listen on an alternate port for exactly this reason. For the providers Broadcast supports directly:

Note that Amazon SES and Resend use 2587 rather than 2525, so test the right one from your droplet (nc -vz portquiz.net 2587). In Broadcast, just edit the email server and change the port; everything else stays the same.

There is an even simpler way out for four of these. Amazon SES, Postmark, SendGrid, and Mailgun can all send through their APIs instead of SMTP in Broadcast: edit the email server and switch the delivery method. API delivery goes over HTTPS on port 443, which no host blocks, and it gives you better error reporting than SMTP failure codes. The port problem disappears entirely.

Step 3: Ask DigitalOcean to lift the block

DigitalOcean’s documentation offers no way to remove the block, but in practice people do get ports 465 and 587 opened by filing a support ticket, especially on accounts with some history and a clear use case. Sometimes it takes a couple of days. Sometimes they say no. Port 25 they essentially never unblock.

Two things make the ticket stronger:

• Explain what you send and to whom. A newsletter with opt-in subscribers going through an authenticated relay is a very different request from an open mail server.
• If the block appeared after an incident, say so. If your mail server had an outage and your droplet retried against it for hours, explain that and ask for the block to be reviewed as a false positive rather than as a favor.

File the ticket, but switch to 2525 while you wait. If the ports open up later you can move back to 587, or just stay on 2525. Either works.

The symptom to remember

The signature of a provider-level port block is that everything times out and nothing tells you why. No authentication error, no rejection, no bounce. Just silence. If your sending broke with no error message anywhere and your mail server checks out fine from other networks, test the ports before you touch another setting.

Broadcast is self-hosted email marketing software that sends through your own SMTP server or provider account. More on configuring email servers in the setup documentation, and if you run your own stack, Knowing when your self-hosted server goes down pairs well with this one.