Use PD Google Cloud DNS to publish the TXT value requested by a domain-verification service. The module writes DNS data; the requesting service decides whether its ownership check passes.

Check the latest request

Keep the requested type, full hostname and latest verification value. An apex record differs from a record beneath a service label. Avoid repeating the zone suffix accidentally when entering a complete hostname.

Open the intended zone’s Records page, or use My Tools in the client portal, then the DNS manager. Check that its project and assigned nameservers match the actual public delegation.

Save the exact value

1. Search for TXT records at the requested name.
2. Select TXT in the type-aware editor.
3. Enter the correct name, TTL and complete content.
4. Save without removing unrelated SPF or other verification values.
5. Reload and compare the result with the latest service request.
6. Confirm authoritative publication, then run the requesting service’s check.

Several TXT values at the same name can be legitimate and share a record-set TTL. Adding one verification value is not a reason to replace the entire set. Preserve long values rather than shortening them to fit a displayed row.

Diagnose a failed check

Separate a refused save from a saved value that the service cannot see. A refusal can concern permissions, quota, policy or a zone lock. A visibility failure can concern the wrong managed zone, a repeated name, cached answers or a newer request from the service.

Keep account-specific verification strings out of public diagnostic screenshots where they are unnecessary. Do not remove working mail records or recreate the zone to clear a single warning. Follow the service’s retention guidance after verification. See the project and zone-identity checks if the expected zone cannot be opened.

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