How DNS TXT Domain Verification Works

Before any responsible scanner sends a request to a website, it needs a reason to believe the person asking is allowed to. The most common proof is a DNS TXT record: a small piece of text you publish in the domain's DNS that only someone with control of the domain could have put there. Here is what that proves, how to do it for a client, and the ways it goes wrong.

What a TXT record is

DNS is the system that maps names like shop.example.com to servers. Besides addresses, a domain's DNS can hold TXT records: free-text entries attached to a name. They were originally meant for human notes, and are now used mostly by machines, for email authentication (SPF, DKIM, DMARC) and for exactly this kind of ownership proof. Google Search Console, Let's Encrypt's DNS challenge, Microsoft 365 and most SaaS products that need to confirm you control a domain all use the same mechanism.

What the proof actually says

A verification service generates a random token tied to your account and the domain, for example _scanbastion.shop.example.com TXT "7f3a9c…". You add that record. The service looks it up from the public DNS. If the record is there with the right token, the service concludes: someone with permission to edit this domain's DNS authorised this account.

That is a strong statement, because DNS edit rights are closely held. A web developer may have FTP access to a site, a marketing agency may have the CMS log-in, but the ability to change DNS usually sits with the domain owner, their IT provider or whoever manages the registrar account. Asking for a TXT record therefore pulls the actual owner into the decision, which is the point.

What it does not say

It does not prove the website and the domain are run by the same people. A domain can point at a hosting provider, a CDN or a SaaS platform operated by someone else. Scanning still sends traffic to that infrastructure, which is why responsible scanners keep scans bounded regardless of verification.
It does not cover other hostnames. Verifying shop.example.com does not authorise api.example.com. Services differ on whether verifying the bare domain covers subdomains; read the policy of the service you use. ScanBastion's Responsible Scanning Policy describes its approach.
It is not a contract. The record proves control at the moment it was checked. Your engagement letter or written authorisation is what proves you were asked to assess the site, and you should keep that too.

Adding the record for a client domain

In practice the step-by-step is the same everywhere; only the DNS provider's screen differs.

Get the record from the service. It will give you a host (often a prefixed name like _scanbastion) and a value (the token). Copy both exactly.
Find out who controls DNS. Ask the client where the domain is registered and whether DNS is hosted there or elsewhere (Cloudflare, Route 53 and the hosting panel are common). The NS records of the domain, visible with any DNS lookup tool, tell you which provider answers for it.
Send the client a one-paragraph request. Something like: "To authorise security scanning of shop.example.com, please add a DNS TXT record with host _scanbastion and value 7f3a9c…. It has no effect on the website or email; it is a proof of authorisation that we can remove afterwards." Including why makes it far more likely to be done this week rather than next month.
Wait for propagation. New records are usually visible within minutes, but a TTL of several hours on a previous lookup can delay it. Most services let you re-check on demand.
Keep it in place. Services generally re-verify periodically. If the record is removed, scanning is paused until it returns, which is a feature: it gives the owner a kill switch they understand.

Common mistakes

Host entered as a full name when the panel wanted a relative one, or vice versa. If the panel appends the domain automatically, entering _scanbastion.shop.example.com produces _scanbastion.shop.example.com.shop.example.com. Look at the resulting record before saving.
Quotes around the value. Some panels want them, some add them. If verification fails, check whether the published value has doubled or missing quotes.
Editing the wrong zone. The registrar's DNS panel is not authoritative if the NS records point elsewhere. Changes there do nothing. This is the single most common cause of "I added it but it doesn't work".
Subdomain delegated separately. shop.example.com may have its own zone on a different provider from example.com. Check where the specific hostname is answered.
Replacing an existing TXT record. A name can hold several TXT records. Add, do not overwrite, or you may break the client's email authentication.

Why scanners insist on it

Unauthorised scanning is, in many jurisdictions, illegal, and in all of them it is unprofessional. A scanner that will point itself at any URL you type is a liability for the person running it and the people operating it. Requiring DNS verification costs a few minutes per domain and buys three things: the owner knows and agreed, there is a timestamped record of that agreement, and the owner can revoke it at any time without talking to anyone. For an agency, it also makes the authorisation conversation part of onboarding rather than an afterthought.