Customer Domain Verification: Scheduled Polling and Triggered Rechecks for Tenant Onboarding

Fintech tenants receive a subdomain from the platform, which is activated through the platform's DNS change. For customer-owned hostnames, the platform conducts scheduled verification in the background and offers a customer-triggered recheck as an additional control. However, a button alone is insufficient to confirm that a DNS change has reached the resolver performing the check.

The platform uses the DNS ownership boundary to determine the default verification method. A customer-owned zone undergoes scheduled checks, supplemented by a rate-limited recheck. The platform provides separate states like awaiting DNS, verified, and ready to serve, along with the last observed result and check time. It never treats a failed lookup as a permanent rejection, as the customer may still be editing the zone.

The platform recommends controlling ownership first, with customer-triggered rechecks used only when necessary. The feedback latency is a secondary criterion. While a customer may have published the correct record, a resolver might still be returning an earlier absence. A recheck reports what this verifier observed, not a guarantee of global propagation.

The verification worker maintains a small state machine, persisting the hostname, tenant ID, challenge, attempt count, next check time, and last observation. A customer-initiated recheck moves an eligible record forward in the queue, calling the same verifier. This ensures that both scheduled jobs and manual rechecks adhere to the same verification rules and avoid disagreements.

In summary, the verification process prioritizes DNS ownership, uses scheduled checks with customer-triggered rechecks as an optional control, and maintains transparency through distinct states and clear status updates.