Your host blocks the SMTP port, so nothing sends

If your support centre's mail attempts hang and then time out, with no numbered reply from the server at all, your host is blocking the outbound port. On Hetzner Cloud, ports 25 and 465 are blocked by default and port 587 is not, so moving your relay to 587 fixes it the same afternoon. On DigitalOcean, all three are blocked on Droplets and you need a provider API instead.

Test it before you change anything, because the two providers most readers are on take opposite positions on the port that matters.

How do you tell a blocked port from every other mail failure?

By whether you get an answer. A blocked port means the packets are dropped before they reach the mail server, so your tool waits and then gives up: connection timed out, no reply, no error code. Every other common mail failure produces a numbered response, because it happens after the connection is open.

• A reply of 535 5.7.8 means the connection succeeded and your credentials were refused. That is username and password not accepted, a different problem entirely.
• A message that is accepted and then never appears is the sign-in email never arrives, which is a delivery problem, not a network one.
• A message that is accepted and later bounced with a code, such as Gmail's 550 5.7.26, got all the way to the recipient's provider.

Prove which one you have in a single line. nc reports a refused or timed-out connection immediately:

nc -vz -w 5 smtp.provider.com 25
nc -vz -w 5 smtp.provider.com 465
nc -vz -w 5 smtp.provider.com 587

Run it from inside the container if that is where your app lives, not from your laptop, because the firewall in question is the one around your server. A succeeded! on 587 and a hang on 465 is the whole diagnosis.

To go one step further and see the greeting banner, open the port properly:

openssl s_client -connect smtp.provider.com:465 -crlf -quiet

That should print a 220 greeting within a second or two. Silence means nothing is getting through.

Which ports does your host actually block?

Name the host, because the answer is not the same everywhere. Both of the figures below come from the provider's own documentation, fetched on 23 August 2026.

Hetzner's reason is stated plainly in its cloud FAQ: "email spammers and scammers like to use cloud hosting providers". The block can be lifted, but only by a limit request, only once you have been a customer for a month and paid your first invoice, and each request is decided case by case.

Most people never need to ask, and this is the sentence that gets left out of every write-up of the Hetzner block:

Port 587 is not blocked and can be used without sending a limit request.

Hetzner Cloud FAQ

If you are sending through an external relay, which is what almost every self-hosted support tool should be doing, Hetzner's block does not affect you at all. Our own guide to self-hosting on Hetzner recommends the host without covering any of this, and this page is the missing half of that advice.

DigitalOcean is stricter, and it also says why it would not recommend the alternative even if it opened the port: self-hosted mail servers "are difficult to secure and maintain, frequently get flagged as spam, and require constant monitoring". Their recommendation is a third-party email provider, which on a Droplet means the provider's HTTP API rather than SMTP on any port.

What do you do when the port you need is blocked?

Work down this list and stop at the first one that applies.

• Move the relay to 587. On Hetzner this is the entire fix. Change the port in your tool's configuration, make sure it is set to STARTTLS rather than implicit TLS, and send a test.
• Use the provider's HTTP API instead of SMTP. Every serious transactional provider offers one, it runs over port 443, and no host blocks 443. This is the answer on DigitalOcean and on any platform that gives you no outbound SMTP at all.
• Check whether your provider offers an alternative port. Several publish a non-standard submission port precisely because 25, 465 and 587 are so widely filtered. Read their documentation rather than guessing at a number.
• Ask for the unblock only if you genuinely need 25. You need it to run your own mail server or to deliver directly to recipient servers. Sending through a relay is not one of those cases, so the request is usually avoidable work.
• Move the sending to somewhere else entirely. A scheduled job on a platform with no outbound restrictions, or a serverless function, can carry the mail while the VPS keeps serving the site.

Why does 465 fail even when nothing is blocking it?

Two ports, two protocols, and a lot of software that only ever implemented one of them. Port 587 is the message submission port defined in RFC 6409, where the connection starts in plain text and is upgraded with STARTTLS. Port 465 carries implicit TLS, meaning the connection is encrypted from the first byte, and it was restored as a standard route for submission in RFC 8314. A client that only speaks STARTTLS cannot talk to 465 at all, and the failure looks like a hang rather than an error.

Fider is a concrete example of exactly that. Issue #865, "Cannot get SMTP SSL working", carries six reactions, the most of any SMTP issue in that repository, and the reporter's own summary is the giveaway: "I tried to set up Fider but could not get SMTP SSL working (standard port 465) ... But with TLS/STARTTLS 587 it is working." Implicit TLS on 465 was only added in pull request #1554, merged in May 2026. Both were read from the GitHub API on 23 August 2026.

Microsoft draws the same line from the other side. Its guidance for applications sending through Microsoft 365 says that a device defaulting to port 465 "doesn't support the required versions of TLS for client SMTP submission", and directs you to 587.

The practical rule: prefer 587 unless your provider specifically documents 465, and if you must use 465, confirm your tool supports implicit TLS before blaming the network.

The port your support centre does not open

Worth saying once, because it is the reason this page exists rather than a claim about it. Docket's runtime is static files plus two endpoints, with no SMTP client in the free edition at all, so there is no outbound mail connection for a host firewall to drop. The paid tiers add email notifications and go out through a transactional provider, which means 587 or an HTTPS API, neither of which Hetzner blocks. That removes one failure mode. It does not remove the DNS records, which every sender still has to publish: SMTP for self-hosted tools covers those, and SPF permerror, too many DNS lookups covers the one that most often makes them invalid.

Frequently asked questions