Domain verification establishes that a requester controls a domain or a specific part of its namespace. A service typically generates a challenge value and asks the requester to publish it at a particular DNS name. The service then queries DNS and checks the result against its expected value. This demonstrates control of the required DNS location; it does not establish legal ownership of the domain, validate a business identity, or prove that an application is secure.
TXT records are commonly used because they can carry arbitrary verification strings without changing application routing. For example, a service might require a TXT record at example.com containing a unique token, or at a dedicated name such as _verify.example.com. Other services require a CNAME that points a generated name to a service-controlled destination. Follow the exact record type, owner name, and value supplied by the verifier. A TXT token cannot replace a required CNAME merely because both can support verification workflows.
Distinguish verification records from other DNS records tested in networking scenarios. An A record maps a name to an IPv4 address, while an AAAA record maps it to an IPv6 address. A PTR record maps an address back to a name in a reverse DNS zone, usually controlled by the address-space owner or its delegate. Reverse DNS can support mail-system reputation checks, but it is not interchangeable with forward-domain verification. A CNAME creates an alias to another DNS name. An Amazon Route 53 alias is a provider-specific record capability, not a separate standard DNS record type; an alias A or AAAA record can route traffic to supported targets but does not replace a requested verification token.
Publish the challenge in the zone that is actually authoritative for the requested name. Creating a public hosted zone alone does not make it authoritative: the parent zone must delegate to its name servers. If dev.example.com is delegated to another account, a challenge beneath that subdomain normally belongs in the delegated zone. For externally validated public domains, putting the token only in a private hosted zone or an on-premises split-horizon view will not make it visible to the public verifier. Resolver forwarding across a VPN or Direct Connect connection provides DNS reachability, not evidence of control in public DNS.
In a multi-account environment, an application team can request a certificate while a central DNS team publishes its validation CNAME. This separates application permissions from control of the corporate namespace, but introduces coordination and renewal dependencies. Use narrowly scoped DNS change permissions, review record names carefully, and automate approved changes where possible. DNS control is security-sensitive because an attacker who can publish the required challenge may be able to authorize a certificate or claim a domain in another service.
Troubleshoot failures by querying the authoritative name servers and a public recursive resolver for the exact record name and type. Check delegation, accidental duplication of the zone suffix, conflicting CNAME data, and cached negative responses. Lowering a TTL does not immediately remove previously cached answers. Retain records required for ongoing validation or automatic renewal; remove obsolete records according to the service's lifecycle requirements. Some services also support HTTP-file or email challenges, but those methods have different reachability and operational dependencies.
Amazon Route 53