Skip to content

How to Apply Plesk DNS Template Changes Safely

In Plesk for Linux, editing the DNS template affects new domains straight away. Existing domains change only when you click Apply DNS Template Changes (or Apply DNS Template for a single domain), and records that a user has added or edited are never touched. Before applying, compare the whole template with a sample zone, because every pending difference between the template and each zone is applied, not only your latest edit.

This guide is for administrators of a Plesk for Linux server that hosts many domains. If you only need one record changed on one domain, edit that domain’s DNS records instead, or contact Noiz support if your hosting is managed by Noiz.

Last reviewed: 13 October 2026, against the current Plesk Obsidian release. This guide is written for Noiz hosting and is kept current against Plesk. It complements, and does not replace, the official Plesk documentation linked below.

  • Administrator access to Plesk, and root SSH access if you use the command line.
  • A saved copy of the current template and of the zones you expect to change, kept off the server.
  • A list of which domains publish their DNS from Plesk and which use an external DNS provider, including any synchronised from Plesk.
  1. Decide whether the change belongs in the template or in one domain’s zone.
  2. Save the template and a sample of affected zones.
  3. Edit the template under Tools & Settings > DNS Settings.
  4. Compare the whole template with a sample zone to see every pending difference.
  5. Apply the change to one domain, check it, then apply it more widely.
  6. Check the result at the authoritative nameservers.

Use the template when you want to change the default for future domains, or for a reviewed set of existing domains. Use a domain’s own DNS settings when the change only concerns that domain. Remember that a record in Plesk may also be copied to secondary nameservers or an external DNS provider, so find out where each domain is actually published before you start.

The <ipv6> placeholder is replaced with the IPv6 address of the subscription the domain belongs to. Keep it. Replacing it with the server’s address typed in full would point every domain at that address, whatever its own hosting assignment. Plesk lists all placeholders in its DNS template reference.

<ipv6.mail> is the same as <ipv6>: it resolves to the subscription’s IPv6 address, not to a separate mail address. If mail for some domains is hosted elsewhere, check the mail records deliberately. How to Enable IPv6 for a Website in Plesk explains what this means for mail.

An IPv6 address written directly into the template’s SPF record is plain text and needs its own review. For example, after a server address change you might replace only ip6:2001:db8:100::10 with ip6:2001:db8:100::20 inside the existing SPF value, keeping every other mechanism, qualifier and the TTL as they are.

During a change of sending address, add the new address first, wait for the old SPF record’s TTL to pass, and remove the old address only once it no longer sends mail. SPF checks the address of the connecting server, so removing it too early causes rejected mail.

Plesk for Linux applies the template to existing zones separately from new domains:

  • All domains: Tools & Settings > DNS Settings > Apply DNS Template Changes. You choose whether to apply the changes only to zones that users have not modified, or to all zones. In both cases, records that a user added or changed are left exactly as they are.
  • One domain: Websites & Domains > the domain > Hosting & DNS > DNS > Apply DNS Template.

Two consequences matter most:

  • After a restore, migration or upgrade, Plesk treats every zone as user-modified. If your domains arrived by migration, the option for unmodified zones will skip them, and only the all-zones option applies the change.
  • Every pending difference is applied, not just your edit. Earlier template edits that were never applied to existing zones go out at the same time. Compare the whole template with a sample zone first.

Because user-modified records are protected, some zones can keep an old value even after you apply. Find those and correct them one domain at a time.

Domain Aliases Follow Their Primary Domain

Section titled “Domain Aliases Follow Their Primary Domain”

When a domain alias has Synchronize DNS zone with the primary domain switched on, any change to the primary domain’s zone is copied to the alias, and the alias’s own records cannot be edited. Include aliases in your list of affected zones, and expect them to change whenever their primary domain changes, even without a template change.

When something changes unexpectedly, work out whether it came from the template, the primary domain, an external provider or a manual edit, and correct it at that source. Correcting a record that will simply be regenerated does not last.

  1. Before applying, save each affected zone:

    Terminal window
    plesk bin dns --info example.com
  2. Apply the change to one domain and save its zone again.

  3. Compare the two. Check that TTLs, MX priorities and TXT values you did not mean to change are identical, and count duplicate records rather than treating them as one. Compare TXT values exactly: changing case or spacing inside a TXT value is a real change.

  4. List the additions, removals and edits you expected, and explain every other difference before applying more widely.

Some zones on a server may already be disabled or hosted elsewhere, and some may already contain duplicate or faulty records. Note those before the change, so that they are not mistaken for problems it caused.

Keep zone exports private: they show your customers’ mail and service setup.

For a small change, use the panel. For larger, reviewed changes, use the Plesk CLI, XML API or SDK, and check each record’s current value before changing it. Do not edit the Plesk database or the generated zone files directly.

  • In the XML API, the host value is a prefix relative to the domain. Leave it empty for the domain itself rather than entering the full name the panel shows. If you omit both site-id and site-alias-id, the record is added to the server DNS template, not to a domain.
  • Adding a record to the template through the API changes the template only. Check existing zones afterwards rather than assuming they were updated or left alone.
  • If a script fails partway, read the zones again before retrying, because some records will already have changed and Plesk can renumber records in synchronised aliases.

If Plesk refuses to save a change because the zone is already invalid (for example an NS record pointing at a name in the same zone that has no A record), fix that first as a separate, deliberate change.

Check Publication and Undo Only What Went Wrong

Section titled “Check Publication and Undo Only What Went Wrong”
  1. Query each authoritative nameserver for the changed records and the SOA, then check any secondary nameservers and external providers.
  2. Compare zones that were healthy before the change with their own saved copy.
  3. For an unwanted change, read the current record again, then restore only the saved value, or remove only the new record, through the panel, CLI or API. Allow for alias copies and DNS caches, and keep any customer edits made since.

Do not use plesk bin dns --reset (which rebuilds a zone from the template) or a full Plesk database restore to undo one template change.

Noiz manages DNS templates and zones on its Plesk hosting. If your server is on a Noiz managed plan, contact Noiz support with the record you want changed and the domains affected.

[noiz] | disrupt the signal