DNS Records Explained: How to Connect a Domain, Website, Email, and Services

Overview

When someone visits example.com, their device does not automatically know which server should answer. It queries the domain’s DNS configuration, usually through recursive resolvers operated by an internet provider, company, or public DNS service. The result may point to a web server, mail provider, verification service, or another hostname.

There are two related parts to manage:

• Nameservers: The authoritative servers responsible for publishing DNS records for a domain. You normally change nameservers at the registrar or domain management provider.
• DNS records: The individual instructions stored on those authoritative servers. You normally edit them in a DNS control panel operated by your registrar, hosting company, cloud platform, or DNS provider.

Changing nameservers can replace the entire active DNS zone. Editing a record changes only one instruction within the current zone. Before switching nameservers, copy or document existing records for the website, email, verification tools, subdomains, and other services.

Core DNS records at a glance

DNS does not install an SSL certificate, move website files, create a mailbox, or configure an application. It only directs requests or publishes information. Those other tasks must be completed in the hosting, server, email, or service provider account.

Checklist by scenario

1. Connecting a domain to a cloud server or VPS

1. Confirm the server’s public IPv4 address. If the VPS has a usable IPv6 address and web server configuration, record that separately.
2. In the authoritative DNS zone, create an A record for the root domain, often shown as @, pointing to the IPv4 address.
3. If you use IPv6, create an AAAA record for the root domain. Do not add one unless the server, firewall, web server, and application are ready to accept IPv6 traffic.
4. Create a CNAME record for www pointing to the root domain, or create an A record if your hosting design specifically requires it. Follow one consistent approach rather than creating conflicting records.
5. Open the required web ports in the VPS firewall and confirm the web server responds to both the root and www hostnames.
6. Configure the site’s SSL certificate after DNS resolves correctly. A DNS change alone does not make HTTPS work.

For a broader deployment sequence, use the domain-to-hosting, DNS, and SSL checklist. If you are moving an existing site, pair DNS changes with a website migration checklist so files, databases, redirects, and email are not overlooked.

2. Connecting a domain to shared or managed hosting

1. Add the domain inside the hosting control panel first. Many hosts will not serve the site until the domain is attached to the correct account.
2. Check whether the host expects an A record, a CNAME, or a nameserver change. Use the provider’s exact target value.
3. If using an A record, point the root domain to the supplied IP address. If using a CNAME for a subdomain, enter the complete target hostname and do not append an IP address.
4. Set up www and the root domain intentionally. Choose the preferred version and redirect the other in the web server or application.
5. Enable the hosting account’s SSL feature and test both HTTP and HTTPS after DNS resolution is available.

Do not assume that changing nameservers is always necessary. A record-based setup can preserve an existing DNS zone, while a nameserver change may transfer responsibility for every record to a new provider.

3. Setting up domain email

1. Obtain the mail provider’s complete MX instructions, including each server name and priority.
2. Remove obsolete MX records only after confirming which service should receive new mail. Multiple providers may not safely share responsibility for the same domain.
3. Add the provider’s TXT records for sender authorization and verification, if required.
4. Publish DKIM exactly as supplied, often as a TXT record at a selector-based subdomain.
5. Add or update DMARC only after understanding the domain’s sending sources. Begin with a monitoring-oriented policy when you need to identify legitimate senders before enforcing a stricter policy.
6. Send test messages to and from more than one mailbox, and check whether replies, forwarding, and application-generated mail behave as expected.

MX records control where incoming mail goes; they do not authenticate outgoing mail. TXT-based email records and the provider’s application settings handle different parts of delivery.

4. Verifying a cloud, analytics, or third-party service

Many services ask for a TXT record, a CNAME record on a unique subdomain, or occasionally an HTML file or application change. Add only the record requested, preserve its punctuation, and wait for the service to detect it. A verification record can often remain in place, but remove obsolete records when retiring a service to keep the zone understandable.

What to double-check

Record names and formatting

DNS panels differ in how they represent the root domain. One provider may use @, another may display the full domain, and some automatically append the domain name to a record name. Entering www.example.com.example.com is a common result of misunderstanding that behavior. Read the panel’s preview or resulting fully qualified name before saving.

Conflicts and unsupported combinations

A hostname generally should not have a CNAME alongside A, AAAA, MX, or other records at the same name. The root domain may also have provider-specific limitations around CNAME-like records. If a service requires an unusual setup, follow its documentation rather than combining records by trial and error.

TTL and propagation

TTL, or time to live, tells recursive resolvers how long they may cache a response. It is not a guaranteed global propagation timer. Some users can see an old answer while others see the new one because caches expire at different times. Before a planned migration, lower the relevant TTL in advance when the DNS provider permits it, then restore a sensible value after the change is stable.

Testing from more than one location

Check authoritative answers and recursive answers separately. Useful checks include:

• dig A example.com and dig AAAA example.com for address records.
• dig MX example.com for mail routing.
• dig TXT example.com for verification and email policy records.
• dig +trace example.com when nameserver delegation itself is in doubt.
• A browser request to both the preferred hostname and its redirect target.

On Windows, nslookup provides similar basic checks. Compare results using more than one recursive resolver when a change appears inconsistent.

Common mistakes

• Changing nameservers without copying email records: The website may work while mail stops because the new zone lacks MX, SPF, DKIM, or verification records.
• Pointing a record to a private address: Private VPS or internal network addresses are not suitable for a public website unless a separate public gateway is configured.
• Adding an AAAA record prematurely: Visitors using IPv6 may reach a server that is not listening, creating intermittent failures even when IPv4 works.
• Using an IP address as a CNAME target: CNAME values must be hostnames. Use an A or AAAA record for an address.
• Expecting DNS to provide SSL: DNS directs traffic; certificate issuance and web server HTTPS configuration are separate tasks.
• Deleting records during troubleshooting: Export or screenshot the zone first. Change one related group at a time so the cause remains identifiable.
• Forgetting subdomains: Applications, staging systems, APIs, status pages, and mail selectors may use names other than the main website.

When using a CDN or DNS proxy, verify whether the record should be proxied or DNS-only. Proxy behavior can affect the visible destination, TLS mode, ports, and troubleshooting results. The provider’s documentation should determine the appropriate setting.

When to revisit

Review DNS before a hosting migration, VPS rebuild, domain transfer, email provider change, CDN rollout, major application launch, or seasonal traffic plan. It is also worth reviewing after an ownership change, security incident, abandoned SaaS integration, or change to the people and systems authorized to send email.

Keep a small DNS inventory with the hostname, record type, value, purpose, owner, and date last verified. Record which provider controls the authoritative nameservers and where the zone backup is stored. This turns a fragile collection of values into an operational reference that another administrator can understand.

Before making the next change, use this final sequence:

1. Record the current nameservers and export the active DNS zone.
2. List every dependent service: website, VPS, email, CDN, SSL, analytics, authentication, staging, and integrations.
3. Identify the exact records the change affects and confirm the intended target values.
4. Lower TTL ahead of planned migrations when appropriate, and avoid changing unrelated records at the same time.
5. Apply the change, test authoritative and recursive DNS answers, then test the actual website, email, and service workflows.
6. Document the result and restore normal TTL settings after the environment is stable.

For related infrastructure decisions, compare VPS options for developers, review how a CDN and DNS provider fit into hosting, and use the website launch checklist when building a new project.