DNS records connect your domain to a website, email provider, security service, or other online system. This practical guide explains what A, AAAA, CNAME, MX, TXT, SPF, DKIM, and DMARC records do; how to configure them safely; what to check after a change; and when to revisit your DNS settings as your website and email services evolve.
Overview
The Domain Name System, or DNS, translates a human-readable domain such as example.com into instructions that internet services can use. A website may need records that point visitors to a hosting server, while email may need separate records that identify where messages should be delivered and which services are allowed to send them.
DNS is usually managed at the registrar or DNS hosting provider that controls your domain’s authoritative nameservers. Your web hosting account may display the records you need, but the records are only active when they are added to the correct DNS zone. Before changing anything, confirm where DNS is managed. If you update records in the wrong control panel, the change will not affect the live domain.
Keep a simple record of the current configuration, including the record type, host or name, value, priority where applicable, and TTL. This makes it easier to compare changes, restore a previous setting, or explain a problem during a domain transfer or website migration. For a broader domain-to-hosting workflow, see the guide to connecting a domain to web hosting.
What to track
Use the following reference when reviewing a DNS zone. The exact field names vary between providers: “Name,” “Host,” and “Record” may describe the same field, while the root domain may appear as @ or as a blank value.
| Record | Purpose | Typical value or detail to check |
|---|---|---|
| A | Points a name to an IPv4 address. | A numerical IPv4 address supplied by your host. Commonly used for the root domain. |
| AAAA | Points a name to an IPv6 address. | An IPv6 address supplied by your host. Add it only when the service supports IPv6 correctly. |
| CNAME | Aliases one hostname to another hostname. | A target such as a provider hostname. Often used for www or service verification. |
| MX | Specifies which mail servers receive email for the domain. | Mail server hostnames plus a priority number. Lower priority numbers are generally preferred. |
| TXT | Stores text used for verification and policy instructions. | Provider verification strings, SPF data, or other service-specific values. |
| SPF | States which senders are authorized to send mail for the domain. | Published as a TXT record. Keep one consolidated SPF policy for the domain. |
| DKIM | Allows recipients to verify a cryptographic signature added to outgoing email. | Usually a TXT record at a selector-based hostname supplied by the email provider. |
| DMARC | Sets instructions for handling messages that do not align with SPF or DKIM checks. | A TXT record at _dmarc, with a policy and optional reporting address. |
A record versus CNAME: An A record contains an IP address. A CNAME points to another hostname, which can be useful when a hosting or SaaS provider manages the destination. Do not replace a provider-required CNAME with an IP address unless the provider specifically instructs you to do so. Also check whether your DNS provider permits a CNAME at the root domain; root-domain behavior differs between platforms.
MX records: MX records control incoming email, not website traffic. Copy the mail hostnames exactly as provided and preserve the required priorities. Removing an existing MX record before the replacement service is ready can interrupt delivery.
SPF, DKIM, and DMARC: These records address different parts of email authentication. SPF identifies permitted sending services, DKIM validates a message signature, and DMARC tells receiving systems how to handle authentication or alignment failures. A new email platform may require updates to all three. SPF is normally a single TXT policy; adding multiple separate SPF policies can create an invalid or ambiguous configuration. DKIM values are often long strings, so avoid adding spaces or changing punctuation when copying them.
For each record, track the source of the value, the date it was added, and the service that depends on it. Remove old verification records only after confirming that no active website, email provider, analytics system, or security tool still uses them.
Cadence and checkpoints
A monthly or quarterly DNS review is usually enough for a stable small website, with additional checks whenever a service changes. The goal is not to edit DNS routinely; it is to notice stale, duplicated, or unexpected settings before they cause an outage.
Before connecting a website
- Confirm whether the host expects nameserver changes or individual A, AAAA, and CNAME records.
- Record the existing DNS zone before making changes.
- Add only the records required by the hosting provider.
- Check the root domain and common subdomains such as
wwwseparately. - Test both the secure and non-secure versions of the site after the host provisions SSL.
If you are launching a new site, the instant site launch checklist can help place DNS work in the right order.
Before changing email providers
- List the current MX, SPF, DKIM, and DMARC records.
- Confirm which applications send mail using your domain, including forms, newsletters, invoices, and support tools.
- Obtain the new provider’s required records and note any transition instructions.
- Plan the MX change separately from SPF, DKIM, and DMARC updates when the provider recommends it.
- Send and receive test messages using more than one mailbox, then review authentication results if available.
When changing TTL, use the value recommended by your DNS provider or service documentation. A shorter TTL may help during a planned migration, while a longer TTL can reduce repeated lookups for stable records. DNS updates are cached, so a change may not appear everywhere at the same time.
How to interpret changes
When a website stops loading after a DNS edit, first check whether the domain uses the nameservers you edited. Next compare the live A, AAAA, and CNAME records with the hosting provider’s instructions. An old AAAA record can sometimes direct IPv6 visitors somewhere different from IPv4 visitors. A conflicting CNAME or duplicate hostname record can also produce inconsistent results.
If email stops arriving, inspect MX records and their priorities before changing SPF or DKIM. Incoming delivery depends primarily on MX settings. If messages arrive but are rejected or marked as suspicious, review SPF authorization, DKIM signing, and DMARC alignment. Make sure every legitimate sender is accounted for, but avoid adding broad or speculative authorization that you cannot maintain.
Verification records deserve a separate review. A TXT value may belong to a service that is no longer active, or a provider may have issued a replacement token. Do not assume every TXT record is related to email. Keep a note beside each one so a future administrator can distinguish verification, SPF, DKIM, and other service instructions.
For website security issues, DNS is only one part of the diagnosis. An incorrect certificate, hostname mismatch, or incomplete HTTPS setup may require a separate review of the hosting and SSL configuration. Use the SSL certificate errors guide when the DNS destination is correct but the browser still reports an HTTPS warning.
When to revisit
Review your DNS records on a monthly or quarterly schedule, and immediately after any of the following events:
- You register a new domain, change nameservers, or complete a domain transfer.
- You move the website to new web hosting, a managed WordPress hosting plan, or a different infrastructure provider.
- You add or replace an email provider, newsletter platform, help desk, payment system, or transactional email service.
- You receive repeated delivery failures, spam complaints, authentication warnings, or unexpected verification requests.
- You add a subdomain, staging site, landing page, CDN, security service, or third-party application.
- You discover an expired service, an unfamiliar record, or a DNS change that no one on the team recognizes.
- You are preparing for a renewal, migration, backup review, or website launch.
At each checkpoint, export or copy the current zone, confirm that every record has an owner and purpose, test the website and email, and remove only records that are demonstrably obsolete. Keep the review record with your domain renewal and website backup documentation. The domain expiration checklist and backup and restore plan can help complete that wider maintenance routine.
DNS works best when it is treated as a maintained configuration rather than a one-time setup. A small, documented review after each service change can prevent the most common website connection, email delivery, and verification problems.
