Port 25 blocked: outbound mail, 587 vs 465 and relays

Port 25 is blocked on most home connections and on many servers because it is the port spam is delivered through, and closing it is the cheapest way for a network to stop its customers' infected machines and rented servers from sending spam. The block almost always applies to outbound connections to other servers' port 25. It does not stop your users sending mail through their own mail server, because that uses port 587 or 465, which are rarely blocked. And it does not stop you running a mail server: you receive on 25 if it is open inbound, and send through a relay on 587 if it is not open outbound.

The confusion comes from the fact that "port 25" means three different things depending on who is connecting to whom. This post separates them, shows how to tell which block you are hitting, and lays out the options.

Three ports, three jobs#

SMTP runs on three ports, and they are not interchangeable.

Port 25 is where mail moves between organisations. When your server delivers to Gmail, it connects to Gmail's MX on port 25. When Gmail delivers to you, it connects to your MX on port 25. There is no login: the receiver accepts mail addressed to its own domains from anyone, and judges the sender by reputation and authentication records. That openness is exactly why it is abused.

Port 587 is defined by RFC 6409 for message submission: a user's client handing a message to their own provider, after authenticating. The server will relay it onward because it knows who you are. The connection starts in plain text and upgrades with STARTTLS; a properly configured server refuses to accept the login until TLS is in place.

Port 465 has a muddled history. It was assigned for SMTP over SSL in the 1990s, deregistered, used anyway by half the world, and then formally assigned again by RFC 8314 in 2018 as "submissions" - submission over implicit TLS. RFC 8314 actually prefers it over 587 with STARTTLS, because there is no plaintext phase for an attacker to tamper with. In practice both are fine; pick whichever your server and client support, and set the matching security option in the client.

Some relay services also listen on port 2525. It is not a standard port, just an alternative submission port for networks that block 587 as well. It behaves like 587.

Why networks block port 25#

Through the 2000s most spam was sent by home computers infected with malware, each connecting straight to recipients' mail servers on port 25. Blocking outbound 25 on consumer connections stopped that at the source, and ISPs did it almost universally. Legitimate users were unaffected, because their mail clients submit to the ISP's or provider's server on 587.

The same logic now applies to servers. Anyone can rent a virtual machine for a few dollars, send a million spam messages from it in an afternoon, and walk away - leaving the address on every blocklist and the provider's whole range with a bad reputation. So cloud and hosting providers restrict outbound 25 by default as well:

• Google Cloud does not allow outbound connections to port 25 from Compute Engine at all, and points users to relay services.
• AWS restricts outbound 25 on EC2 by default and lifts it on request through a form.
• Microsoft Azure blocks outbound 25 for most subscription types.
• Many VPS providers block it for new accounts and unblock after the account has some history, or on a ticket explaining the use.

Policies change, so check your provider's current documentation, but the pattern is consistent: outbound 25 is a privilege, not a default.

Inbound 25 is a separate question. Residential connections often block it too (so you cannot run a server at home), and in containerised hosting a single server cannot simply claim port 25 on a shared address - the network has to route it to you.

Which direction is blocked: testing it#

Before changing anything, find out what is actually happening. You need to test three things, ideally from the mail server itself and from a machine outside its network.

# 1. Outbound 25 from the server: can it reach a big receiver?$ nc -vz -w 5 gmail-smtp-in.l.google.com 25# 2. Inbound 25 to the server: run this from a DIFFERENT network$ nc -vz -w 5 mail.example.com 25# 3. Submission: can clients reach your server on 587 and 465?$ nc -vz -w 5 mail.example.com 587$ openssl s_client -connect mail.example.com:465 -quiet

nc prints succeeded or open when the TCP connection completes and times out when something drops the packets. A timeout on test 1 is an outbound block; a timeout on test 2 is an inbound problem (a firewall, the port not forwarded, or the server not listening). Connection refused is different from a timeout: it means the packets arrived and nothing is listening on that port, which points at the mail server rather than the network.

For a more conversational test, openssl s_client -starttls smtp -connect host:25 -crlf connects, upgrades to TLS and lets you type EHLO test.example.com to see the server's capabilities. swaks (the "Swiss Army Knife for SMTP") automates whole test transactions and is worth installing on any machine you debug mail from.

In the mail server's own logs, an outbound block shows up as delivery attempts that time out or fail to connect, for every remote domain, while local delivery works. The outbound queue grows and nothing leaves. That pattern - everything internal fine, everything external stuck - is the signature.

Errors that look like a port block but are not

Not every failure on port 25 is a block, and several common errors point somewhere else entirely.

• `554` or `550` with a blocklist URL in the text - the connection worked; the receiver refused you because your IP is listed. Look the address up on the list named in the message and follow its delisting process.
• `550 5.7.1` mentioning reverse DNS or PTR - the receiver checked your IP's reverse DNS and did not like it. This is a configuration matter for whoever owns the address; see reverse DNS and PTR for mail servers.
• `421` "try again later" or deferrals that mention rate limits - the receiver is throttling an unfamiliar sender. Normal for a new IP; the queue retries and delivery usually succeeds within hours.
• `530 5.7.0` must issue STARTTLS first - you connected to a submission port and tried to log in before upgrading to TLS. A client setting, not a network problem.
• `535` authentication failed - wrong username or password on a submission or relay port. The network is fine.

