Outbound port 25 (direct-to-MX SMTP) blocked by default on new accounts?

Hi, I’m setting up a self-hosted mail server (Stalwart) on a Fly Machine and need to confirm outbound SMTP behavior before I invest more build time.

Specifically:

  • Is outbound port 25 (direct-to-MX delivery, not authenticated submission via 587) blocked by default on new Fly accounts?
  • If blocked, what’s the process to request it unblocked — is there a form, or does it require reaching out to support directly?
  • Does this depend on whether the app is using a shared IPv4 vs. a dedicated IPv4?

App name: fly-core-template, region: iad. Appreciate any clarity — trying to confirm this is technically possible before finishing the deployment.

587 is not blocked by default, but I assume 25 is. I assume that here is a good place to catch staff attention.

Reference: Request to unblock outbound SMTP (port 587) for app rialma-api

Thanks! I appreciate the share.

Following up in case a staff member can confirm: is port 25 outbound actually blocked by default, and if so, is there a specific process/form to request it unblocked? Want to confirm before continuing to build against it. :slight_smile:

Hey! There’s no per-account blocking of outbound port 25. That being said, we don’t really recommend setting up mail servers in this way.

Direct-to-MX delivery needs reverse DNS on your sending IP, and we don’t currently offer customer-configurable PTR records. You could allocate a dedicated egress IP (i.e. fly ips allocate-egress -r iad ) so your outbound traffic has a stable source address, but it won’t have a PTR record which most large receivers will penalize or outright reject for direct-to-MX.

Inbound usually works fine, but you’d have to set up a dedicated IPv4 ( fly ips allocate-v4 ) for it. On a shared IPv4, the proxy can’t route plain SMTP since there’s no SNI or Host header to route on.

For outbound we recommend relaying through some kind of transactional email service (i.e. SendGrid, Postmark).

You can read more about this here:

https://fly.io/docs/getting-started/troubleshooting/#outbound-connections

Hi, really appreciate the detailed answer, this was exactly what I needed to make a call on architecture.

Going to go that route rather than attempting direct-to-MX delivery. Good to know the option’s there if that ever changes down the line.

Thanks again for the clear explanation. Saved me a lot of trial and error.