Port 25 and Outbound Email: Why It Is Blocked

You deploy an application, it tries to send a password reset email, and
nothing arrives. No error that makes sense, no bounce. The cause is almost
always the same: outbound traffic on port 25 is blocked by default, and has been
on essentially every cloud provider for years.

Why it is blocked

Port 25 is the port mail servers use to deliver mail to each other. It is
also, for the same reason, the port used to send spam, and cloud infrastructure
is attractive to spammers because it is cheap, fast to provision and
disposable.

A provider whose address ranges develop a reputation for sending spam causes
problems for every customer in that range, because major mail systems block by
reputation at the network level. One abusive customer can degrade deliverability
for thousands of legitimate ones.

Blocking outbound port 25 by default is the simplest effective control. It
protects the provider’s address reputation, which protects their customers. It
is not an arbitrary restriction and it is not negotiable as a matter of policy
on most platforms.

What is actually blocked

Usually outbound connections to port 25 from your instances. Typically not
blocked:

• Inbound mail to port 25, if you are running a receiving mail server.
• Outbound submission on ports 587 and 465, used to authenticate to a mail
  provider and hand them a message to deliver.

That second point is the practical route for almost every application, and it
is why most people never need port 25 at all.

Sending email the right way

Use a transactional email provider. Your application authenticates over an
API or over submission on port 587, and the provider handles delivery.

This is not a workaround; it is better than running your own mail server for
reasons that have little to do with the port block:

• Deliverability. A new cloud IP address has no sending
  reputation, which means spam folders at best. Established providers have
  reputation you inherit.
• Authentication. SPF, DKIM and DMARC are configured once and
  correctly, rather than debugged by you over several weeks.
• Bounce and complaint handling, which you otherwise have to
  build and must handle properly to keep sending.
• Visibility of what was delivered, opened or rejected.
• No mail server to operate, patch and secure. An open or
  misconfigured relay is a fast route to an acceptable use suspension.

Most providers of this kind have free tiers sufficient for a small
application’s transactional mail.

About requests to unblock it

Some providers will lift the restriction on request, usually after the
account has a payment history and a stated legitimate reason. Others will not,
or will only do so for established business accounts.

Two things are worth being clear about. First, it is a trust decision tied to
account history, which means a brand new account is unlikely to succeed.
Second, and more usefully: for a normal application there is rarely a reason to
ask. If what you need is for your software to send email, submission to a mail
provider does that better, and the only situation that genuinely requires
outbound port 25 is running your own full mail server, which is a larger
undertaking than most people intend.

If mail is not arriving and the port is not the cause

Work through these in order:

1. Confirm which port and method your application is using. Port 25 means
   reconfigure to submission.
2. Check the provider’s documentation for a stated restriction on your
   account.
3. Check SPF, DKIM and DMARC records for the sending domain. Missing or wrong
   records send mail to spam even when delivery succeeds.
4. Check whether your sending address range appears on a public blocklist.
5. Look at the mail provider’s own delivery logs, which usually state the
   reason precisely.

In most cases the answer is either the port or the authentication records,
and both are configuration rather than infrastructure problems.