1. Open DNS Manager > Record sets and create a set with a clear purpose, such as the starting records for one hosting service.
2. Add records using the record editor. Select the type, enter the name and data, and set the TTL. Supply priority and other type-specific fields where the editor requests them.
3. Use supported variables for values that differ by domain or assigned service. Examples include {$domain}, {$ip}, {$serverhostname} and the configured nameserver variables.
4. Mark a record as protected only when customers genuinely should not change it. Explain the resulting restriction in the service documentation.
5. Save the set and preview it using a real eligible test item. Confirm that every variable resolves to the intended value.

Unknown variables and unresolved empty values are rejected. Do not place a shared hosting server address in a template that will also be used for unrelated dedicated-IP services. Check IPv4, IPv6 and hostname fields independently.

Edit the DNS package and select the administrator-owned default under its starting-records settings. Use Items to connect that package to actual WHMCS products, product addons or domain TLDs. The product relationship belongs to the package; do not assume there is a separate direct template-to-product binding screen.

The default set is applied by the package's creation workflow. Review registration, transfer and hosting-activation triggers so the necessary service data exists when variables are resolved.

For a package whose hosting service supplies a valid public IPv4 address, a small starting set can contain these two records. Use a TTL accepted by every selected provider; 300 seconds below is an illustration, not a required package default.

Preview the set against your eligible test service. Check that the apex and www names resolve once, without a doubled domain suffix, and that {$ip} is the intended website address. Do not apply this unchanged to an IPv6-only service or overwrite an existing www record serving another application. This example deliberately leaves MX and mail-authentication records to the actual mail provider configuration.

Create a zone for a test domain and inspect the resulting A, AAAA, CNAME, MX and TXT records. Verify each public service that the template is intended to support. An email template needs the mail provider's current exact records, not a guessed SPF policy or a sample DKIM key.

Check wildcard entries and apex aliases carefully. A CNAME cannot normally coexist with other data at the same owner name, and provider-specific flattening is not a universal DNS capability.

Editing a record set changes future use of that set; it does not automatically rewrite every existing zone. Use an explicitly reviewed bulk or changeset workflow for existing customers. Preview merge or replacement effects, preserve unrelated verification records and keep a rollback copy before a widespread change.

• Offer selected administrator DNS record sets to customers
• Build a DNS package for hosting products, addons and domain TLDs
• Review and apply DNS changesets with a clear recovery path
• Create and apply reusable DNS record sets