Use PD DNS Manager templates to apply a repeatable set of records to customer zones. A template is useful for your standard hosting configuration, but its values must still describe the destination services you intend to provide.

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.

Build the template

1. Open DNS → Templates and create a named preset.
2. Add each intended record’s type, name, TTL and value.
3. Use supported merge fields where the value should depend on the zone.
4. Review mail priorities and service-specific fields before saving.
5. Apply the template to a controlled zone and inspect the resulting records before using it widely.

The supported merge fields include {domain}, {sld}, {tld}, {ns1} through {ns5} and {ip}. The IP field comes from an existing apex A record. A value that cannot be resolved is skipped, so a template depending on an apex address should not be assumed to create that prerequisite for itself.

Apply it to the intended zone

A template can be selected when creating a zone or applied from an existing zone’s records page. Review which records are already present. Template application adds the intended records and recognises matching records; it is not a promise to replace every old value at the same name. Review added, skipped, failed and over-allowance counts separately before another application.

Editing the template does not prove that zones where you previously applied it have changed. For a deliberate fleet-wide change, use the separate bulk-operation workflow after reviewing the target set.

Keep presets and mail policy distinct

Where available, Quick set-ups offers service-oriented presets. Compare any mail preset with the provider’s current instructions and your own tenant/domain values rather than assuming a generic example completes verification. An SPF lockdown describes a domain that sends no mail; it should not replace the policy of an active sender.

Review Activity and the actual records if an application is incomplete. A missing merge value, a provider restriction or a record quota needs a different correction from a duplicate. Keep a snapshot before changing a working configuration.

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