Want to connect your domain to a website or add a service, but A, CNAME, MX and TXT records look confusing? First identify who operates the active DNS zone and which services use the domain. Your website and email can be hosted in different places.
This guide explains common records and a verifiable change process. Obtain real values from your host or the relevant service; none of the examples below is an iMasterWeb account setting.
1. Separate the domain, hosting and active DNS zone
Your registrar, DNS operator, website host and email provider may be different organizations. The panel where you bought the domain is not necessarily serving its active DNS zone.
Identify the active nameservers and ask support where to edit the authoritative zone. Updating an unused zone does not change public answers. Replacing nameservers changes the zone’s delegation and needs more preparation than updating a website address record.
2. Read the common record types
| Type | Purpose |
|---|---|
| A | IPv4 address for the name. |
| AAAA | IPv6 address for the name. |
| CNAME | Alias to another DNS name. |
| MX | Receiving mail servers. |
| TXT | Verification or authentication text. |
| NS | Authoritative nameservers for the zone. |
| SOA | Zone administration information. |
Teaching example only: example.com and these addresses are not your hosting settings. Do not copy them into a real DNS zone.
| Name | Type | Example value |
|---|---|---|
| @ | A | 192.0.2.10 |
| www | CNAME | example.com. |
| @ | MX | 10 mail.example.net. |
Depending on the panel, the root name may be entered as @, a blank field or the full domain. Check its convention: some interfaces append the domain to a short name. The symbol @ is not a value to copy into every field.
DNS record overview · DNS principles.
3. Connect the website without changing email unintentionally
Get the exact settings for the root domain and www. Prepare a small table with the old value, new value, reason and expected check. Include existing AAAA records: an outdated IPv6 destination can produce different results on different connections.
- Export the current zone or retain a readable copy.
- Confirm the name and type of each record to change.
- Apply only the planned website changes and preserve identified services.
- Check the root domain,
wwwand the website over HTTPS. - Test inbound and outbound email even when it was intended to stay unchanged.
A CNAME points to a name, not a URL containing https:// or a path. It is not an HTTP redirect. A conventional CNAME cannot coexist with other data at the same name; the zone root may need a provider-specific mechanism. Do not delete root MX or TXT records to force a CNAME. CNAME constraints.
4. Preserve email routing and authentication
MX records identify receiving mail servers; they do not transfer existing mailboxes. The target is a server name, and a lower numerical priority is preferred. Use your provider’s values rather than inventing a target or priority. MX behavior.
Check authentication records as well:
- SPF: describes authorized sending sources. Do not create competing SPF policies at the same name; combine legitimate sources into a coherent policy.
- DKIM: publishes information corresponding to the sending service’s signatures. Use its exact selector and supplied value.
- DMARC: expresses a policy based on authentication results and alignment. Do not apply a generic strict policy without examining legitimate senders.
Several TXT records can be legitimate: one SPF policy does not mean only one TXT record per domain. A Search Console verification TXT does not replace SPF or DKIM. SPF specification.
5. Understand TTL and temporary differences
TTL is a caching lifetime. If lowering it is part of a cutover plan, do so early enough for older cached answers to expire. Lowering it at the last moment does not remove copies already cached.
Answers can therefore differ temporarily across resolvers and caches. There is no universal 24- or 48-hour propagation deadline for every DNS change. Check authoritative data and public responses. TTL reference.
6. Treat nameserver changes as a wider operation
Prepare the complete destination zone before changing delegation: website, mail, subdomains, verification records and other services. Automatic detection or copying does not prove that every necessary record was found.
If DNSSEC is active, coordinate signatures and the DS record with the registrar and DNS operator. An inconsistency can cause validation failures. DNSSEC authenticates DNS data; it is not website HTTPS encryption. DNSSEC documentation.
7. Verify and investigate without repeatedly changing settings
After saving, compare the active zone and observed answers. Correct address resolution does not establish that the server or HTTPS certificate is configured correctly. DNS and HTTPS require separate checks.
- Old website appears: inspect caches, active nameservers, domain variants and stale A or AAAA destinations.
- Email stops: compare MX, authentication and actual mailboxes with the intended configuration.
- A subdomain fails: check the name actually created and whether the domain was appended twice.
- Ownership verification fails: check the name, complete TXT value and active zone.
When requesting support, include the domain, record name and type, old and new destinations, change time and observed result. Do not expose private keys or account access codes.
Checklist and frequently asked questions
- Authoritative zone identified and old configuration retained.
- Values obtained from the relevant service.
- Email and subdomains included in the plan.
- TTL and DNSSEC considered where relevant.
- Website, HTTPS and email tested separately.
Must I change nameservers when changing hosting?
Not always. Depending on the chosen arrangement, updating the website records may be sufficient. Confirm the scope first.
Does changing MX copy old messages?
No. Migrating mailbox accounts and their contents is a separate task.
Continue with the WordPress backup guide, migration guide and Search Console guide. For actual account settings, contact iMasterWeb.