DNS template
A reusable set of DNS records you apply to many domains. Cuts the per-customer DNS setup from a 10-record checklist to a single apply.
A DNS template is a reusable set of records (with placeholders for the parts that change per domain) that you apply across many domains. Most often used by SaaS platforms onboarding customer domains, or agencies managing dozens of client zones.
What a template looks like
YAML or JSON example:
name: yoursaas-customer-domain
description: Standard records for connecting a customer domain to Your SaaS
records:
- host: "@"
type: ALIAS
target: "edge.yoursaas.com"
ttl: 300
- host: "www"
type: CNAME
target: "edge.yoursaas.com"
ttl: 300
- host: "_acme-challenge"
type: CNAME
target: "{{customerSlug}}.validation.yoursaas.com"
ttl: 60
- host: "@"
type: TXT
target: "yoursaas-verification={{verificationToken}}"
ttl: 300
Apply this template to customer.com with customerSlug=acme and verificationToken=Bk9X.... The four records get written. Repeat for the next customer.
Two flavors
- Internal templates in tools like Terraform, OctoDNS, DNSControl. You manage your own DNS this way.
- External templates in the Domain Connect protocol. The SaaS publishes a template; the customer's DNS provider applies it after user consent.
What templates are good for
- Custom-domain SaaS onboarding. Customer adds a domain in your dashboard; you apply your standard template to their zone (via Domain Connect on supported providers, or by emailing them the record list otherwise).
- Multi-tenant DNS for the same product. Identical record set across 500 white-label customer domains. Templates let you change something once and re-apply across all.
- Standard zone setup at a registrar. "Every new domain we register gets these MX records, this SPF, this DMARC." Template applied at registration time.
- Onboarding services across an organization. Setting up email auth (SPF, DKIM, DMARC), monitoring (CAA), and observability (TXT verification for various SaaS tools) as a standard bundle.
Limitations
- Templates work best for record types that don't have inter-record dependencies. SPF flattening, DKIM key rotation, CT log monitoring all need stateful logic that pure templates don't express well.
- Templates that mix "always there" records with "optional based on config" records get unwieldy. At some point you've reinvented Terraform.
In a SaaS
For a custom-domain platform, your template is the documentation of "what we need on the customer's domain to make this work." If the template is more than 5-6 records, your setup is too complex; simplify before exposing it to customers.