Your TXT record is malformed, it starts with ailway-verify=, while it should start with railway-verify= (missing an 'r'). Make sure you are clicking the copy button when getting the value of the TXT record instead of manually selecting the text.

Thanks for spotting that. On the record at my host, it actually shows the 'R' but for some reason its propagating without the 'R'. Any idea what could cause that?

I don't know what the cause for this. But I do recommend you remove your custom domain and all its related DNS records, and add again.

I have tried that already, removing the domain and then adding it again and hour later... I'm trying another fix, Ive added quotation marks around the record as apparantly some hosts remove the 1st didgit when there is a = sign in the record. also waiting for my host to confirm this, waiting for it to propagate.

That didn't work, so now AI suggested on inserting only the string "c47cec99500af71f16816270a0d61198c1a0d8474d7abee9768cae9f21f85ad4". MXToolbox now picks up : _railway-verify.api.ficahub.co.za 4 hrs "c47cec99500af71f16816270a0d61198c1a0d8474d7abee9768cae9f21f85ad4" - So hoping Railway accepts it instead of "railway-verify=c47cec99500af71f16816270a0d61198c1a0d8474d7abee9768cae9f21f85ad4" - fingers crossed.

i looked it up myself just now on both google and cloudflare resolvers and the record is STILL coming back as:

railway-verify=c47cec99500af71f16816270a0d61198c1a0d8474d7abee9768cae9f21f85ad4

so yeah, the leading r is genuinely getting eaten at the dns level, even with the quotes. your panel shows the r but whats actually being served drops it. here's the answer i'd post:

i pulled your record from a couple public resolvers and it's still serving ailway-verify=... (no r), so nothing's landed yet. two things:

first, drop the "just the hash string" idea, that wont work. railway is matching on the full railway-verify= value, so a bare c47cec... will never verify even if mxtoolbox shows it. you'd just be trading one failure for another.

your nameservers are ns.otherdns.net / .com / ns.dns1.co.za, and that panel is straight up stripping the first character of the TXT value (the r). quotes didnt fix it, removing+readding didnt fix it, cuz its the host mangling output not your input.

the hack that actually beats it: since the host eats exactly one leading char, give it one to eat. set the TXT value to a DOUBLE r:

railway-verify=c47cec99500af71f16816270a0d61198c1a0d8474d7abee9768cae9f21f85ad4

when the host strips the first char it propagates as railway-verify=... which is exactly what railway wants. ugly but it works around the bug directly. after you set it, dont trust the panel, verify whats actually live (mxtoolbox or dig TXT _railway-verify.api.ficahub.co.za) and wait for the old 14400s TTL to age out before checking.

the proper fix if you dont wanna rely on a hack: move ficahub.co.za's nameservers to cloudflare (free), recreate the CNAME + the railway-verify TXT there. cloudflare doesnt mangle TXT records, and as a bonus you get clean apex/CNAME flattening. that permanently kills this class of problem instead of fighting the SA host.

your CNAME is already good (api.ficahub.co.za -> zvq7etem.up.railway.app), so the TXT is the only thing standing between you and a verified domain.