DNS Records for Website Hosting and Email: A Practical Setup Reference

Overview

Before changing DNS, identify the company that hosts your domain’s authoritative nameservers. That may be your registrar, hosting provider, CDN, or a dedicated DNS service. DNS records must be added where those nameservers point; changing records in a different dashboard will not affect the live domain.

Make a simple inventory before you begin:

• The root domain, such as example.com.
• Common subdomains, such as www.example.com, app.example.com, or status.example.com.
• Your website host, CDN, or website builder.
• Your email provider and any services that send mail on your behalf.
• Verification, security, analytics, or certificate services that require DNS entries.

DNS changes are usually made by entering a record type, host or name, value, and sometimes a time-to-live (TTL). The exact field labels differ between providers. A host field containing @ generally means the root domain, while some dashboards expect the domain name itself or leave the field blank. Follow the provider’s field instructions rather than copying a format blindly.

SPF is technically published as a TXT record, while DKIM and DMARC are also normally represented through TXT records. Some DNS interfaces provide separate labels or guided forms, but the underlying DNS record type may still be TXT.

Checklist by scenario

Connecting a domain to a website

1. Confirm whether the host requires an A record, AAAA record, CNAME, or a combination.
2. Check whether the root domain and www hostname need separate entries.
3. Remove only conflicting records for the same hostname. Do not delete unrelated mail or verification records.
4. Add the requested values exactly. Avoid adding quotation marks unless the DNS interface specifically requires them.
5. Set the host’s preferred canonical address, such as redirecting www to the root domain or the reverse, in the website platform rather than creating a DNS loop.
6. Confirm that the hosting platform recognizes the domain as connected.

An A record points directly to an IPv4 address. A CNAME points one hostname to another hostname and is often useful for a subdomain managed by a hosted platform. A CNAME generally cannot coexist with other record types at the same exact hostname, and the root domain has additional DNS limitations in many systems. Use the host’s documented root-domain method when it provides one.

Adding or changing email

1. Collect every MX record supplied by the email provider, including priorities.
2. Remove old MX records only after confirming that the new provider is ready to receive mail.
3. Add the provider’s SPF instruction as a TXT record. Keep one SPF policy for the domain; combine authorized senders carefully rather than publishing several separate SPF records.
4. Generate or copy the DKIM record, including its selector hostname and public key.
5. Add a DMARC TXT record at _dmarc, beginning with a monitoring-oriented policy if you need to observe legitimate senders before enforcing a stricter policy.
6. Send test messages to and from more than one mailbox, and inspect authentication results where available.

MX records control where incoming mail is delivered; they do not authorize outgoing senders. SPF addresses approved sending infrastructure, DKIM authenticates signed messages, and DMARC uses those authentication results to apply a policy. A complete DNS records for email setup should account for all four functions instead of relying on MX records alone.

Enabling SSL or a CDN

1. Read the CDN or certificate provider’s domain-connection instructions before changing records.
2. Add any requested CNAME or TXT validation record exactly as shown.
3. Check whether the service expects the root domain, www, or a dedicated subdomain.
4. Wait for domain validation, then enable HTTPS in the hosting or CDN dashboard.
5. Test both HTTP and HTTPS versions, the root domain, and important subdomains.

DNS points traffic to a service, but DNS alone does not install or validate a certificate. Certificate issuance, HTTPS redirects, and origin configuration are handled by the website host or CDN. For a broader launch sequence, use the website deployment checklist.

Adding a subdomain or verification record

1. Use a specific host name, such as docs, shop, or verify.
2. Choose the record type requested by the service.
3. Check whether the value should include a trailing dot; most modern dashboards handle this automatically.
4. Leave unrelated records unchanged.
5. After verification succeeds, keep the record if the service says it is required for ongoing operation.

What to double-check

Before saving a DNS change, review these details:

• Nameservers: Confirm that you are editing the active DNS zone.
• Hostname format: Determine whether the dashboard automatically appends your domain. Entering the full domain when only a label is expected can create an unintended name.
• Record conflicts: Look for duplicate A, AAAA, CNAME, or MX records at the same hostname.
• Mail priorities: Lower MX priority numbers generally indicate preference, but use the values supplied by your provider.
• TTL: A shorter TTL can make planned changes easier to adjust, while a longer TTL may reduce repeated lookups. TTL does not guarantee instant propagation.
• IPv6: An incorrect AAAA record can cause some visitors to fail even when the A record is correct. Publish AAAA only when the IPv6 destination is configured properly.
• SSL coverage: Verify that the certificate includes every hostname visitors will use.
• Backups: Export or record the current DNS zone before a major migration. DNS is not a substitute for website or email backups; pair changes with a tested backup and restore routine.

Use independent DNS lookup tools or command-line utilities such as dig and nslookup to compare the record returned by different resolvers. Test the exact name and type you changed, for example dig MX example.com or dig CNAME www.example.com. A result from one resolver may differ temporarily from another because of caching.

Common mistakes

• Editing the registrar instead of the active DNS provider: The domain purchase location and DNS hosting location are not always the same.
• Publishing multiple SPF records: Combine mechanisms into one valid SPF TXT policy according to the senders you actually use.
• Deleting all existing records during a website migration: This can interrupt email, verification, subdomains, or certificate renewal.
• Using an A record where a CNAME is required: Hosted platforms often provide a hostname rather than a fixed IP address.
• Assuming propagation is broken: Check authoritative nameservers, TTL, local cache, and the exact hostname before repeating a change.
• Ignoring the root and www difference: A site can work at one address and fail at the other if both are not configured.
• Starting DMARC enforcement without inventorying senders: Website forms, marketing tools, support systems, and transactional services may all send mail for the domain.
• Leaving obsolete records behind: Old mail, hosting, or verification entries create confusion and may direct traffic to services no longer controlled.

When a change fails, avoid making several edits at once. Record the current values, identify the exact failing hostname, verify the authoritative zone, and change one related group of records at a time. This creates a clear rollback path.

When to revisit

Keep this DNS checklist with your domain and hosting documentation. Revisit it before a website migration, email-provider change, CDN rollout, SSL configuration, seasonal campaign, or major application deployment. It is also useful when renewing a domain, adding a new subdomain, changing a form or transactional email service, or investigating intermittent resolution and mail-delivery problems.

At each review, export or document the active records, confirm who controls the nameservers, remove entries for retired services, and verify that website and email tests still pass. If your tools or provider workflows change, update the procedure with the provider’s current record names and validation steps rather than relying on an old screenshot or copied example.

For a final pre-launch pass, combine this reference with a DNS, SSL, and deployment checklist, then test resolution from more than one network. Record the date, the reason for the change, the previous values, and the rollback plan. That small habit turns DNS from a one-time setup task into a manageable part of your site infrastructure.