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

Overview

DNS, or the Domain Name System, translates a domain such as example.com into the destinations used by browsers, mail servers, and other services. Your domain registrar, hosting provider, or dedicated DNS provider may manage these records through a control panel.

Before changing anything, identify where the domain's authoritative DNS is managed. Updating records at the registrar will have no effect if the domain uses nameservers supplied by a separate hosting or DNS platform. Look for the active nameservers in your domain management account, and make changes in the corresponding DNS zone.

The main record types have different jobs:

• A: Points a hostname to an IPv4 address. It is commonly used for a website hosted on a server with an IPv4 address.
• AAAA: Points a hostname to an IPv6 address. Add it only when the destination and hosting setup support IPv6 correctly.
• CNAME: Points one hostname to another hostname, such as a provider-specific address. It is often used for www or hosted subdomains.
• MX: Specifies which mail servers receive email for a domain. MX records include a priority value; lower numbers generally indicate higher priority.
• TXT: Stores text-based instructions or verification values. SPF, DKIM-related values, DMARC, and many service ownership checks use TXT records.
• NS: Identifies the nameservers responsible for a domain or delegated subdomain. NS changes can affect the entire DNS zone and should be handled carefully.

DNS changes are separate from website files, hosting accounts, SSL certificates, and email mailboxes. A correct A record does not create a website, and a correct MX record does not create an inbox. Each service must be provisioned and configured independently.

Checklist by scenario

To connect a domain to a website

1. Confirm the exact hostname the site should use, such as the root domain, www, or a subdomain.
2. Obtain the destination details from the hosting provider. This may be an IPv4 address, IPv6 address, or provider hostname.
3. Create an A record for the root domain if the provider gives you an IPv4 address. Use the provider's required host or name format; many dashboards represent the root as @.
4. Add an AAAA record only if an IPv6 address is supplied and supported.
5. For www or another subdomain, add the CNAME or address record required by the hosting platform.
6. Remove conflicting records for the same hostname when the provider specifically requires a single destination. Do not delete unrelated records without checking their purpose.
7. Complete the hosting platform's domain verification step, then configure HTTPS or the platform's SSL option.
8. Test both the root domain and the preferred version, such as www.example.com. Confirm that redirects, canonical settings, and the certificate match your chosen version.

If you are moving a site, reduce the risk of downtime by lowering the relevant TTL before the change when your provider permits it, preparing the new hosting account first, and keeping the old site available until testing is complete. A broader migration plan should also cover files, databases, backups, and rollback steps. See the website backup guide before making a high-impact change.

To connect a domain to email

1. Create the mailboxes or aliases with the email provider before changing delivery records.
2. Copy every MX record exactly as provided, including the destination hostname and priority.
3. Remove old MX records only when you are sure the previous provider should no longer receive mail. Leaving old and new providers together can cause inconsistent delivery.
4. Add the provider's SPF TXT record if required. Keep one SPF policy for the domain rather than publishing multiple separate SPF records.
5. Publish DKIM records using the selector and value supplied by the provider. DKIM is often represented by a TXT record or, depending on the service, a CNAME record.
6. Add a DMARC TXT record after reviewing which systems send mail for the domain. Begin with a monitoring approach if you need time to identify legitimate senders, then tighten the policy based on observed results.
7. Send test messages to and from more than one mailbox. Check delivery, replies, message headers, and whether legitimate mail is placed in spam.

For a fuller email-specific workflow, use this business email setup guide. DNS can authorize or route mail, but it cannot correct a disabled mailbox, an application using the wrong SMTP credentials, or a provider-side sending limit.

To verify a service or subdomain

Many analytics, search, payment, CDN, and SaaS platforms ask you to prove control of a domain. The usual process is to add a TXT record with a one-time value, wait for DNS visibility, and click a verification button in the service. Use the exact host and value supplied. A verification TXT record normally does not replace website or mail records, so avoid editing existing records unless the instructions explicitly say to do so.

To delegate a subdomain

Use NS records when a separate team or platform should manage all DNS records beneath a subdomain, such as shop.example.com. Delegation is more powerful than adding one A or CNAME record: the delegated provider becomes authoritative for that subdomain. Document who owns the delegated zone and how it can be recovered before applying the change.

What to double-check

• Authority: Confirm the active nameservers before editing records. Use a DNS lookup or record checker from more than one network when results appear inconsistent.
• Hostname format: A dashboard may expect @, a blank field, or the full domain. Follow that dashboard's convention and avoid accidentally creating www.example.com.example.com.
• Trailing dots: Some interfaces display fully qualified hostnames with a final dot; others add it automatically. Do not duplicate the domain suffix.
• TTL: TTL controls how long resolvers may cache a response. It does not force every resolver to refresh immediately, so allow time after changes.
• Conflicts: A hostname should not have an incompatible CNAME alongside A or AAAA records. Check for duplicates before saving.
• Root-domain limits: Some DNS providers handle root-domain aliases differently from standard CNAME records. Use the provider's documented option for the apex or root domain.
• SSL coverage: DNS pointing and HTTPS are separate. Confirm that the certificate covers every hostname visitors will use.
• Mail authentication: Review all legitimate senders, including website forms, marketing platforms, help desks, and transactional systems, before enforcing a strict DMARC policy.

Record the old values, new values, date, reason, and person responsible for each change. This simple change log makes troubleshooting and rollback much easier, especially when several systems share one domain.

Common mistakes

Changing DNS at the wrong provider: The most frequent issue is editing a zone that is not authoritative. Check nameservers first.

Replacing the whole zone: A hosting wizard may show only the records it needs. Do not overwrite the existing zone unless you have documented website, email, verification, and third-party records and know the new zone includes them.

Adding multiple SPF records: SPF is designed as one policy record for a domain. Combine authorized senders according to the email provider's instructions instead of publishing separate SPF TXT records.

Expecting instant propagation: Cached answers can persist according to TTL, and different resolvers may update at different times. Repeatedly changing a record while waiting can make diagnosis harder.

Testing only one hostname: Test the root domain, www, key subdomains, and mail flow separately. A site can work at one hostname while another still points to an old server.

Deleting records without ownership information: An unfamiliar TXT or CNAME may support a service, verification, or email workflow. Identify it before removal.

When to revisit

Revisit your DNS checklist before a hosting migration, email provider change, domain transfer, website redesign, seasonal campaign, or infrastructure consolidation. It is also worth reviewing after adding a new form provider, marketing platform, CDN, monitoring service, or developer deployment workflow.

At each review, export or document the current zone, confirm domain renewal and account access, remove obsolete records, and verify that DNS, SSL, website hosting, and email ownership are understood. Run a fresh set of lookups after any planned change, then test the actual website and send a real email rather than relying only on a dashboard's “verified” status.

For a repeatable final pass, use this order: identify authoritative nameservers, record the current zone, define the intended website and email destinations, apply the smallest necessary change, wait for DNS visibility, test each hostname and mail path, and document the result. Keeping this checklist with your domain and hosting records turns DNS from a one-time setup task into a manageable part of website operations.