The likely smoking gun: your TXT record is on the wrong host

You have the verification TXT at @ (apex). Railway's railway-verify TXT isn't an apex record — it's hosted on a _railway-verify-prefixed label matching the subdomain you're adding. Across current Railway cases the pattern is consistent: for api.follow-the-herd.com the record is _railway-verify.api TXT = railway-verify=..., and similarly _railway-verify. for other subdomains. Railway

For www.theprofile.agency, Railway is querying _railway-verify.www.theprofile.agency — and finding nothing, because your token is sitting at the apex. That single mismatch explains the whole chain: verification never completes → ACME never fires → "Waiting for DNS update" forever → and the domain never gets committed into serviceDomains (which only happens post-verification; that's also why it shows in the dashboard but not the API — it's in a pending, uncommitted state, not a real persisted record).

The CNAME (www → 4u98cm2b.up.railway.app) looks correct, so just the TXT host is off.

Fix

Open the domain's "Configure DNS Records" / see instructions modal in Railway and copy the exact TXT host string — that's the source of truth. It should read like _railway-verify.www.

In GoDaddy, add a TXT record with host _railway-verify.www and value railway-verify=c954a78fffd8200dc644c217bd38e3dad2ee6cd8e876922c1d80c8dccc3645f5. GoDaddy auto-appends the zone, so enter _railway-verify.www, not the FQDN.

Delete the stray apex @ TXT you added — it's doing nothing where it is.

Wait ~10–15 min. Verification → cert issuance is automatic once Railway sees the record at the right host.

If it's already at the right host (or still stuck after ~1 hr)

Then it's a Railway-side verification-state desync, not DNS — which matches the dashboard-vs-API mismatch you found. The only known remedy is the clean reset, and it's what Railway staff repeatedly recommend: remove the domain from Railway and the records from your DNS provider, wait ~10–15 minutes, then re-add them. When re-adding, take the records straight from the dashboard modal so the TXT host is exact. Railway

One thing worth checking before you do that: there have been incidents where elevated queued deploys delay the domain validator — glance at Railway's status/incident banner, since if that's active, a reset won't help and you'd just want to wait it out. Railway

If a clean reset with the corrected TXT host still doesn't clear it, that's a genuine backend-state issue only Railway staff can reset. Escalate at station.railway.com with your project/service IDs (14e68f23-…) and mention the dashboard-vs-serviceDomains API desync explicitly — that detail tells them it's stuck in their verification state machine, not your DNS.