Railway Will Forward Your Email Now: What Platform-Owned Domain Perks Really Cost Portability

Railway's September 11 changelog (#0307) ships email forwarding for domains purchased through Railway: point hello@yourdomain.com at an inbox you already use, no separate mail service required. It is a genuinely nice feature for a side project — and it is also the third link in a chain that now binds a Railway-bought domain to the platform at the registrar, DNS, TLS, and mail layers at once. Each link is individually escapable. Together, they turn "leaving Railway" from one migration into a sequence of dependent migrations, each with its own wait and cutover risk:

Nothing in that table is hidden — it is all in Railway's own docs, quoted below. The point is structural, not accusatory: every "free with your domain" capability is capability that only exists while the platform remains your registrar, your DNS, and your mail exchanger. This post walks the chain link by link, names the escape hatches honestly, and shows what the portable version of the same setup looks like.

What Railway now bundles with a domain​

Railway started selling domains directly (railway.com/domains, March 2026) through a registrar partner, and the bundle has grown steadily since. The current inventory, per the docs:

Registration. 250+ TLDs, one-year terms (two-year minimum on some like .ai), WHOIS privacy and auto-renewal on by default, priced at cost rounded to the dollar. Two details matter for what follows: domain subscriptions are billed separately from the workspace subscription, and — in Railway's own words — "Railway is listed as the registrant contact and handles all registry communications on your behalf." You own the domain in the commercial sense, but the platform sits between you and the registry operationally.

DNS. Fully managed through Railway's nameservers by default; attaching a domain to a service needs no manual records. Workspace admins can delegate to custom nameservers without transferring the domain out — but while delegated, the one-click attach flow disappears and the DNS records section goes read-only ("managed at your external provider"). The managed experience and the portable experience are mutually exclusive by design.

TLS. Automatic issuance once the domain is attached to a service. Standard PaaS fare, and genuinely zero-config — until the day you need the same hostname to validate somewhere else.

