Why the block exists
Port 25 is the port mail servers use to talk to each other. It is also the port that a compromised virtual machine uses to send spam, which is why nearly every cloud provider blocks outbound traffic on it for new accounts.
The block is about protecting the provider’s IP address reputation. If addresses in their range start sending spam, legitimate mail from every other customer in that range starts landing in junk folders. Blocking by default is the cheapest way to prevent that.
Blocked, restricted and open
Providers fall into three broad groups, and the difference matters if outbound mail is part of your plan.
- Hard blocked with no exception process. Google Cloud blocks port 25 on Compute Engine outright, and Azure blocks it on most subscription types.
- Blocked with a request process. AWS, DigitalOcean and Linode restrict it initially and will consider unblocking once an account has some history and a stated legitimate use.
- Generally available. Hetzner, OVHcloud and Kamatera permit outbound mail subject to their acceptable use policies, which makes them practical hosts for a mail server.
Ports 587 and 465 are a different question
The block is usually specific to port 25. Ports 587 and 465, which clients use to submit authenticated mail to a relay, are commonly left open.
That distinction is the basis of the most common solution: run your application anywhere, and hand outbound mail to a relay over port 587 rather than delivering it yourself on port 25.
Using a relay instead
For most applications a relay is the better answer regardless of whether port 25 is available. A dedicated sending service handles the parts of email that are genuinely hard: IP warming, reputation management, bounce and complaint handling, and authentication.
Amazon SES is the usual choice on cost grounds at volume. New SES accounts start in a sandbox with low limits and restricted recipients until production access is granted, which is worth knowing before you plan around it.
If you do run your own mail server
Having port 25 open is necessary but nowhere near sufficient. Deliverability depends on things that have nothing to do with the port.
- Set up SPF, DKIM and DMARC records for the sending domain.
- Configure forward and reverse DNS so the IP address resolves to your mail hostname and back.
- Check the IP against the major blocklists before you rely on it, since addresses are recycled between customers.
- Warm the address up gradually rather than starting at full volume.
- Handle bounces and unsubscribes properly, because complaint rate drives reputation.
Choosing on this basis
If outbound mail is central to the workload, pick the provider accordingly rather than fighting a block later. Hetzner and Kamatera are the straightforward options for self-hosted mail; Amazon SES is the straightforward option for application email at volume.
Related cloud accounts
This guide applies across providers. The cloud account catalogue lists every platform with its configurations and prices, and the comparison table puts them side by side.
Further reading
- Rotating Access Keys Without Breaking Production
- Google Workspace Accounts: What You Get and How to Choose a Configuration
- DigitalOcean vs OVHcloud: Which Cloud Account Should You Buy?
- Monitoring: Knowing Before Your Users Tell You
Frequently asked questions
AWS operates a request process and considers requests case by case. It is not automatic, and there is no guarantee it will be granted.
Usually not. The restriction typically applies to port 25 specifically, which is why relaying over 587 is the common workaround.
For most applications, no. A relay handles deliverability better than a self-hosted server unless you have a specific reason to run one.
