24 days ago
Dear support team,
I’m currently trying to verify a custom domain for a service, but the verification is stuck on “Waiting for DNS update,” even though the DNS records appear to be correctly configured.
Project / Service:
redacted
Affected domain:
redacted
Current situation:
- The CNAME record is already correctly detected and resolved by Railway.
- The TXT verification record (
_railway-verify) is set and publicly resolvable via DNS. - However, Railway still shows “Waiting for DNS update” and displays a yellow warning triangle next to the TXT record.
I’ve verified via dig that the TXT record is live and returns the expected value from multiple resolvers, so this doesn’t appear to be a propagation issue anymore.
Additional context (important):
We’ve run into this issue multiple times now. A workaround that does work:
- Delete the custom domain in Railway
- Re-add it (no waiting required)
After that:
- Both CNAME and TXT show as verified (green checkmarks)
However, there’s a catch:
- Railway assigns a different CNAME target after re-adding the domain
- Despite that, the domain still works with the old CNAME as well
This puts us in a difficult position:
I don’t want to ask our client’s IT team to repeatedly update DNS records if the previous CNAME continues to work fine.
Questions:
- Is it safe to keep using the old CNAME value in the DNS settings, even if Railway now shows a different one?
- Is this inconsistent TXT verification behavior a known issue on your end?
- Can we expect a fix so that TXT verification works reliably without needing to re-add the domain?
I’ve attached a screenshot showing:
- The first correctly recognized CNAME
- The warning state for the TXT record in Railway
Thanks in advance for your help!
Best regards
Pinned Solution
22 days ago
For the API, the TXT content is located under verificationToken under status.
4 Replies
Status changed to Awaiting Railway Response Railway • 24 days ago
24 days ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • 24 days ago
24 days ago
- Although it works, it’s not recommended and may cause unexpected behavior in the future.
- DNS itself can have some funky issues here and there; I haven’t noticed any constant issues regarding TXT verification. A quick remove and re-add pretty usually fixes those one-off situations.
- Answered above.
22 days ago
Hi @0x5b62656e5d,
thanks for the clarification.
The difficult part for us is that the recommended workaround creates extra work with every affected customer domain:
We ask the client’s IT team to add the CNAME/TXT records, Railway gets stuck on TXT verification, we remove and re-add the custom domain, Railway assigns a new CNAME, and then we have to ask the client’s IT team to update DNS again.
That’s hard to manage, especially when DNS changes are handled by the client’s IT department.
If the TXT record is publicly resolvable, is there a way to re-trigger Railway’s TXT verification without deleting and re-adding the custom domain?
Alternatively, could Railway keep the same CNAME target when a domain is removed and re-added?
Thanks!
22 days ago
Heads up for you: Via GraphQL one can only see data in "dnsRecords" that references the CNAME record – no info on the TXT record.
"{
"data": {
"domains": {
"serviceDomains": [
{
"id": "redacted",
"domain": "redacted.up.railway.app"
}
],
"customDomains": [
{
"id": "redacted",
"domain": "immobilien.redacted.redacted",
"status": {
"dnsRecords": [
{
"hostlabel": "immobilien",
"requiredValue": "redacted.up.railway.app",
"currentValue": "redacted.up.railway.app",
"status": "DNS_RECORD_STATUS_PROPAGATED"
}
],
"certificateStatus": "CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP"
}
}
]
}
}
}"
22 days ago
For the API, the TXT content is located under verificationToken under status.
Status changed to Solved 0x5b62656e5d • 9 days ago