Use a TXT record to publish the proof requested by an external service. PD PowerDNS supplies the DNS editor; the service requesting verification decides when the proof is accepted.

Copy the exact request

Obtain the current record name and complete content from the intended account. Some requests use the domain root, while others use a named prefix. Check the resulting full hostname rather than assuming every verification record belongs at the root.

Keep account-specific verification values private when sharing screenshots. Do not reuse another customer’s token or publish an example value as if it were a real verification request.

Publish without removing unrelated TXT records

1. Open the correct provider and zone in PowerDNS → Zones.
2. Review existing TXT records at the requested name.
3. Choose Add record → TXT and enter the requested name, content and TTL.
4. Save and read back the resulting full name and value.
5. Check authoritative DNS before asking the external service to verify again.

Multiple unrelated TXT values may legitimately share a hostname. Preserve existing verification and mail-authentication values. PowerDNS stores a common TTL for the name/type set, so review that value after changes.

Diagnose a pending verification

Check the authoritative nameservers, exact requested hostname, latest token and previous cache TTL. A successful module write does not prove the external service has checked the new answer yet.

For an ACME DNS-01 challenge, publish the current value at the requested challenge name and manage its cleanup through the intended integration. If automation is used, see the module API guide; never distribute an upstream PowerDNS key to a customer to automate a single proof.

Check disabled native record members before editing

PowerDNS can retain disabled members in a native record set. The module displays enabled members of recognised types and rebuilds an affected set from enabled members when writing it. Disabled members in that same set can therefore be removed by a module change. If your deployment uses disabled records, have your PowerDNS administrator preserve and review the native set through your authorised server process before editing it here. Module snapshots and BIND exports omit disabled members, so they do not preserve that native state.

See the PD PowerDNS Blesta guide for related tasks, or explore PD PowerDNS.