Port 25 and Outbound Email: Why Cloud Providers Restrict It

Why Your Server Cannot Reach Port 25

Deploy an application to a fresh cloud instance, wire up a password reset email, and there is a good chance nothing arrives. No error, no bounce, just a connection that times out. The cause is almost always the same: the provider does not allow outbound connections on TCP port 25 from that instance.

This is not a bug and it is not aimed at you. It is an industry-wide default, and the providers that apply it most strictly do so because the alternative made their address ranges unusable for everybody.

What follows explains the reasoning, distinguishes port 25 from the ports you should actually be using, and covers the authentication records that decide whether your messages are accepted. It does not cover evading the restriction, which is against every provider's terms and counterproductive besides.

The Reasoning Behind the Block

Port 25 carries server to server mail transfer. Crucially, it is the port on which a receiving mail server accepts messages from strangers, with no authentication involved. That property is what made email work across the whole internet, and it is also what made it the ideal channel for bulk unsolicited mail.

Cloud providers hand out addresses in large contiguous ranges, cheaply and within seconds. From an abuse perspective that is a perfect combination: whoever controls a compromised account can create instances and send at volume until somebody notices.

The consequence lands on everyone else. Blocklist maintainers do not evaluate addresses in isolation, so a range with a history of abuse is treated with suspicion as a whole, and every legitimate customer in it finds mail delayed or silently discarded. Reputation is far slower to rebuild than to lose.

So providers close the port by default and open it selectively. The strictness varies:

• Google Cloud does not permit outbound port 25 traffic from Compute Engine instances at all. The Compute Engine mail guidance directs customers to a relay instead.
• AWS restricts outbound port 25 on EC2 by default and publishes a request process for accounts with a clear, stated need.
• Azure blocks outbound port 25 from virtual machines for most subscription types.
• Developer clouds including DigitalOcean, Vultr and Hetzner commonly block it for new accounts, with support handling requests case by case.

Treat the block as a property of the platform you chose, like a default firewall rule or a service quota.

Port 25 Is Probably Not the Port You Want

Much of the confusion comes from applications that reach for port 25 out of habit. Three ports matter, and they have distinct jobs.

Message submission was separated from transfer for exactly this reason, and is specified in RFC 6409. Your application is a submission client, not a mail server: it should authenticate, hand the message to a relay, and let the relay deal with delivery.

Providers do not block 587 and 465, because a connection on those ports is authenticated and therefore attributable. Configure your application for one of them and the problem usually disappears.

Inbound port 25 is a separate matter. A mail server that receives messages for your own domain must accept connections on port 25, and providers generally permit that. The restriction is on outbound connections.

The Legitimate Reasons Teams Need Outbound Mail

Most applications send email, and almost none of it is marketing:

• Account lifecycle messages: verification, password reset, security alerts about a new sign-in.
• Transactional records: receipts, invoices, shipping confirmations, booking details.
• Operational notifications: monitoring alerts, backup failures, cron job output, certificate expiry warnings.
• Messages between users of a platform: a reply notification, a shared document, a support ticket update.
• Newsletters and product updates to people who explicitly asked for them.
• Running a genuine mail service for a domain you control, where the server must deliver to other mail servers directly.

Only the last of those actually requires outbound port 25. Everything above it is better served by an authenticated relay, which also handles retries, bounce processing and reputation management on your behalf.

If you do intend to run a full mail server, plan for the whole job: inbound filtering, storage, backups, blocklist monitoring and reverse DNS. Providers assess requests for outbound port 25 access against that context and the standing of the account.

Using a Relay, Which Is What Almost Everyone Should Do

A relay service accepts your authenticated submission and takes responsibility for delivery. The providers each offer one, and there is a healthy market of independent services alongside them.

The provider options include Amazon Simple Email Service, Azure Communication Services Email and the SMTP relay that comes with Google Workspace. Signing up is a real process: you verify your sending domains, you start in a restricted environment, and you show that you handle bounces and complaints before limits are raised. That gatekeeping is the product.

Wiring it up takes one of two forms. Most application frameworks accept SMTP settings directly, so you set the host, port 587, the credential and the sender address. Alternatively, install a local mail transfer agent such as Postfix configured as a satellite that forwards everything to the relay as its smarthost, which is worth the effort when several services on the machine send mail or when cron output needs to arrive somewhere.

Keep the credential out of the repository and out of the image, exactly as with any other secret; the secrets management guide covers where it should live. If you use a provider relay, an AWS account or a Google Cloud account gives you the sending service in the same place as the compute, and the AWS and Google Cloud comparison covers how differently the two platforms package supporting services like this.

The Records That Decide Whether Mail Is Accepted

Getting a message out of your network is half the problem. Getting it into an inbox depends on DNS records that let the receiving server verify you. Publish all four.

SPF

A TXT record on your domain listing the servers permitted to send on its behalf. Relays publish an include mechanism you add to yours. Keep one SPF record per domain, not several, and stay within the lookup limit the specification sets out in RFC 7208.

DKIM

A cryptographic signature added to each message, with the public key published in DNS. It survives forwarding in a way SPF does not, because it validates the message rather than the connection. Your relay generates the key pair and tells you the record to publish.

DMARC

A policy record saying what a receiver should do when neither SPF nor DKIM aligns with the visible sender domain. Start with a monitoring policy and the reporting address enabled, read the reports for a few weeks to find sources you forgot about, then tighten to quarantine and finally to reject.

Reverse DNS

A PTR record mapping your sending address back to a hostname that resolves forward to the same address. Providers set this from the instance or address configuration rather than your registrar, and it matters only when your server delivers directly on port 25. The DNS setup article covers where each of these records lives.

Sending Responsibly

Authentication proves who sent a message. It says nothing about whether the recipient wanted it, and mailbox providers weigh recipient behaviour far more heavily than records.

Send only to people who asked, and keep a record of when and how they asked. Confirmed opt-in, where a subscriber clicks a link to activate, keeps complaint rates low and is the right default for any list.

Make unsubscribing trivial and act on it immediately, including the list header that mail clients turn into a one-click unsubscribe button.

Handle bounces and complaints automatically. Remove hard bounces on the first failure, retire addresses that go quiet, and treat a complaint as a permanent removal. Continuing to send to dead addresses is one of the clearest signals that a sender is not maintaining its list.

Separate your streams. Send transactional mail from one subdomain and bulk mail from another, each with its own authentication, so a campaign with a bad week cannot stop password resets from arriving. Watch the delivery metrics your relay exposes, and investigate a rising complaint rate before a blocklist does it for you.

Questions About Mail on Cloud Servers