DNS Records Explained for Websites and Email: A Practical Troubleshooting Reference

Overview

The Domain Name System translates human-readable names such as example.com into the destinations that browsers, mail servers, and other services need. DNS is separate from your website hosting account, although the two must be configured to work together. You can register a domain with one company, host a website with another, and use a third provider for email, provided the authoritative DNS zone contains the right records.

Most DNS problems come from changing the wrong record, editing DNS at a provider that is not authoritative, entering a hostname twice, or overlooking an old conflicting value. Before editing anything, identify the nameservers in use and save a copy of the current zone. Make one controlled change at a time, use a suitable TTL, and verify the result from more than one network.

DNS records at a glance

An A record points directly to an IPv4 address, while a CNAME points to another name that is resolved separately. A CNAME is useful when a service provider gives you a hostname rather than a fixed address. The root domain, often written as @ in a DNS interface, may have provider-specific restrictions around CNAME records, so follow the interface guidance when configuring it.

Checklist by scenario

When a website does not load

1. Confirm that the domain has not expired and that the nameservers are the ones you expect.
2. Check the root hostname and www separately. The root may use an A record, while www commonly uses a CNAME or its own A record.
3. Compare the A or AAAA value with the address supplied by your web hosting or cloud hosting provider.
4. Look for obsolete A, AAAA, or CNAME records that point to an old server. An incorrect AAAA record can affect visitors on IPv6 networks even when the A record is correct.
5. Confirm that the web server is configured to answer for the domain and that the SSL certificate includes the exact hostname.

Changing DNS will not fix an application error, an incorrectly configured virtual host, an expired certificate, or a blocked server port. For HTTPS-specific checks, use the SSL certificate hosting guide.

When email stops arriving

1. Inspect the MX records at the authoritative DNS provider. Confirm the mail server hostnames exactly as supplied by your email provider.
2. Check MX priority values. Lower numbers generally indicate higher delivery priority, but use the provider’s documented values rather than guessing.
3. Make sure the MX targets resolve to addresses. An MX record should point to a mail hostname, not normally to an IP address.
4. Review whether an old provider’s MX record remains. A single leftover record can send some messages to the wrong service.
5. Check the email provider’s own mailbox, account, and delivery logs before changing DNS repeatedly.

MX records control incoming delivery. They do not, by themselves, configure outgoing authentication or make a mailbox exist. Sender authentication usually requires additional TXT records.

When setting up SPF, DKIM, or DMARC

• SPF: Publish one SPF policy as a TXT record at the domain used in the envelope-from or return-path configuration. List only the sending services you intend to authorize. Multiple separate SPF records can create an invalid policy, so merge approved mechanisms according to the provider’s instructions.
• DKIM: Add the TXT or CNAME record supplied by the email service, commonly under a selector such as selector1._domainkey. The selector is part of the lookup name, so do not omit it or replace it with the root domain.
• DMARC: Publish a TXT record at _dmarc. Start with a policy and reporting destination that match your operational readiness, then review reports before tightening enforcement. The exact policy syntax should come from your email provider or security documentation.

When connecting a SaaS tool or verifying ownership

Use the record type requested by the service. A TXT token normally belongs at the root or at a named verification host. A CNAME verification value belongs at the exact hostname shown by the service. Do not add quotation marks unless the DNS interface requires them, and do not change the token while copying it. Some interfaces automatically append your domain to the host field; entering the full domain in such a field can create a duplicated name.

When adding a subdomain

Decide whether the subdomain should point directly to an IP address or follow another hostname. Use an A record for a fixed IPv4 destination, an AAAA record for IPv6, or a CNAME when the destination is a hostname managed by another service. Then configure the destination service to recognize the subdomain. DNS alone does not create a website, application route, mailbox, or SSL certificate.

What to double-check

Find the authoritative DNS provider

The registrar account is not always the place where DNS is managed. Query the domain’s NS records or inspect the domain control panel to identify the authoritative nameservers. If the domain uses nameservers supplied by a hosting company, editing records at the registrar may have no effect.

Verify from the command line

On systems with common DNS utilities, use commands such as:

dig A example.com
 dig AAAA example.com
 dig MX example.com
 dig TXT example.com
 dig NS example.com
 dig CAA example.com

For a specific name server, append @1.1.1.1 or another resolver you trust. On systems without dig, nslookup can provide similar results. Compare the answer with the value saved in your DNS control panel and with the value supplied by the destination service.

Use a propagation-verification checklist

1. Record the old value, new value, date, time, and reason for the change.
2. Confirm the change at the authoritative nameserver first.
3. Query one or more public recursive resolvers and, if relevant, a resolver in the affected region.
4. Test the actual service: open the website, send and receive a test email, or repeat the provider’s verification step.
5. Allow for cached responses according to the previous TTL. A new record may appear at one resolver before another.

Lowering TTL before a planned migration can reduce the time that old answers remain cached, but it cannot guarantee instant worldwide change. After the migration is stable, restore a sensible TTL that balances caching with the need for future operational changes.

Common mistakes

• Editing the wrong DNS zone: The domain may use third-party nameservers, a separate staging zone, or delegated subdomain nameservers.
• Duplicating the domain name: A host field containing mail.example.com may become mail.example.com.example.com if the interface automatically appends the zone.
• Leaving conflicting records: Old A, AAAA, MX, or verification records can direct different users or services to different destinations.
• Creating a CNAME conflict: A hostname generally should not have a CNAME alongside other data records such as A, AAAA, or MX.
• Publishing multiple SPF records: Combine authorized senders into one policy instead of creating several independent SPF TXT records.
• Assuming propagation is the only problem: Check hosting configuration, application routing, firewall rules, SSL coverage, and email account status as well.
• Changing many records at once: Bundled edits make it harder to identify which change caused an outage or verification failure.

For a migration, keep the old hosting service available until DNS answers, website traffic, email flow, certificates, and application functions have been tested. The website migration to cloud hosting checklist provides a broader sequence for that work.

When to revisit

Review DNS records before moving a website, changing email providers, adding a SaaS platform, renewing or replacing SSL certificates, or introducing a CDN. Recheck them after a domain transfer, nameserver change, hosting migration, security incident, or unexplained delivery failure. They are also worth auditing before seasonal planning cycles when traffic, campaigns, or support coverage may change.

As a practical routine, keep an exported copy or documented inventory of production records, identify who can approve changes, and note the purpose and owner of each non-obvious entry. Revisit SPF, DKIM, and DMARC when sending platforms or transactional email workflows change. Revisit CAA records when certificate issuance workflows change. Review TTL choices when you move from frequent deployment changes to a more stable operating model.

Before closing a DNS task, complete this final sequence: identify the authoritative nameservers, back up the zone, change only the required record, verify the authoritative answer, test the real website or email path, and document the result. This simple process turns DNS troubleshooting from guesswork into a repeatable part of website and CMS operations.