Use a TXT record to prove control of a domain to the service requesting verification. PD DNS Manager publishes the requested value at your DNS provider; the requesting service decides whether the domain is verified.

Before a change, confirm the provider connection and the actual zone it resolves. With Route 53, name-based operations resolve the first matching hosted-zone name; selecting a familiar domain is not sufficient when AWS holds multiple zones with that name. Have your AWS administrator compare the hosted-zone ID, records and assigned nameservers before proceeding. With Google Cloud DNS, the current connection derives the managed-zone name from the domain. An existing zone with a different native name can appear in a list yet fail to open correctly; establish that mapping with your Google Cloud administrator instead of creating a duplicate zone.

For a PowerDNS backend, module reads and zone-file snapshots omit disabled native record values. Editing an affected record set can rebuild it from the enabled values. If your hosting team uses disabled records, preserve and review the native record set with your DNS administrator before module changes; use your established native management process where those values must be retained. A module export is not a complete backup of those disabled values or other provider settings.

Identify the exact hostname

Keep the service’s record type, full hostname and latest verification value. A record at the zone apex differs from one under a verification label. Do not paste a full hostname into a field in a way that repeats the zone name.

Open DNS → Zones → Manage records for the domain, or use My Tools in the client portal, then the DNS manager as the customer. Check the domain’s authoritative nameservers and make sure this is the zone the public DNS actually uses.

Publish the value

1. Search for the intended name and TXT type.
2. Select TXT in the type-aware editor.
3. Enter Name, TTL and the complete Content from the service.
4. Review the name once more, then click Save record.
5. Reload the zone and compare the saved value with the latest request.
6. Return to the requesting service and run its verification check.

Keep unrelated TXT records such as SPF and other service verifications. More than one TXT value at a name can be intentional; do not replace the whole set simply because a new request uses the same hostname.

Diagnose a failed check

Separate a failed save from a saved record that the service cannot yet see. A refused save can concern policy, quota or a locked zone. A public lookup that lacks the value can concern the wrong authoritative provider, an incorrectly repeated hostname or caching.

If the service generated a new verification value, use that request rather than an older screenshot. Keep account-specific verification values out of public diagnostic attachments where they are not needed. After the service confirms verification, follow its retention instructions instead of assuming the record should be deleted. See the record-editing guide for address and alias records.

See the PD DNS Manager Blesta guide for related tasks, or explore the module.