Publish your mail provider’s authentication records through PD Cloudflare DNS. SPF, DKIM and DMARC serve different roles, so use the exact type, hostname and content supplied for your domain rather than treating them as one interchangeable TXT value.

Review the existing records

Ask the mail administrator for the intended SPF policy, DKIM selector/type and DMARC policy. Check records already present for those names before adding another set. Preserve unrelated TXT verification records.

An SPF policy needs to account for the senders your domain actually uses. Do not append a second SPF policy for another mail service without having the mail administrator combine the intended policy.

Publish the supplied values

1. Open the intended zone through the enabled DNS Manager client-navigation link, or Manage DNS on the linked domain/service, or Cloudflare DNS → Zones → Records as staff.
2. For SPF, review the existing TXT policy at the requested name and edit or add the agreed single policy.
3. For DKIM, select the type the provider requests, commonly TXT or CNAME, and use its exact selector hostname and content/target.
4. For DMARC, add or edit the TXT record at the name the mail administrator specifies, commonly _dmarc, using the agreed policy value.
5. Save each change and confirm its complete hostname, type and content.
6. Use the mail provider’s verification tools to confirm each record separately.

Do not substitute a DKIM public-key value for a CNAME target, or publish the record at the root just because the domain itself is being authenticated. Check the final full name to avoid appending the domain twice.

Verify without inventing a mail policy

Successful publication and successful mail authentication are separate checks. Test through your mail provider and inspect its reported result. A strict DMARC policy can affect legitimate senders if SPF/DKIM alignment is not ready; obtain the intended policy from the person managing the mail service rather than copying a restrictive example blindly.

Changing authentication records does not create a mailbox, change MX delivery targets or guarantee inbox placement. Use the MX guide when changing where incoming messages are delivered.

If a change is refused

Check for a conflicting record type/name, a protected forwarding-managed record, a zone lock or package limit. Your hosting team should inspect the specific error and compare it with the saved record and intended mail configuration. Avoid deleting a working mail policy simply to make a new row save.

Check the saved mail policies

Your hosting team and mail administrator should compare the provider-supplied SPF policy, DKIM selector/type and DMARC hostname/policy with the actual saved records and authoritative answers. Check CNAME conflicts and any managed record, lock or allowance before changing a working mail policy. Mail-provider verification and sender alignment are separate from a successful DNS save. Do not invent a stricter mail policy or delete unrelated verification records as a repair.

See the PD Cloudflare DNS WHMCS guide for related tasks, or explore the module.