Save your DNS zone: a checklist before changing nameservers

1. Save the active zone, not just any record list

First check which nameservers are assigned to your domain and where their zone is managed. With our default nameservers, use DNS management in your atdomain.at account; with custom nameservers, the active management is there. An old record list may still be visible even though its zone is no longer used. Record the domain, current nameservers, management location and capture time together. If an agency handles the technical work, have it confirm this relationship before the move. Changing nameservers changes DNS responsibility and does not copy existing records automatically. Start your inventory while you still have access to the previous setup.

2. Record each row together with its purpose

Create a working list that you can compare row by row afterwards. A screenshot can provide a useful extra view, but truncated values are not a reliable reference. If your current management service offers an export, retain the original file too; this guide does not assume every account has an export feature. Where several records share a type, include every required record. Alongside the technical fields, note which service supplied the value and who can answer questions. That makes it easier to determine whether an unfamiliar row is genuinely obsolete or belongs to a service that is only used occasionally.

3. Include less visible services and names

Work through the applications you actually use: the main website, www, shop or help subdomains, mailboxes and automated sending can have separate requirements. Also check service verification and any specialised record types, such as SRV or CAA. Use values from your existing setup or the responsible service’s current instructions. A public lookup helps cross-check known names, but does not provide a complete list of every subdomain in use. An ANY query can also return only a subset of the records for the requested name. Do not conclude from a missing lookup result that a service needs no other DNS values.

4. Prepare website and mail records separately at the destination

Map the required values into the new zone before saving the nameserver change. Check the spelling of each name and how the interface represents it: a short host label and a full name must produce the intended result after saving. For mail, include the receiving destinations as well as instructions for the sending services and their authentication. Do not copy someone else’s example values from a tutorial. Compare the saved destination setup with your working list rather than merely counting rows. Two lists can have the same length yet contain different names or values. Resolve unsupported record types before switching.

5. Separate DNS data from additional features

Some DNS interfaces also offer redirects, web protection or other services. Record those features separately: a saved DNS row does not establish that an HTTP redirect or website feature exists at the destination. Let the new zone’s SOA and NS base settings follow its documented setup instead of blindly overwriting them with old system values. DNSSEC requires coordinated preparation because the DS link must match the signing configuration. If your atdomain.at account shows active DNSSEC, contact support@atdomain.at before switching. Copying ordinary website records alone does not resolve that issue. Do not disable protection features just to see whether it helps.

6. Agree timing, responsibilities and escalation

Decide who checks the new zone, who changes nameservers and who then tests the services in use. Separate those tasks from a simultaneous website or mailbox move where your project allows it. That makes discrepancies easier to interpret. Retain the previous zone and your notes during the agreed transition; because of caches, returning to the previous nameserver assignment is not an instant undo button. Lowering a TTL at the last moment does not erase answers already cached. Record the previous values and times, and ask for clarification before proceeding when the configuration is uncertain. Keep the responsible people available for the planned checks.

7. Test more than the homepage afterwards

After the planned switch, compare public delegation and the required DNS values with your approved list. Check the website and relevant pages over valid HTTPS, together with the subdomains you use. For email, check receiving and sending separately using the addresses actually configured. Record the time, network and result; different answers can still occur during the transition. A successful website test is not approval for mailboxes or automated messages. If a problem remains, avoid changing several values at once. Collect the affected address and a redacted error message so that the responsible person can investigate a specific issue.

• Are the required names and values present at the destination?
• Do the website and relevant subdomains work over HTTPS?
• Have receiving, sending and required verifications been checked separately?

8. Keep the approved version with your domain records

After checking, update your list with the actual changes and any unresolved points. Store it securely with your project records and share only necessary extracts; passwords and access keys do not belong in it. A DNS backup also does not replace website files or stored email. Domain registration, DNS, hosting and mailboxes are different tasks. At atdomain.at a standard new .at domain currently costs €12.99 total price for the first year; renewal costs €15.99 total price for each additional year. DNS management with the default nameservers and custom nameservers are supported. Plan hosting and email mailboxes separately. For an additional domain, consider its future management and recurring charges as well.