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

Overview

The Domain Name System translates human-readable names such as example.com into the destinations computers use. Your domain registrar, hosting provider, website platform, and email provider may each give you values that must be entered in the domain’s DNS settings.

Before changing anything, identify where DNS is managed. It may be the registrar where you bought the domain, a dedicated DNS provider, or a hosting control panel. The authoritative DNS provider is the system whose nameservers are published for the domain. Editing records in a different dashboard will not change the live configuration.

DNS records usually contain a name or host, a record type, a value, and sometimes a time to live (TTL). The exact labels vary between providers. For example, the root domain may appear as @, a blank field, or the full domain name. Read the provider’s field instructions rather than copying a value into an incompatible format.

Core DNS records explained

• A: Points a hostname to an IPv4 address. It is commonly used to connect a root domain or subdomain to a web server.
• AAAA: Points a hostname to an IPv6 address. Add it only when the destination is configured to serve traffic over IPv6.
• CNAME: Aliases one hostname to another hostname, such as www pointing to a platform-provided address. A CNAME generally should not be used at the root domain unless the DNS provider supports an equivalent feature.
• MX: Specifies which mail servers receive email for a domain. MX records include a priority value; a lower number commonly represents higher priority, but follow the email provider’s instructions.
• TXT: Stores text used for domain verification, SPF guidance, DKIM keys, and other service-specific instructions. TXT records do not automatically perform an action; the requesting service must read them.
• NS: Identifies the authoritative nameservers for a domain or delegated subdomain. Changing nameservers can replace the entire DNS zone, so treat this as a high-impact change.
• SRV: Defines the hostname and port for particular services. It is used by some communication, collaboration, and developer tools.

Checklist by scenario

To connect a domain to a website

1. Confirm the website host’s required destination. It may provide an IPv4 address for an A record, an IPv6 address for an AAAA record, or a target hostname for a CNAME.
2. Decide which versions of the domain should work. A common arrangement is the root domain and www, with one redirecting to the other through the website platform.
3. Open the authoritative DNS dashboard and record the existing A, AAAA, and CNAME entries before editing them.
4. Add or update only the records required by the host. Remove conflicting records for the same hostname when the provider specifically instructs you to do so.
5. Complete any verification step in the website platform. This may require a TXT record or a unique CNAME.
6. Confirm that the website host has the correct domain configured and that SSL certificate provisioning is enabled or requested there.
7. Test the root domain, www, and any important subdomains over HTTPS.

If you are moving an existing site, lower the relevant TTL in advance only if your providers recommend it, keep the old hosting available during the transition, and follow a documented website migration checklist.

To configure business email

1. Collect every MX record supplied by the email provider, including its priority. Enter all required records exactly as shown.
2. Remove obsolete MX records only after confirming that no active mailbox or mail-routing service depends on them.
3. Add the provider’s TXT records for domain verification and email authentication. SPF is usually published as a TXT record, and DKIM commonly requires a provider-specific selector hostname.
4. Publish the requested DMARC policy as a separate TXT record at the designated hostname, often _dmarc. Begin with a policy appropriate to your monitoring and email-sending setup rather than copying an unfamiliar example.
5. Send test messages to and from more than one mailbox. Check delivery, replies, junk-folder placement, and any forwarding or shared-mailbox behavior.

Do not create multiple SPF records for the same domain. If several systems send mail, their authorized mechanisms generally need to be combined into one SPF TXT value according to the providers’ documentation.

To verify a service or subdomain

1. Use the exact hostname requested by the service, such as verify, docs, or a generated selector.
2. Choose the record type specified by the service. A verification value intended for TXT should not be entered as an A or CNAME record.
3. Check for an existing record with the same name before adding another one. Some services require multiple TXT values, while others require a single value.
4. Wait for the service to detect the record, then remove temporary verification records only if the service says they are no longer needed.

For developer and infrastructure services

Use separate subdomains for staging, APIs, documentation, and other environments when practical. Confirm whether a service expects a CNAME, A record, SRV record, or delegated nameserver. Keep production and staging records clearly labeled, and document ports or service targets when SRV records are involved. A hosting checklist covering SSH, deployments, databases, and logs can help you connect DNS changes to the rest of the deployment process: developer hosting checklist.

What to double-check

• Nameservers: Verify that you are editing the active DNS zone. A registrar’s DNS screen may be informational if the domain uses external nameservers.
• Host formatting: Providers differ on whether a field accepts @, a short label, or a fully qualified domain name. Follow the dashboard’s convention.
• Trailing dots: Some systems display fully qualified hostnames with a final dot. Do not add or remove it unless the provider’s interface requires a specific format.
• Conflicts: Check for duplicate A, AAAA, or CNAME records. Multiple destinations can produce inconsistent results if the service is not designed for them.
• TTL and caching: DNS changes are cached according to TTL and may also be affected by resolver behavior. A successful lookup from one network does not prove that every user sees the new value immediately.
• HTTPS: DNS only directs traffic. The website platform or server must also have the domain configured and a valid SSL certificate installed.
• Email continuity: Confirm MX, SPF, DKIM, and DMARC changes separately. A website can work while email is broken, or email can work while the website points to the wrong host.

For a practical DNS record checker guide, query the root domain, www, mail hostnames, and important verification names from more than one resolver or network. Compare the returned type, value, and TTL with your intended configuration. Avoid relying on a browser alone, because browsers may hide DNS details behind local caching.

Common mistakes

• Changing nameservers unnecessarily: If the task only requires an A, CNAME, MX, or TXT record, edit that record instead of moving the whole DNS zone.
• Leaving old mail records in place: Old MX entries can send messages to a previous provider. Confirm the complete mail path before removing or retaining any record.
• Using a CNAME at the root without support: Many DNS systems treat the root differently from subdomains. Use the host’s documented root-domain method.
• Replacing a TXT record: Multiple services may use TXT records at different names, and some names may support multiple values. Do not overwrite an existing verification or authentication value without checking its purpose.
• Forgetting IPv6: An incorrect AAAA record can send IPv6 users to the wrong server even when the A record is correct. Remove or fix it if the destination does not serve the domain over IPv6.
• Testing too soon: Record the change time, allow for caching, and test from more than one location before declaring the change complete.
• Skipping documentation: Save the provider, record purpose, expected value, change date, and owner. This makes future migrations and incident response safer.

Protect the account that controls DNS with strong authentication and limited access. DNS is part of your website and email security boundary, so include it in your broader website security and uptime checklist.

When to revisit

Review DNS before launching a new website, changing hosting, moving email, adding a subdomain, or connecting a third-party service. Revisit it before seasonal planning cycles when campaigns, landing pages, tracking services, or temporary environments may be introduced. It is also worth reviewing after a team member leaves, a registrar or DNS provider changes, or a security incident affects an account.

Use this short change checklist each time:

1. Write down the goal and the affected hostname.
2. Identify the authoritative DNS provider.
3. Export or record the current relevant records.
4. Confirm the new values with the destination provider.
5. Make the smallest necessary change.
6. Record the time, TTL, and person responsible.
7. Check website, HTTPS, email, and service verification separately.
8. Monitor the old and new destinations until the transition is complete.

Keep this checklist with your domain and hosting records. When tools, providers, or workflows change, update the documented destinations rather than relying on memory. For related planning, see the guide to choosing a domain name and hosting plan and the guide to setting up a staging site.