Publish the mail provider’s sender-authentication records through PD PowerDNS. DNS publication and actual mail-server signing are separate tasks: a DKIM record cannot make an unsigned message signed.

Prepare the authoritative values

Obtain the SPF policy for the sending domain, the DKIM selector and supplied record type/content, and the intended DMARC policy. Confirm which systems send mail before changing an existing policy. Keep current records available for comparison.

Add the requested records

1. Open the intended zone’s Records view.
2. Review the existing SPF TXT value at the sending domain.
3. Update the single intended SPF policy rather than adding conflicting SPF policies.
4. Add the DKIM TXT or CNAME requested for the exact selector name.
5. Add or edit the DMARC TXT record at the requested DMARC name.
6. Save and compare names, values and TTLs with the mail provider’s request.

Do not replace every TXT record just to change SPF. Keep unrelated verification values. For CNAME-based DKIM, do not place an ordinary TXT value alongside the alias at the same name.

Check a real message

Inspect authoritative DNS, then review a test message’s authentication results with the mail administrator. Compare the actual sender domain and DKIM selector with the records you published.

An unexpectedly strict DMARC policy can affect delivery where sending systems are not aligned. Use the intended policy from the mail administrator and check the actual outcome rather than copying a stronger example. If publication succeeds but authentication fails, retain redacted message results and exact selector/domain details; do not send full customer messages or unrelated account exports.

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 WHMCS guide for related tasks, or explore PD PowerDNS.