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

Overview

When you buy a domain name, the registration itself does not automatically connect it to web hosting or email. That connection is made through the domain's DNS zone: a set of records managed at your registrar or at a separate DNS provider.

The most useful records for a typical domain and hosting setup are:

• A: Points a hostname, such as example.com, to an IPv4 address.
• AAAA: Points a hostname to an IPv6 address.
• CNAME: Points one hostname to another hostname. It is commonly used for www, hosted applications, and verification services.
• MX: Identifies the mail servers responsible for receiving email for a domain.
• TXT: Stores text-based instructions, including email authentication policies and service-verification values.
• NS: Identifies the authoritative nameservers that publish the DNS zone.

A record's name or host field identifies the hostname, its value or target contains the destination, and its TTL controls how long resolvers may cache the answer. Provider dashboards use different labels, so compare the provider's instructions with the fields in your DNS management panel rather than copying labels mechanically.

Before changing anything, record the current DNS entries. If the domain already supports a live website, email, verification service, or subdomain, deleting an unfamiliar record can break an existing function. For broader planning, see the website migration checklist.

Checklist by scenario

To connect a domain to cloud hosting

1. Find the hosting provider's required destination. This may be an IPv4 address for an A record, an IPv6 address for an AAAA record, or a provider hostname for a CNAME.
2. Decide which hostname should be primary. A common arrangement is the root domain for the main site and www as an alternate hostname.
3. Add the required A, AAAA, or CNAME record. Do not create a CNAME at a hostname where another record already exists.
4. Configure the same domain inside the hosting control panel. DNS alone does not always tell the hosting platform which site should answer for that domain.
5. Set the preferred redirect between the root domain and www, if your hosting platform requires one.
6. Enable and test the SSL certificate after DNS resolves. Visit both HTTP and HTTPS versions and confirm that the intended hostname appears in the certificate.

Some website builders and deployment platforms require a combination of records rather than a single destination. Follow the platform's current setup instructions and avoid leaving old hosting records active unless you intentionally need them. The guide to connecting a domain to cloud hosting covers this workflow in more detail.

To set up business email

1. Obtain the email provider's MX targets and priority values. Add every required MX record exactly as provided.
2. Remove obsolete MX records only after confirming that the old provider is no longer receiving mail. Mixed old and new records can produce inconsistent delivery.
3. Add the provider's TXT verification record if required. Verification records are often placed at the root host, represented by @ in many dashboards.
4. Publish email authentication records requested by the provider, such as SPF and DKIM values. These are usually TXT records, but the exact host and value depend on the provider.
5. Add a DMARC TXT record when you have identified the services that send mail for your domain. Start with a monitoring-oriented policy if you need time to review legitimate senders, then tighten the policy through a controlled process.
6. Send test messages to and from more than one mailbox. Check delivery, replies, spam placement, signatures, and mobile access.

Keep a list of every system that sends email on behalf of the domain, including contact forms, billing platforms, marketing tools, and application alerts. A business email domain setup can appear correct while an overlooked sender fails authentication.

To add a subdomain or service

1. Choose a clear hostname such as app, staging, docs, or status.
2. Use an A or AAAA record when the service gives you an IP address; use a CNAME when it gives you a hostname.
3. Confirm whether the service requires a separate verification TXT record.
4. Configure the hostname in the destination service and secure it with SSL where applicable.
5. Test the subdomain independently from the main website.

What to double-check

• Authoritative nameservers: Make changes in the DNS provider named by the domain's NS records. Editing a dormant zone at the registrar will have no effect if the domain uses different nameservers.
• Root versus subdomain: The root domain may be shown as @, a blank field, or the full domain name. A record for www does not automatically apply to the root domain.
• Record conflicts: A hostname should not have competing A and CNAME records. Check for duplicate MX records, stale verification entries, and old subdomain destinations.
• Trailing dots and provider formatting: Some interfaces add the domain automatically, while others expect a fully qualified hostname. Enter values according to the dashboard's documented format.
• TTL and propagation: DNS changes are cached. A DNS propagation checker can show responses from different locations, but it cannot force caches to refresh or confirm that the destination application is configured correctly.
• IPv6 behavior: If an AAAA record exists but the IPv6 destination is not working, some visitors may experience failures even when the A record is correct. Publish AAAA only when the service is ready to accept IPv6 traffic.
• SSL coverage: DNS resolution and SSL are separate steps. A domain can point to the correct server while still showing a certificate warning or an unconfigured-host message.

Use multiple checks: query the record type directly, open the site in a private browser window, test from a separate network, and verify the service's own dashboard. For provider selection and delegation decisions, see DNS providers compared.

Common mistakes

• Changing nameservers without migrating the zone: Switching to new authoritative nameservers before copying website, email, and verification records can make several services disappear at once.
• Using the wrong record type: A CNAME cannot generally replace an MX record, and a hostname supplied by a provider should not be entered as an IP address.
• Leaving old MX records in place: Mail can be routed unpredictably when old and new providers are both listed.
• Editing DNS during a migration without a rollback plan: Save the previous values, lower TTL ahead of planned changes when appropriate, and keep the old service available until testing is complete.
• Assuming propagation is the only problem: If DNS resolves but the site displays an error, investigate hosting configuration, firewalls, application routing, SSL, and redirects.
• Publishing email policies without inventorying senders: An overly restrictive policy can affect legitimate automated messages if the sending services are not included in the provider's required authentication configuration.

For an email move, preserve the existing mail service until the new MX records and test accounts work as expected. The guide to moving email during a domain or hosting change provides a dedicated sequence.

When to revisit

Review this DNS checklist before a seasonal planning cycle, a major campaign, a hosting change, or a domain transfer. Recheck it whenever your organization adds a sending platform, launches a subdomain, changes its website architecture, or replaces its email provider.

At minimum, keep a current DNS inventory containing the authoritative nameservers, website records, mail records, verification records, TTL choices, and the owner responsible for each service. Schedule a periodic review to remove obsolete entries and confirm that domain privacy, registrar access, SSL renewal, and DNS account security are still handled deliberately.

Before your next change, use this short action list:

1. Export or document the current zone.
2. Identify the authoritative DNS provider.
3. List the website, email, subdomains, and third-party senders affected.
4. Apply only the records required by the destination service.
5. Check DNS responses, SSL, website behavior, and email delivery.
6. Remove obsolete records only after the new setup has been verified.

This process keeps DNS management understandable and recoverable, whether the domain serves a small business website, a WordPress cloud hosting environment, or several developer-managed applications.