Project ID: 0674b19b-c358-44b6-b944-a775eb0d2fcb, service websites

Domains: adimmlaw.com and www.adimmlaw.com

CNAME shows verified (green) in the Networking panel; the _railway-verify TXT has shown pending (yellow) for 2+ hours. Visiting https://adimmlaw.com returns the "train has not arrived" page, Request ID 9agbKbviToyAbrIWozsQ6Q. No TLS cert provisioned (curl -sI returns empty).

DNS is Cloudflare, all records DNS-only (not proxied) — confirmed by the DNS administrator with a zone screenshot. Records resolve globally with correct names and values:

dig adimmlaw.com +short → 69.46.46.15 (Cloudflare flattening, DNS-only)

dig www.adimmlaw.com +short → svl2g815.up.railway.app

dig TXT _railway-verify.adimmlaw.com +short → "railway-verify=450c8f0e110857bc4151c905fe2a6c42889a6da73520b95eddbdb8abcd0f85b8"

dig TXT _railway-verify.www.adimmlaw.com +short → "railway-verify=6ffcb60ae5cd3b60f5a5b8a67a23c529c2ed014e022335578b46e0414d80e517"

I've seen the resolution on a similar thread (mlb-dispatch) where the TXT records were on the wrong hostnames (@/www instead of _railway-verify/_railway-verify.www). That is not my situation — my TXT records are at exactly _railway-verify.adimmlaw.com and _railway-verify.www.adimmlaw.com, confirmed both by the DNS zone screenshot and by dig (outputs above). Since the records are at the correct hostnames with the correct values, I need the verification re-triggered or diagnostics on what the checker sees.

Your AI agent reviewed this and confirmed it's a platform-level verification stuck state needing team investigation.

Requests:

Re-trigger verification for both domains, or tell me what the checker sees that doesn't match.

Please confirm whether remove/re-add preserves the existing CNAME/TXT values — DNS is managed by a third-party IT vendor, so regenerated values force another handoff I'd like to avoid.