Build a named template for the ordinary DNS records you repeatedly configure, then apply it to the intended Azure zone. Review its values against the actual hosting and mail services before using it for another customer.

Create the preset

1. Open Azure DNS → Templates and choose Add template.
2. Give it a recognisable purpose-based name.
3. Add the intended types, names, TTLs and values.
4. Review supported merge fields and any prerequisite records.
5. Save and inspect the result in a controlled zone before broader application.

The documented {domain} field represents the zone name; {ip} depends on an available apex address. Do not assume a dependent value can be resolved where its prerequisite does not exist.

For a template MX value, use the documented priority-before-target form such as 10 mail.{domain}. That combined template value is different from the normal MX editor’s separate priority and target fields.

Apply and compare

Open the intended zone’s menu under Zones and choose Apply template. Check the provider/group and existing records before confirming. Read back the actual resulting records rather than treating a success message as a service test.

Matching records are skipped. Rows with unresolved merge fields are also skipped; others can fail or be blocked by the remaining customer allowance. Check added, skipped, failed and over-allowance counts individually. Application is additive; it does not mean every old value at the same name was replaced or all template edits were pushed to previously configured zones. Azure record-set rules still apply, including a shared TTL and a single CNAME target.

Keep customer-specific data separate

A reusable template should not contain another customer’s tenant verification or DKIM values. A mail preset does not create a mailbox, and a web preset does not configure a web host or HTTPS certificate.

After partial application, reconcile what was added before repeating it. A missing merge value, permission refusal and record quota need different diagnoses. Keep a current snapshot before a broad revision, and verify authoritative DNS and the affected service after applying the intended records.

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