DNS records connect your domain to websites, email providers, verification tools, CDNs, and other services. This guide explains what each common record does, which value belongs in each field, how long changes may take to appear, and how to make updates without accidentally disrupting an existing service.
Overview
The Domain Name System, or DNS, translates human-readable domain names into the technical destinations that browsers and internet services use. Your domain may have several records at once: one directing the main website to a server, others routing email, proving ownership, authorizing certificate issuers, or connecting a subdomain to a separate platform.
DNS is managed wherever your domain’s authoritative nameservers point. That may be your domain registrar, web host, CDN, or a dedicated DNS provider. Before adding a record, confirm that you are editing the active DNS zone. Changing records in an inactive dashboard will not affect the domain.
Record fields vary by provider. Common labels include Type, Name or Host, Value or Target, Priority, and TTL. A provider may automatically append your domain name to the host field, so entering a full domain where only a hostname is expected can create an incorrect record. When instructions from a service conflict with the dashboard layout, follow the service’s current setup instructions and check how the DNS provider formats names.
| Record | Purpose | Typical value | Important detail |
|---|---|---|---|
| A | Points a hostname to an IPv4 address | 192.0.2.10 | Use an IPv4 address supplied by your host or service |
| AAAA | Points a hostname to an IPv6 address | 2001:db8::10 | Only add it when the destination supports IPv6 |
| CNAME | Aliases one hostname to another hostname | app.example.net | Normally used for subdomains, not the root domain |
| MX | Routes incoming email | mail.example-provider.com | Priority determines which mail server is preferred |
| TXT | Stores text used for verification and email policy | service-verification=token | Copy the value exactly, including punctuation |
| NS | Delegates DNS authority | ns1.provider.example | Changes can move control of the entire DNS zone |
| CAA | Specifies which certificate authorities may issue certificates | 0 issue letsencrypt.org | Incorrect restrictions can interfere with SSL issuance |
| SRV | Identifies a service, port, and destination | 10 5 443 service.example | Used by services that publish connection details |
A record versus CNAME
An A record maps a hostname directly to an IPv4 address. A CNAME maps a hostname to another hostname, allowing the destination service to manage the underlying IP address. For example, a hosting provider may ask you to point www to a supplied hostname with a CNAME, while the root domain may require an A record or a provider-specific alias record.
Do not replace an existing A record with a CNAME simply because both can connect a website. Check the service’s instructions and the DNS provider’s support for root-domain behavior. A hostname generally cannot have a CNAME alongside other records of the same name.
What to track
Keep a simple DNS inventory before making changes. Record the hostname, type, value, purpose, provider that requested it, date added, and any expiration or review note. This turns an unfamiliar list of entries into an understandable map of your domain.
Website and subdomain records
For a basic website connection, identify whether the provider requires an A record, AAAA record, CNAME, or a combination. The root domain is often shown as @, while a subdomain such as www, shop, or blog is entered by name. Add only the records requested by the provider. Preserve records used by email, verification, analytics, or other subdomains.
When adding a CDN or website platform, check whether it expects the root domain, www, or both. A site can appear partly connected when only one hostname has been updated. Test each hostname that visitors may use, including the HTTPS version where applicable.
Email records
MX records determine where incoming mail is delivered. If you change email providers, use the new provider’s complete MX set and remove obsolete MX records only after confirming that no active mailbox depends on them. MX records use priority values; lower numbers are commonly treated as more preferred, but follow the provider’s instructions rather than guessing.
Email authentication usually also involves TXT records. SPF identifies permitted sending services, DKIM publishes a cryptographic public key, and DMARC states how receiving systems should handle messages that do not authenticate. These records are provider-specific. Avoid creating multiple SPF records for the same hostname; combine authorized mechanisms according to the email provider’s guidance instead.
Verification and security records
Website builders, search tools, advertising platforms, email services, and certificate systems may ask for a TXT record or CNAME to verify domain control. Add the requested record without deleting unrelated verification entries. A verification token is usually an exact string, so extra spaces, quotation marks, or altered capitalization can cause failure.
CAA records can limit which certificate authorities are allowed to issue certificates for your domain. If your domain uses CAA, confirm that the certificate authority required by your hosting or CDN is permitted. If you are troubleshooting an SSL issue, review the related SSL certificate troubleshooting checklist before changing security records.
SRV and NS records
SRV records are structured records containing priority, weight, port, and target. They are used by particular applications rather than ordinary website connections. Copy each field into the matching dashboard field; do not place the entire instruction into a single value field unless the provider specifically requires that format.
NS records are different from most records because they define which nameservers are authoritative for a domain or delegated subdomain. Changing nameservers can move the entire DNS zone to another provider. Export or document existing records first, and recreate essential website and email entries in the new zone before switching authority.
Cadence and checkpoints
DNS does not require daily monitoring for most small websites, but it deserves a documented review whenever a connected service changes. Use this practical schedule:
- Before a DNS change: Save a copy or screenshot of the current zone, note the reason for the change, and identify the records that must remain untouched.
- Immediately after a change: Confirm that the record appears correctly in the authoritative DNS provider’s dashboard. Check for duplicated records, missing periods in targets, and accidental changes to the root hostname.
- After the expected TTL window: Test the website, key subdomains, inbound email, outbound email, and any verification service affected by the update.
- Monthly or quarterly: Review unfamiliar records, old verification tokens, unused subdomains, certificate-related entries, and email authentication records. A quarterly review is a reasonable baseline for many small sites; higher-change environments may need a monthly review.
- Before migration or renewal: Audit DNS as part of the project plan. The domain and hosting migration checklist can help organize a move without overlooking DNS dependencies.
TTL, or time to live, tells DNS resolvers how long they may cache an answer. A change may be visible from one network before another because caches expire at different times. Lowering TTL in advance can make a planned change easier to switch, but it does not guarantee immediate visibility and should not replace testing.
How to interpret changes
If a website stops loading after an update, first determine whether the problem affects the root domain, a subdomain, or both. Compare the live records with the hosting provider’s instructions. Look for an old A record competing with the intended destination, an incorrectly entered CNAME, an unwanted AAAA record, or a nameserver change that points to an incomplete DNS zone.
If email stops arriving, inspect MX records first. Confirm that the new records are published at the authoritative provider and that old records have not been left with a higher preference than intended. If messages send but are rejected or filtered, review SPF, DKIM, and DMARC rather than changing MX records at random.
If a verification service cannot find a token, confirm the hostname format. A service may request _verify.example.com, while a DNS dashboard expects only _verify. Also check whether the record was added to the active nameserver provider and whether the value was copied without modifications.
Do not respond to every DNS warning by deleting records. An entry that looks unfamiliar may support an email platform, a security product, a subdomain, or a certificate process. Identify its purpose first. For broader hosting issues, the guide to monthly and quarterly hosting maintenance provides a useful companion checklist.
When to revisit
Revisit this DNS guide whenever you register a domain, change hosts, connect a website builder, move email, add a CDN, create a subdomain, configure SSL, or verify ownership with a third-party service. It is also worth reviewing DNS before a domain transfer and after a nameserver change. The goal is not to edit records regularly; it is to know what each record does and to notice changes before they become outages.
For an ongoing routine, maintain a dated DNS inventory and schedule a monthly or quarterly checkpoint. At each review, confirm the authoritative nameservers, test the main website and important subdomains, check email delivery, and remove only records that have a confirmed owner and no remaining purpose. Update the inventory when a provider changes its required values or dashboard fields.
Before pressing Save, use this final checklist:
- Am I editing the active DNS provider?
- Do I know whether the request requires A, AAAA, CNAME, MX, TXT, NS, CAA, or SRV?
- Did I enter the hostname in the format this dashboard expects?
- Have I preserved unrelated website, email, and verification records?
- Did I record the old value, new value, purpose, and change date?
- Will I test the affected service after caches have had time to refresh?
When a change involves several services or a hosting migration, document the sequence rather than making simultaneous edits. That makes troubleshooting easier and helps prevent a small DNS adjustment from becoming an avoidable website or email outage.
