Publish the DNS records supplied by your mail provider through PD DNS Manager. MX controls the mail destination; SPF, DKIM and DMARC publish different authentication information. Adding these records does not create a mailbox or move existing messages.

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.

Collect the provider’s exact values

Use the instructions for your own mail domain and account. Keep the complete MX set and priorities, SPF policy, DKIM selector/value and intended DMARC policy. Do not substitute another organisation’s tenant values or remove existing sending services without the mail administrator’s agreement.

Open DNS → Zones, then the zone’s records. A customer can use My Tools in the client portal, then the DNS manager. Confirm the zone is authoritative for the domain before editing it.

Add the records by type

1. Find the existing mail records and keep a copy of the intended before/after set.
2. For MX, enter Name, TTL, Priority and Target for every required destination.
3. For TXT, enter the exact name and complete provider value. SPF and DMARC are TXT records; DKIM can be TXT or CNAME depending on the provider.
4. For DKIM CNAME, use the supplied selector hostname and target, rather than pasting a TXT key into a CNAME field.
5. Save each record, then reload and compare names, types, values and priorities with the provider’s instructions.

Keep one intended SPF policy at a hostname; review existing senders when combining a policy. A DKIM selector is part of the name. DMARC enforcement is an operational choice, so do not change it merely to make a checker stop reporting a warning.

Verify DNS and actual mail separately

Check the published authoritative records and the mail provider’s domain-validation result. Then test inbound delivery and the authentication results on a controlled message. Correct TXT publication alone does not promise inbox placement.

For Cloudflare zones, mail-host address records that must receive mail directly need the appropriate DNS-only configuration. A forwarding-managed MX should be changed through the forwarding feature that owns it. If a save is refused, inspect its policy/lock/quota error before retrying; see the client record-policy guide.

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