Email forwarding (new in #0307). Workspace admins open a domain, find Email Forwarding, add an address (hello → your Gmail), and hit Send test email. Railway configures the required DNS itself. The limits are plan-shaped: 1 address per domain on Trial and Free, 5 on Hobby, 25 on Pro and Enterprise. The capability ceiling is relay-shaped: no mailboxes, no sending from the forwarded address (replies come from the destination inbox), no spam filtering in transit, attachments over 10 MB may fail, one destination per address, no catch-all or wildcard.

For a solo side project, this bundle is close to ideal: one dashboard, one bill, a hello@ address in three clicks. The same changelog also brought one-click Postgres major upgrades and a São Paulo CDN region — Railway is clearly investing in the "never leave the dashboard" moat. The question is what that moat costs on the way out.

The exit chain, link by link​

Imagine the side project worked. It is now a small business, and the team is migrating off Railway — to owned hardware, another PaaS, wherever. The domain has to come along. Here is the actual sequence, with each link's friction:

Link 1: the registrar transfer. This part is better than it could be: Railway offers self-service transfer-out from the domain detail page, no support ticket required. But the constraints are real. Only workspace admins, only with 2FA, only on active domains — and ICANN's 60-day lock means a domain bought 3 weeks ago cannot move for another 5, a policy Railway states it cannot waive or expedite. Once eligible, clicking Get Transfer Code unlocks the domain, turns off auto-renewal, and hands you the EPP code to paste at the gaining registrar, which then carries out a transfer that "most" complete in 5–7 days. Transfers are final, no undo.

So the identity layer of your business spends up to a week in flight between registrars, unprotected by auto-renew, gated on one admin's 2FA device working that day. Separately: Railway does not support transferring domains in, and workspace-to-workspace transfer is still "planned" — the door swings one way, slowly.

Link 2: email must move before DNS can. This is the sharpest interaction in the chain, and it comes straight from the forwarding docs: enabling forwarding adds seven DNS records to the apex (several MX records plus an SPF record), and while forwarding addresses exist, Railway refuses both a third-party MX record at the apex and delegation to custom nameservers. Read that twice. You cannot stage the mail migration (point MX at the new provider while Railway still serves the zone) and you cannot stage the DNS migration (delegate nameservers while forwarding still runs) — the dependency arrow runs one way. Mail exodus first: delete every forwarding address in Railway, which drops the MX/SPF records, then rebuild equivalent forwarding at the new provider, then move DNS.

During that window, mail addressed to hello@ routes wherever the half-migrated records say — the classic split-brain interval, except here the platform's own guardrails force the ordering rather than letting you overlap the cutovers.

Link 3: DNS rebuild with its own TTLs. Whether you delegate nameservers or transfer the domain and rebuild the zone, every record set carries its own propagation delay. Apex ALIAS/CNAME targets change (Railway's service targets do not exist outside Railway), the seven mail records get rebuilt at the new mail provider, and any TXT verification records for third-party services get re-created. None of this is exotic — it is a normal DNS migration — but it is a second migration with a second set of TTLs, sequenced after the mail migration above.

Link 4: TLS re-issuance at the destination. Certificates issued through Railway stay with Railway. Every hostname re-validates on the new platform — new ACME challenges, new DNS-01 or HTTP-01 records or flows — timed against the DNS cutover from Link 3. Short-lived certificates make this routine rather than scary, but it is still cutover number three sharing a maintenance window with cutovers one and two.

To be fair about the counter-argument: none of these links is a wall. Self-service transfer-out exists. Custom nameservers exist without transfer. Pricing is at cost, so there is no financial hostage-taking. A disciplined team executes this chain over a week and moves on. The honest claim is narrower and still matters: the chain is serial, not parallel. Forwarding gates DNS delegation; the 60-day lock gates the transfer; DNS gates TLS. A migration you could have done as concurrent record edits becomes a four-link dependency chain with calendar-time waits (60 days, 5–7 days) embedded in it — and every future "free with your domain" perk gets to add another link.

The portable version of the same setup​

Now replay the whole thing with the domain at an independent registrar (Cloudflare Registrar, Porkbun, Namecheap — anywhere whose only job is the domain), DNS at a dedicated provider, and mail forwarding from a mail-shaped service:

• Registrar independence means the platform migration never touches the registration at all. No EPP codes, no 60-day arithmetic, no week in flight, no admin-2FA gate on moving day. The domain simply outlives every hosting decision.
• DNS at the independent provider turns platform exit into record edits. Point the apex and subdomains at the new infrastructure, lower TTLs ahead of the window, and the cutover is measured in minutes of propagation — with the old records one revert away. No zone rebuild, because the zone never lived on the platform.
• Mail forwarding from a portable relay — Cloudflare's Email Routing is the obvious free analogue: unlimited addresses, catch-all and rule-based routing, MX/SPF/DKIM records you control — keeps the hello@ experience without the coupling. Compare ceilings honestly: Railway gives you 1–25 addresses, no catch-all, no wildcard, replies-from-destination, 10 MB attachment failures; Cloudflare gives you unlimited addresses with catch-all for free on a domain it does not need to have registered. Either way replies come from somewhere else — forwarding is forwarding — but only one version refuses to coexist with your DNS migration.

Note what this setup gives up: the three-click attach. You will paste a CNAME target from a dashboard into a DNS zone like it is 2019. Railway's Domain Connect one-click flow for external domains narrows even that gap for supported registrars. The price of portability is roughly ten minutes of DNS records per service — paid once, at attach time, instead of a serial four-link chain paid under migration pressure later.

There is also a middle path worth naming: buy on Railway for the zero-config start, then the moment the project earns the word "business," transfer out and rebuild the stack above. The 60-day lock makes this a calendar decision — day 61 is the earliest exit — so put the reminder on the day you buy, not the day you want to leave.

Buy the convenience with eyes open​

The pattern here is bigger than one changelog. Vercel sells domains. Cloudflare sells domains. Every platform that sells domains will, sooner or later, attach capabilities that only function while the domain stays — because that is what makes the bundle feel magical. Railway's execution is better than most: self-service exit, documented constraints, at-cost pricing, no dark patterns in the transfer flow. Judge the structure, not the vendor: each perk you adopt is a migration you pre-schedule.

So the rule is simple. If it is a side project and might stay one, take the bundle and enjoy the hello@ — the exit chain costs nothing until you need it. If it is a business, or might become one, keep the domain at an independent registrar from day one, with DNS, mail, and TLS pointed at infrastructure you control. Leaving a PaaS should mean re-homing your workloads, never re-homing your identity layer too.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.