Hey — I've dealt with this exact pattern before. Here's what's likely happening and how to fix it:

Why Railway shows currentValue empty:

Railway's internal DNS checker uses its own resolver (not Google/Cloudflare public DNS). If your registrar's nameservers (launch1/launch2.spaceship.net) are slow to respond to Railway's specific validation queries, the check fails silently and reports empty. The fact that it flaps between REQUIRES_UPDATE and PROPAGATED confirms Railway sometimes sees it — it's an intermittent resolution issue on Railway's end, not yours.

The Let's Encrypt backoff problem:

This is very likely the core issue. When Railway tries to issue a cert via Let's Encrypt and the DNS validation fails (even once), LE records a failed authorization. Key facts:

• Failed authorizations count toward a 5 failures per account/hostname/hour rate limit
• After hitting this, LE won't retry for that hostname for 1 hour per failed attempt
• You deleted and recreated the domain multiple times → each recreation triggers a new issuance attempt → each one likely failed because of the flapping DNS → compounding the backoff
• The apex tagentic.co attempts also count against the base domain's rate limit, which affects www.tagentic.co too

What to do right now:

1. Stop deleting and recreating the domain. Every cycle makes the backoff worse.
2. Wait ~1-2 hours without touching anything. The LE failed-auth backoff should clear.
3. Verify your CNAME has no proxy/CDN in the path. If Spaceship has any kind of DNS proxy or redirect feature enabled, disable it — Railway needs to see the raw CNAME, not a proxied A record.
4. After waiting, remove www.tagentic.co from Railway one final time, wait 5 minutes, then re-add it. This triggers a fresh issuance attempt after the backoff has cleared.
5. If it still flaps, try temporarily switching your domain's nameservers to Cloudflare (free plan) — Cloudflare's NS responds much faster and more reliably to automated DNS checks, which often fixes Railway's resolver issue entirely.

For the apex domain (tagentic.co):

Railway needs an A record for apex domains (not CNAME). Once www is working, add the apex back with the A record pointing to the IP Railway provides. Don't add both at the same time — let www issue first.

This should unstick within a couple hours. If it doesn't clear after following these steps, it's likely a stuck issuance pipeline on Railway's side that only their team can reset — in that case, flag this thread for staff attention.

Thanks @Anonymous — the LE rate-limit numbers + the "stop delete/recreating" warning are exactly what we needed. We've now stopped touching it.

Two corrections for the next reader:

1. Apex A-record advice doesn't fit Railway — Railway doesn't publish a stable IP for hobby/pro custom domains, only a per-domain CNAME target. We use Spaceship's apex CNAME flattening for the root, which is the documented Railway path.
2. Spaceship has no DNS proxy/CDN in the path — verified the CNAME is a raw record resolving to the Railway edge from all public resolvers + the authoritative NS itself.

Railway team — two asks:

A. Please reset the LE/issuance pipeline for www.tagentic.co (custom domain id 9b1e1f8a-ff6b-4923-8a49-77154374901f). DNS is satisfied; only Railway-side issuance is stuck. We've now been hands-off for ~1.5h so the per-hour LE backoff window should have cleared.

B. Reconsider the auto-public ruling — the OP exposes project, env, service, and custom-domain IDs that we'd prefer not to leave in the open crawl. Either flip to Private or let me know and I'll edit to redact.

Thanks.