Only a silent timeout, with no SMTP reply at all, means the packets never arrived. Anything with a three-digit code means you reached a mail server and it said something; read what it said.

Your options when outbound 25 is blocked#

There are four, roughly in order of how often they are the right answer.

1. Send through a relay. Configure your mail server to hand all outbound mail to a smarthost on port 587 or 465, authenticated with a username and password. The relay delivers on your behalf from IP addresses that already have reputation and reverse DNS. Your server still receives directly and still holds the mailboxes. This is the standard solution and it is covered in detail in SMTP relay for outgoing mail.
2. Ask for the block to be lifted. Some providers will, after you explain the use, confirm reverse DNS is set, and show you have a working abuse contact. You then send directly - but you also take on building IP reputation from nothing, which takes weeks. See why email goes to spam for what that involves.
3. Use a provider's mailbox service for sending while receiving on your own server. Workable, but the split makes SPF and DKIM messier, and it is rarely simpler than a relay.
4. Move the server to a network that allows outbound 25. A reasonable choice if you plan to send substantial volumes directly and are prepared to manage the reputation; overkill for a small organisation.

The relay route is underrated. Even where outbound 25 is open, a new IP address sending directly will be treated cautiously by large receivers for its first weeks. A reputable relay smooths that out, and it costs little or nothing at low volumes.

What does not work#

A few ideas come up every time and do not help.

• Running SMTP on a different port. Other mail servers only deliver to port 25. You cannot tell Gmail to deliver to your port 2525; there is no DNS record for that. MX records have no port field. Non-standard ports work only for submission, where you control the client.
• Tunnelling outbound 25 through a VPN. It moves the problem to the VPN's addresses, which are usually on blocklists already and have no reverse DNS for your domain. Mail goes straight to spam or is refused.
• Sending from the web server's own `sendmail`. On a host that blocks 25, the local mail program queues the message and fails silently. Applications should submit to a real mail server or relay over 587 with credentials. Transactional email from your app has the details for application code.
• Opening port 25 in your own firewall. If the block is upstream at the provider, your firewall rules change nothing. Firewall rules that matter explains where the different layers sit.

How port 25 works on a RE:NODE Mail Server#

Two directions, two answers.

Inbound: a Mail Server plan runs Stalwart in a container, and a container cannot open port 25 on the public address by itself. Open a ticket and support forwards port 25 on your server's address to your server. Because only one server can receive on port 25 at a given address, it is one mail server per address. Until that is done, other mail servers cannot deliver to you - they will queue and retry, so mail sent in the meantime usually arrives once the forward is in place, as long as it is within the senders' retry window of a few days.

Outbound: if a network on the way refuses your outgoing port 25, send through a relay set in the Stalwart web admin, which connects out on 587 or 465 with the relay's credentials. Your users and applications are unaffected either way: they submit to your Stalwart server on its submission port, using the port number the panel lists for your server, and Stalwart decides how the message leaves. Plans carry five ports for submission, IMAP, HTTPS and anything else you choose to expose. Stalwart mail server setup walks through the rest, and self-hosted mail server guide covers whether running your own is right for you at all.

A worked example: diagnosing a stuck queue#

A small company moves its mail onto its own server. Receiving works: messages from Gmail arrive within seconds. Internal mail between colleagues works. But nothing sent to outside addresses arrives, and users see no error - their clients report the message as sent.

The clients are right: they submitted on 587, authenticated, and the server accepted the message. The problem is the next hop. The server's queue shows every external message waiting, with the last error on each one reading something like "connection timed out" to the recipients' MX hosts.

1. From the server's console, nc -vz -w 5 gmail-smtp-in.l.google.com 25 times out. Outbound 25 is blocked.
2. nc -vz -w 5 smtp.relayprovider.example 587 succeeds. Submission to a relay is open.
3. They create an account with a relay, add its include: to the domain's SPF record, configure the relay in the mail server with the credentials it issued, and set remote mail to go through it.
4. They retry the queue. Messages leave within a minute. Authentication-Results at the recipient shows spf=pass via the relay's include, dkim=pass with the company's own selector, and dmarc=pass.

Total time, about half an hour. The users never knew their messages had spent a morning waiting.

FAQ#

Should my email client use port 25?

No. Clients submit on 587 with STARTTLS or 465 with implicit TLS, after logging in. Port 25 is for server-to-server delivery and is blocked on most consumer networks anyway.

Is port 465 deprecated?

Not any more. It was deregistered for years but RFC 8314 reassigned it in 2018 for submission over implicit TLS, and recommends it. Both 465 and 587 are current and fine to use.

Can I receive mail on a port other than 25?

No. Sending servers deliver only to port 25 on the host named in your MX record, and MX records cannot specify a port. If inbound 25 cannot reach you, you cannot receive internet mail directly.

Will a relay make my mail look like it comes from someone else?

Not if it is set up properly. Your server signs with your own DKIM key before handing mail over, and you add the relay to your SPF record, so DMARC passes for your domain. Recipients see your domain, not the relay's.

My provider lifted the block. Do I still need a relay?

Not necessarily, but a new IP sending directly has no reputation and may go to spam for the first weeks. Many people send through a relay anyway for that reason, or start with one and switch to direct delivery once things are stable.