DNS verification

DNS verification is the proof step in custom-domain onboarding. Before your SaaS starts serving traffic for acme.com (or even issuing a TLS cert), you need to confirm the person claiming to own acme.com actually controls its DNS.

Two common verification patterns

TXT record verification

You issue the customer a random token: yourapp-verification=abc123. They publish it as a TXT record:

_yourapp.acme.com.   TXT   "yourapp-verification=abc123"

Your backend polls the DNS for this record. When it matches, the domain is verified.

Pros: works without affecting the live serving of the domain. The customer can do this on Monday without breaking their site, then add the actual CNAME on Friday.

Cons: extra step.

CNAME verification

You tell the customer to set the actual CNAME they need to serve traffic:

acme.com.   CNAME   edge.yourapp.com

Your backend resolves the CNAME. When it points at your edge, you treat the domain as verified.

Pros: one fewer step.

Cons: only works for the hostname being connected, not the apex. And the customer can't "preview" the setup; the moment they CNAME, their site is in your hands.

Best practice for SaaS

Offer both. Use TXT verification for the apex (where CNAMEs aren't allowed anyway). Use CNAME verification for subdomains.

Why not just trust the customer?

Two reasons:

1. Cert issuance requires it. Let's Encrypt won't issue a cert for a domain you haven't proven control of. Even if you tried to forge it, the ACME challenge would fail.
2. Domain hijacking. Without verification, anyone could add google.com to your SaaS and have you start trying to serve traffic for it. Embarrassing at minimum, legally risky at worst.

Usually verification takes 30 seconds to 5 minutes after the customer adds the record. Sometimes up to an hour if their DNS provider has a long default TTL.