Port 25 and Cloud Email Sending: Why Providers Restrict It
Why cloud providers restrict outbound port 25 on new accounts, what ports 587 and 465 are for, how authenticated relays and Amazon SES replace direct delivery, and how providers handle lift requests.
Almost every cloud and VPS provider restricts outbound TCP port 25 on new accounts, and the first time an engineer sees a connection to a remote mail server time out it looks like a bug. It is not. The restriction is a deliberate anti-abuse control, and the correct response is to route application mail through an authenticated relay on a submission port or through a transactional email service. This article explains what port 25 is for, why providers limit it, the compliant alternatives, and how a provider decides whether to lift the restriction.
What port 25 actually does
SMTP uses three well known ports, and they have different jobs. Port 25 is the port mail servers use to talk to each other. When your server wants to deliver a message to example.com, it looks up the MX record, opens a connection to that host on port 25, and hands over the message. This is unauthenticated server to server transfer, and any machine on the internet can attempt it.
Port 587 is the submission port. A mail client or an application connects to a server it has an account with, authenticates with a username and password, upgrades the connection with STARTTLS, and hands the message to that server for onward delivery. Port 465 does the same job over a connection that is encrypted from the first byte (implicit TLS). Both submission ports require authentication, which is exactly why providers leave them open: a compromised virtual machine cannot use them without valid credentials for a relay.
So the real question is whether your server needs to deliver mail directly to other people’s mail servers, or only needs to hand mail to a relay. For nearly every application, the answer is the second one.
Why providers restrict outbound port 25
Cloud IP addresses are cheap to obtain, easy to automate, and shared across many customers over time. That combination makes them attractive to spammers: a stolen card opens an account, a script launches servers, and each one sends mail on port 25 until the provider notices. Compromised servers do the same thing without the owner knowing, usually after a weak SSH password or an unpatched web application is exploited.
The damage lands on the provider’s address space. Blocklist operators such as Spamhaus track abuse by IP and by network range, and large mailbox providers keep their own reputation data. When one address sends spam, the surrounding range can be listed too, and the next customer to receive that address inherits the poor reputation. Restricting port 25 by default breaks the automated abuse pattern, protects the reputation of the whole range, and cuts the volume of abuse complaints the provider’s abuse desk has to handle.
Providers in the VPS and developer cloud segment, including DigitalOcean, Linode, Hetzner, OVHcloud, Kamatera, and BinaryLane, each publish their own position on outbound mail in their documentation or terms. The wording differs, but the pattern is the same: port 25 is limited or closed on new accounts, submission ports stay open, and any change is at the provider’s discretion.
The compliant alternatives
The first alternative is an authenticated relay. Your application or a local mail transfer agent connects on port 587 or 465, authenticates, and lets the relay deliver on port 25 from its own well managed IP space. Amazon SES exposes an SMTP interface for exactly this purpose, with SMTP credentials generated from an IAM user, and it also offers an API for applications that prefer HTTPS calls. Google Workspace offers an SMTP relay service for organisations that already run Workspace mailboxes. Other transactional providers work the same way.
The second alternative is to let the service handle the whole sending path. The application calls the provider’s API with the recipient, subject, and body, and the provider manages queues, retries, bounce handling, feedback loops, and IP reputation. This suits signup confirmations, password resets, receipts, and alerts. The guide to SMTP versus API sending compares the two integration styles.
If you run Postfix on a VPS for local system mail, you can keep it and point it at a relay. Set relayhost to the relay’s submission endpoint, enable SASL authentication with the relay credentials, require TLS, and leave port 25 alone. Cron output, monitoring alerts, and application mail then leave through the relay.
| Port | Purpose | Authentication | Typical state on a new cloud account |
|---|---|---|---|
| 25 | Server to server mail transfer to the recipient’s MX host | None for inbound transfer | Outbound restricted or closed by default; opened only on request |
| 587 | Message submission to a relay you have an account with | Required, with STARTTLS | Open |
| 465 | Message submission over implicit TLS | Required | Open |
How a provider decides to lift the restriction
There are legitimate reasons to deliver directly on port 25: running a mail server for your own domain, operating a mailing list for a community, or hosting mail for clients as a business. Providers handle these cases through a request under their acceptable use policy, made through their support channel, and the decision is the provider’s alone.
Expect to be asked what you intend to send, to whom, and how recipients consented. Providers commonly want a domain that resolves to the server, a reverse DNS record (PTR) that matches the hostname the server announces in its HELO or EHLO greeting, SPF and DKIM records for the sending domain, and an account with some age and a settled billing history. They may also want to see that the server is not an open relay and that bounce and abuse mailboxes for the domain are monitored. The article on SPF, DKIM, and DMARC setup covers the DNS side.
A request that describes bulk or purchased list sending will be refused, and a lift that is granted can be withdrawn if the provider later receives abuse reports. The restriction is a term of service, and the acceptable use policies of the major providers spell out what happens when it is ignored.
What responsible sending looks like from a VPS
This checklist applies whether the VPS relays through a service or has been approved for direct delivery.
- Send only to addresses that opted in, and record when and how consent was given.
- Publish SPF, sign with DKIM, and set a DMARC policy for every domain you send from.
- Process bounces and complaints automatically and suppress those addresses at once.
- Set a matching forward and reverse DNS entry for the server hostname.
- Keep the mail transfer agent patched, and never run it as an open relay.
- Monitor postmaster and abuse mailboxes for the domain and answer them.
- Start with low volumes and increase gradually, as described in the guide to email deliverability basics.
Where to go next
Several CloudAccountHub listings carry an Open 25 Port label, which states only what the label says and nothing about how the account may be used. Use of any account remains subject to the provider’s terms and acceptable use policy. The relevant pages are DigitalOcean accounts, Linode accounts, Hetzner accounts, Kamatera accounts, OVHcloud accounts, and BinaryLane cloud accounts.
For application mail that does not need a mail server at all, read Amazon SES explained, which covers the sandbox, production access, and sending quotas. The full email infrastructure series and the provider guides are in the Cloud Library.