The domain is missing its TXT ownership-verification record, which is why the certificate is stuck in VALIDATING_OWNERSHIP. Custom domains require both a CNAME (yours is correctly propagated) and a TXT record at _railway-verify.overskud.seanbaldwin.com with the verification value shown on the domain's settings page in the dashboard. Once that TXT record propagates, the certificate will advance and the edge will begin routing traffic to your service.

Thanks, but I don't think the TXT record is right — and I have something more specific.

On the TXT record: your own API doesn't ask for one. Querying the custom domain returns exactly one required record, a CNAME for traffic routing, with no ownership/verification record of any kind:

{
  "domain": "overskud.seanbaldwin.com",
  "status": {
    "certificateStatus": "CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP",
    "dnsRecords": [{
      "hostlabel": "overskud",
      "recordType": "DNS_RECORD_TYPE_CNAME",
      "requiredValue": "dxxej2qk.up.railway.app",
      "currentValue": "8wczaonx.up.railway.app",
      "status": "DNS_RECORD_STATUS_PROPAGATED",
      "zone": "seanbaldwin.com",
      "purpose": "DNS_RECORD_PURPOSE_TRAFFIC_ROUTE"
    }]
  }
}

There's no _railway-verify record in the dashboard or in the API response, so I've not added one.

What I think is actually wrong: look at currentValue above. It reads 8wczaonx.up.railway.app — that was the target of the previous custom domain record (ae340dd3-3c66-4cf1-babb-9826a37dc86b), which I deleted at ~08:36 CEST. It has not been in my zone since.

My DNS only ever contains one record, and every resolver agrees:

• Authoritative zone (HostGator, read via cPanel API): a single CNAME, overskud → dxxej2qk.up.railway.app., TTL 14400. No other record for that hostname, no A/AAAA, no TXT.
• Google DNS (dns.google): dxxej2qk.up.railway.app.
• Cloudflare DNS (cloudflare-dns.com): dxxej2qk.up.railway.app.

And your API's own reading of it is flapping:

• 10:04 CEST — currentValue: "dxxej2qk.up.railway.app" (matching requiredValue)
• 11:05 CEST — currentValue: "8wczaonx.up.railway.app" (the deleted domain's target)

Nothing changed in my zone between those two readings.

So it looks like the DNS check is holding stale state from the deleted domain record, which would explain why ownership validation never completes even though status says PROPAGATED. Meanwhile the edge returns 404 {"message":"Application not found"} for the hostname and serves the default *.up.railway.app cert.

Domain id: 006a9247-e432-435a-860b-b7a8c2163714

Project: 45de0d7b-37df-46df-97a9-e36fa7b7b50b / service 8a7aa7b4-cee2-474d-b263-583e66561c16

Could a human take a look and clear the cached DNS state for this domain? Happy to run any check you want from my side.

The verification TXT record is the blocker. Custom domains require both a CNAME and a TXT record. Your CNAME is correct and propagated, but without the TXT the domain stays unverified and the edge returns "Application not found" with the wildcard cert.

The TXT value isn't inside status.dnsRecords. It's returned separately in status.verificationToken (docs). You can also find it on the domain's settings page in the dashboard. The record goes at _railway-verify.overskud.seanbaldwin.com.

On the flapping currentValue: we see the same stale value on our side from the deleted domain record. The CNAME status reads PROPAGATED regardless, so adding the TXT record is the step that unblocks verification. Once the TXT propagates and the domain verifies, the certificate and routing follow automatically. If issuance doesn't advance after that, railway domain certificate retry overskud.seanbaldwin.com via the CLI retriggers it.