DNS records explained: connect a website without breaking email
Learn which DNS records control your website and email, find the right DNS panel, and prepare a website change without losing working mail settings.
In this guide
Connecting a new website usually means changing a few DNS records—not replacing everything attached to your domain. Your website and email can use the same domain while being hosted by different companies.
This guide helps you identify the website records, spot connections to your email, and prepare the exact change your new host asks for. It does not give you a universal set of values to paste: those come from your own hosting account.
Have access to the account where you bought the domain, the current DNS settings, and the new host’s domain-connection instructions. You do not need to buy another domain, move your email, or change your website design.
First, find the DNS panel that actually controls the domain
DNS is the address book that tells other computers where to find services for your domain. A DNS record is one entry in that address book.
The company that sold you the domain is its registrar. The company answering its DNS queries may be different. In your registrar account, open the domain and find Nameservers. Nameservers identify the service responsible for the domain’s authoritative DNS—the original records other services look up and cache.
If those names belong to your registrar, use its DNS-management page. If they belong to another service, open that service’s DNS panel instead. For example, a domain using Cloudflare nameservers normally has its records managed in Cloudflare. If you cannot identify the provider or access the account, resolve that with the registrar or current administrator before changing anything.
Changing nameservers is a wider change than editing a website record. A new DNS service needs the whole required set of records, including mail. Do not change nameservers just because the new website host also offers DNS. Follow the host’s connection method for an existing DNS provider when it supports one.
The records you are likely to see
Suppose your domain is example.com. These names and addresses are illustrations, not working settings.
| Type | What it does | Example of its role |
|---|---|---|
| A | Points a name to an IPv4 address | example.com points to the web server’s numeric address |
| AAAA | Points a name to an IPv6 address | Another route to the web server, using IPv6 |
| CNAME | Makes one name an alias of another hostname | www.example.com points to a hostname supplied by your website host |
| MX | Names the servers that receive mail for the domain | Mail to hello@example.com goes to the mail provider |
| TXT | Stores text used by other services | Domain verification or an SPF policy used in email authentication |
In many DNS panels, @ means the bare domain, such as example.com. A name of www usually means www.example.com. Some panels expect the short name; others show or require the complete one. Read the preview of the resulting name before saving, so you do not create www.example.com.example.com.
An MX entry also has a priority number; a smaller number is preferred. TXT records have many purposes, so neither their name nor their type means they are safe to delete. Leave unfamiliar entries in place until you know what uses them.
Protect email before touching the website records
Save an export of the current DNS records if the panel offers one. Otherwise, record each entry’s name, type, value, priority where applicable, and TTL. TTL is the period for which a DNS answer may be cached. Keep this baseline somewhere you can reopen if you need to undo your edits.
Then look at the destination of each MX record. Keeping MX and TXT unchanged is a good start, but it is not the whole check:
- If an MX record points to
mail.example.com, the A or AAAA record for that name also matters to mail. - If an MX record points to
example.comitself, changing that domain’s address may redirect incoming mail too. Ask your mail provider for the correct independent mail destination before moving the website. - An email policy or verification record may use TXT or CNAME. Preserve those records as well. A website-only move is not a reason to replace the domain’s email-authentication settings.
- An SPF policy says which servers may send mail for a domain. If its text contains an
aora:hostnamemechanism, it uses that name’s A or AAAA addresses. Changing those addresses can change which sender is authorized even when the TXT record stays untouched. Ask your mail provider about that dependency before moving the website.
If the mail-authentication names are unfamiliar, our SPF, DKIM and DMARC explanation helps you identify what each service controls.
Also note any existing mail-routing service or provider-specific setting. A record table alone may not describe everything configured in the account.
Write a small change list
Open the new website host’s instructions for your site and compare them with the saved baseline. For every requested record, write down:
- The exact name, such as the bare domain or
www. - The record type and the value supplied by the host.
- Whether you are adding a new record or replacing an existing one.
- Whether any mail entry depends on the name being changed.
Do not copy a tutorial’s sample IP address. An address is useful only if it belongs to the service that will serve your site.
Check both A and AAAA records for the name. Leaving an old IPv6 address beside a new IPv4 address can send some visitors to the old server. Use the host’s instructions to decide which should remain; do not delete IPv6 records across the whole domain.
A normal CNAME cannot share its name with other DNS data. Providers may offer ALIAS, ANAME, or CNAME flattening for the bare domain, where ordinary CNAME rules cause conflicts. Use a method supported by both your DNS provider and host; do not improvise one because another provider’s screenshot looks similar.
Know what you will check afterward
Before making the change, write down the current result of three ordinary checks: open the website, receive a test message at your domain mailbox, and send a reply to an address you control. Repeat them after the host reports the connection is ready.
Check the bare domain and www separately. DNS directing a name to a host does not by itself create a redirect between them, publish your site there, or finish its HTTPS certificate. HTTPS is the encrypted connection visitors use; a browser certificate warning is a separate problem to resolve with the host.
Cached answers can outlive the moment you press Save. Do not repeatedly replace correct records because one device still sees an older answer. Compare the saved value with the host’s required value and the connection status first. The previous TTL and other caches affect when users see the change; there is no universal five-minute guarantee.
You are ready to continue when you have a saved baseline, an exact list of website changes, no unexplained mail dependency, and checks for both the website and email. If one part is unclear, ask the relevant provider about that specific record. Buying a different service is not the next step.
Sources and useful links
- Cloudflare’s DNS record reference — the record types and their fields.
- How authoritative nameservers work — why the registrar and DNS provider may differ.
- Cloudflare’s record-management instructions — an example of the fields in an actual provider’s panel.
- DNS caching and TTL — what the lifetime of an answer means.
- CNAME flattening — one provider’s approach to using an alias at the bare domain.
- SPF’s address-based rule — why a website address change can also affect a mail policy.