a month ago
Hi Railway Support Team,
I am on the Railway Pro Plan and experiencing an issue where outbound transactional OTP emails sent via Office 365 SMTP (smtp.office365.com:587) are accepted by Microsoft's edge servers with a 250 OK status, but are never delivered to the target recipient inboxes (including internal domain addresses).
Technical Setup:
Service: Python / Flask Backend (EOR_Backend)
Project ID: afd2c914-25f1-4066-a2cd-1a96264361fa
Environment ID: 74ffe0ff-9035-414f-a981-7a0ffb58839f
Service ID: fd692d80-8cbd-43d5-92a6-3e3343d998df
Port / Protocol: 587 (STARTTLS)
SMTP Server: smtp.office365.com
Diagnostic & Verification Conducted:
Direct Terminal Handshake Verified: Executed interactive smtplib sessions directly inside the container via railway ssh. The connection, authentication, and payload handoff complete successfully with 250 2.0.0 OK from Microsoft's cluster (INDPRD01 / outlook.office365.com).
Microsoft 365 Side Checked: Checked Exchange Message Trace, Defender Outbound Quarantine, and Anti-Spam policies. The messages are missing from traces entirely, indicating they are dropped at the transport/edge layer right after handoff.
Threading Verified: Tested both synchronous and background worker dispatches inside Flask to rule out premature socket teardown.
What I need assistance with:
Could you verify if our project container traffic is originating from a flagged/blacklisted egress IP range on GCP/AWS, or if there is specific egress IP routing/static IP setup available for our service to ensure clean deliverability to Microsoft 365 edge nodes?
Thanks,
Davnish
5 Replies
a month ago
You'll want to use the static IP feature, which is available to users on the Pro plan.
Status changed to Awaiting User Response Railway • about 1 month ago
Railway
You'll want to use the static IP feature, which is available to users on the Pro plan. <https://docs.railway.com/reference/static-outbound-ips>
a month ago
I have just enabled the static IP outbound feature but still not receiving the emails to our inbox. What should we do next?
Status changed to Awaiting Railway Response Railway • about 1 month ago
a month ago
Having looked into this, the issue appears to be in your application code or configuration rather than the Railway platform itself, which puts it outside what Railway support can resolve directly.
This is exactly the kind of problem the Railway community is good at, so we'd like to open your thread as a community bounty. Railway pays a bounty to the community member who solves it, and threads like this usually get picked up quickly.
Opening it makes this entire thread public, including everything already posted. Nothing becomes public until you decide. Use the buttons below.
- Open to the community - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away.
- Keep it private and close the thread - Nothing becomes public and the thread closes.
Status changed to Awaiting User Response Railway • about 1 month ago
a month ago
There is one thing I would like to clear is that on our local machine and on our previous cloud setup, the emails have been working but since we migrated to railway, they stopped working. So, I am confused as what could be the issue.
Status changed to Awaiting Railway Response Railway • about 1 month ago
a month ago
This still looks like an application-level problem, so Railway support can't take it further, but the community can. The buttons below are still live: open the thread up as a public bounty after editing out anything sensitive, or keep it private and close it.
Status changed to Awaiting User Response Railway • about 1 month ago
a month ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • about 1 month ago