Port 25 Is Blocked: Why It Happens and What Actually Fixes It
The short answer
Port 25 is blocked outbound by most residential and cloud networks to stop spam and compromised machines. Nothing you change locally reopens it. Your options are a relay on port 587 or 465, a host that permits 25, a server elsewhere with 25 open, or a mail provider that sends for you.
The symptom is specific: mail queued on your own server sits in the queue, the log shows "connection timed out" to the destination on port 25, and every other port works. It is not a misconfiguration on your side and it is not usually the destination's fault. It is your network refusing outbound port 25, which is a deliberate decision made years ago by almost every consumer ISP and most cloud providers.
Why port 25 is blocked at all
Port 25 is the port mail servers use to relay mail to each other. It is also the port a compromised home machine or an abused cloud instance uses to send spam directly, so networks with large numbers of untrusted endpoints found it cheaper to block outbound 25 than to clean up after each incident.
That is why the block is applied to outbound connections from your network, not to inbound mail arriving for you. Your provider may still accept mail on 25 from other mail servers; what it will not do is let your machine open a connection outward on that port.
What the block looks like in practice
A connection attempt to a remote mail server on port 25 hangs and then times out, typically after 30 to 120 seconds. There is no refusal, because nothing is answering to refuse: the packets are dropped. That distinction matters, because a refusal would suggest the destination rejected you, while a timeout points at the path.
A useful test is to try the same connection from a different network. If it succeeds from a mobile hotspot and times out from your office, the block is on the office connection. If it times out everywhere, the destination or its provider is the one filtering, which is a different problem with the same shape.
The four options that work
Send through a relay on a submission port. Ports 587 and 465 are the standard client submission ports, encrypted, and almost never blocked. Your application authenticates to the relay and the relay does the port 25 delivery on your behalf. This is the correct answer for anything that is sending mail rather than running a mail server, and it is why bought mailboxes exist.
Move the sending to a host that permits port 25. Cloud providers vary: some open it only after a support request and a review, some only on higher plans, some never. A Virtual Private Server or Remote Desktop on a network that allows it removes the block entirely, at the cost of running the mail server yourself.
Use a provider that sends on your behalf, with your domain and your authentication. This is the relay option with the mail server included, and it is the least work if you do not need to receive mail on the same machine.
Ask your provider. It occasionally works: a business connection with a static IP and a stated reason can be unblocked, though home connections usually cannot.
What will not work, and costs an afternoon
Changing the port the destination listens on is not possible: the receiving server decides. Editing your local firewall cannot help, because the block is upstream of it. A VPN may route around it, and then your mail leaves from a shared address with a reputation you do not control, which is usually a worse trade than a relay.
Also avoid "port 25 unlock" tools. There is no setting on your machine that a remote network administrator has left open. Anything sold as a local fix for an upstream block is not fixing the block.
Worked example: a booking system that stopped emailing
A small hotel runs its own booking system on a server in the office. Confirmation emails stop arriving one Monday. The log shows the application connecting to the guest's mail provider on port 25 and timing out after ninety seconds. Nothing in the application had changed, and the ISP had changed something upstream without telling anyone.
The fix was not a firewall rule. The application was pointed at a relay on port 587 with authentication, and confirmations resumed within the hour. The mail left from the relay's address, with the hotel's domain in the From line and SPF and DKIM records updated to match, which took one DNS change per record.
Six months later the hotel wanted the booking system to receive replies as well, and the relay only sent. That is the case for a server with port 25 open: they moved the mail server onto a Windows Remote Desktop at $50 a month, kept the relay as a fallback, and stopped depending on a port their office connection was never going to be allowed to use.
Your situation, and the option that fits it
| Situation | What is blocking | The workable option | Effort |
|---|---|---|---|
| Home or office network, sending from an app | ISP blocks outbound 25 | Relay on port 587 or 465 | Minutes |
| Cloud instance, sending notifications | Provider blocks 25 by default | Provider relay, or a support request | Minutes to days |
| You must receive mail directly | Outbound and inbound 25 | Server on a network with 25 open | A day of setup |
| Running your own mail server | Outbound 25 from your network | Remote Desktop from $50 a month with port 25 open | A day of setup |
| Just need to know if a server accepts mail | Neither: you are testing | An SMTP test against the destination | Minutes |
A $10 proxy address does not fix port 25: it forwards web traffic and cannot carry a mail relay. The relevant product here is the Remote Desktop.
Confirm it is really port 25 before you spend anything
- 1Read the mail log and note whether the failure is a timeout or an immediate refusal.
- 2Test the same connection from a different network, such as a phone hotspot.
- 3Confirm ports 587 and 465 connect from the same machine, which proves the network is fine and only 25 is filtered.
- 4Decide whether you need to send only, or send and receive on your own machine.
- 5If you need to receive, choose a host that states port 25 is open rather than assuming it.
Where this connects on this site
- If you need to send and receive on your own machine, see Remote Desktop servers with port 25 open
- For the relay option with the server included, start with mailboxes that send through a relay
- To check what a destination does with your connection, use the SMTP tester
What this will not do
- Opening port 25 does not make your mail welcome. Authentication, list quality and reputation still decide delivery.
- A relay moves the problem to the relay's reputation, which you do not control. That is a trade, not a solution without cost.
- No configuration described here guarantees that a destination accepts your messages; destinations set their own rules.
- Running your own mail server is real operational work: patching, log review, blocklist monitoring and backup are yours.
Questions this page gets asked
- Can I just use port 587 to send directly?
- No. Port 587 is the submission port: it is for your mail client or application to hand a message to a mail server, with authentication. Delivering to the destination is still the server's job on port 25. Using 587 without a server to submit to means you have nothing to authenticate against.
- Why did this work last year and stop now?
- Providers change policy quietly and often after abuse incidents on their network. The block is usually applied at the network edge, so nothing on your machine changes and nothing warns you. The log is the only notice you get.
- Does a proxy work for mail?
- No. A web proxy forwards HTTP and HTTPS, and a SOCKS5 proxy can carry a TCP connection, but neither is a mail relay: the destination still expects a mail server conversation on port 25. Use a relay or a host that permits the port.
- How can I tell whether the destination is refusing me?
- A refusal returns a reply code, usually in the 4xx or 5xx range, and it appears in your log within seconds. A timeout produces nothing at all. If you see a code, the destination is talking to you and the problem is on its side or in its blocklist, not your network.
Last reviewed 2026-10-26. Written for readers in the United States and elsewhere; rules about access, email and consent differ by country, and nothing on this page is legal advice.