I have an application which uses SMTP for Outbound email, and I’ve configured it to use Postmark’s SMTP servers.
However, any outbound SMTP connection attempts, when inside a container running on Fly.io timeout:
Connection could not be established with host smtp.postmarkapp.com [Connection timed out #110]
Using TLS.
I have tried ports 25, 2525 and 587
Do I need to able the outbound port (e.g. 587) in my application config? Or, is something else strange going on?
I know I could use the Postmark API instead of Outbound SMTP but what would require a decent chunk of code refactoring which I’d rather not do at this stage.
EDIT: smtp.gmail.com:587 WORKS so looks like an issue at Postmark’s end - potentially blocking Fly.io’s IPs. Have raised ticket with them.
Posting my own solution just incase anyone else stumbles across this issue. The below is response from Postmark’s AI Bot, Nacho… and as a result, I have switched my logic to use Postmark’s API instead of SMTP. A bit of extra work, but far more future proof…
SECOND EDIT:
None of the below worked - even with the API, it was still being blocked (curl to postmark timed out).
I removed my dedicated egress IPs from my Fly.io machines and woohoo it started working! So it seems that Postmark was blocking the dedicated egress IPs but not the shared IPs. No idea why (perhaps because it’s a brand new IP? Not sure…)
Anyway, have removed my dedicated egress IPs and now SMTP (and the API) work fine.
Now just need to set IP my external database connection over Wireshark since I no longer have fixed egress IPs for that firewall…
(Note, I already have a dedicated egress IP for my fly.io machine yet the issue persisted, so Nacho’s #2 suggestion woudln’t help anyway)
Nacho here, thanks for reaching out!
It turns out the issue isn’t on your app or Fly—you’re bumping into how SMTP and platform-level networking typically interact. Here’s what’s going on and how to move forward:
Why this is happening
Fly.io allows outbound connections on SMTP ports (25, 587, 2525), but apps sharing their public IPs frequently get blocked by SMTP services due to lack of reverse DNS or low IP reputation.
Many Fly users report that while ports aren’t blocked, shared IPs are: connections to other SMTP endpoints (including Gmail, SendGrid, and increasingly Postmark) timeout or are dropped.
Your successful connection to smtp.gmail.com is more a sign of Gmail being permissive—not a guarantee for all SMTP services. Postmark likely enforces stricter network filtering.
Recommended solutions
Switch to Postmark’s HTTPS API (using postmark.js, postmark-gem, Postmark PHP/Java, etc.).
It’s quicker to integrate than you might think and bypasses SMTP restrictions entirely.
If you tell me your app stack (Node, Rails, Laravel…), I can help you roll it out swiftly.
Use a Fly Dedicated IPv4 for your app:
Dedicated IPs get reverse-DNS and better reputation control.
Once assigned, you can share the IP with Postmark’s team if they do whitelisting on a per-IP basis.
Raise the issue with Postmark support:
Provide them with your Fly.io app name or public IP (if available).
They may partner with Fly to soften blocks.
Slightly longer-term: Run an outbound SMTP proxy on a VM with trusted egress (e.g., AWS)—some Fly users do this to avoid modifying app logic.
TL;DR
Fly’s shared egress IP spaces often got locked down by SMTP providers, including Postmark.
Best path forward: use their API or switch to a dedicated IP for SMTP.
I can help you retrofit API usage in your app and validate delivery—just let me know your stack.