TXT record verification

The service generates a random token tied to one account and one domain, and asks the owner to publish it in a TXT record, usually at an underscore-prefixed name such as _dodomain-challenge.app.customer.com. The service then queries the zone's authoritative nameservers. If the exact value is there, whoever asked controls the zone's DNS, because only they could have written it.

The pattern is everywhere. Google Search Console and Microsoft 365 verify domains this way, and certificate authorities use the same idea for the ACME DNS-01 challenge (RFC 8555), which publishes its token at _acme-challenge. The underscore prefix keeps these records out of the way of real hostnames.

A SaaS product that serves customers' domains is making a decision on every request: this hostname belongs to that tenant. If anyone can claim any hostname, that decision can be wrong in two dangerous ways.

• Domain claiming. Without proof, an attacker can add app.victim.com to their own account before the real owner does. When the victim later points DNS at your product, their traffic lands in the attacker's tenant.
• Subdomain takeover. A customer leaves, deletes their account, but never removes their CNAME. The DNS still points at your platform. If your product lets a new account claim that hostname on the strength of "the CNAME resolves to us", the newcomer now serves pages, and can set cookies, on the victim's domain.

A CNAME alone cannot prevent either, because it proves only that someone pointed the name at your platform, not which of your tenants they meant. A per-tenant token in a TXT record does: it binds the hostname to one account. DoDomain's verification goes one step further and reads the records from the authoritative nameservers rather than trusting that they were applied.

Verification is a moment; control of a domain changes over time. Domains expire, are sold, and move DNS hosts. A product that verifies once and never looks again will keep serving a hostname long after its owner stopped pointing it there. Re-checking the records on a schedule, and treating their disappearance as a change that needs action, closes that gap. DoDomain re-verifies every connected domain on every plan and sends a signed connection.failed webhook when records stop matching.

• One name can hold several TXT records, so a verification token can sit beside SPF or other tokens. It cannot sit at a name that has a CNAME, which is another reason for the underscore-prefixed name.
• Values longer than 255 characters are sent as several strings that receivers join back together. That is one record, not two.
• Read the authoritative answer, not a cached one: a public resolver may still hold the "no such record" answer from before the token was published.

The DNS propagation checker reads a TXT record from the authoritative nameservers and three public resolvers at once; the SPF record checker handles the other common TXT record.

• DNS propagation checker

  Confirm a verification TXT is published at the source before asking a service to check it.

• SPF record checker

  The other TXT record most domains carry, with its own ten-lookup limit.

• Multi-record and email records (docs)

  Where DoDomain places the ownership TXT beside a CNAME or an apex A record.

• Domain Connect

  How a provider can write the verification record for the user in one click.