LiveChat 
Support 
DNS Records Explained: The Complete Guide to Every Record Type
Every time someone visits your website, sends you an email, or verifies that you own your domain, a small set of instructions works silently in the background to route that request to the right place. Those instructions are DNS records. If you have ever felt unsure about why your site loads but your email bounces, or why a service tells you to “add a TXT record,” this guide builds the answer from the ground up.
DNS records are the configuration entries inside your domain’s DNS zone that tell the internet where to send different kinds of traffic. They are not abstract networking trivia. They are the practical control panel that determines whether your domain works. By the end of this guide, you will understand each record type, how they cooperate, and exactly which records to edit for common tasks.
Key Takeaways
• DNS records are instructions in your domain’s DNS zone that route different types of traffic to different destinations.
• The most common types are A, AAAA, CNAME, MX, TXT, NS, SOA, SRV, PTR, and CAA — each handles a distinct job.
• A domain is not one destination. It is a switchboard: your website (A), email (MX), and verification (TXT) can each point somewhere different.
• TTL controls how long records are cached, which affects how fast changes propagate.
• You edit records in your DNS host or registrar’s zone editor.
What are DNS records and where do they live?
A DNS record is a single line of instruction stored in your domain’s DNS zone — the master file that holds every routing rule for your domain. When a browser, mail server, or verification system needs to interact with your domain, it queries DNS and reads the relevant record to learn where to go.
Think of the DNS zone as a directory and each record as one entry in it. One record says “the website lives at this IP address.” Another says “mail for this domain goes to this server.” A third says “this random string proves the domain owner controls the zone.” Each record has a type (which job it does), a name (which part of the domain it applies to), a value (the destination or data), and a TTL (how long it may be cached).
For a deeper foundation on how queries travel from a visitor’s browser to your zone, see our . If you are brand new to the concept itself, start with .
What are the main DNS record types?
There are dozens of record types, but a handful do the vast majority of the work. Here is the core set you will actually use, with what each one does and a representative example.
| Record | Purpose | Example value |
|---|---|---|
| A | Points a domain or subdomain to an IPv4 address | `93.184.216.34` |
| AAAA | Points a domain or subdomain to an IPv6 address | `2606:2800:220:1:248:1893:25c8:1946` |
| CNAME | Aliases one name to another name (not an IP) | `www → example.com` |
| MX | Directs email to the correct mail servers | `10 mail.example.com` |
| TXT | Holds text data for verification and email auth | `v=spf1 include:_spf.example.com ~all` |
| NS | Names the authoritative nameservers for the domain | `ns1.example.com` |
| SOA | Stores administrative info about the zone | primary NS, admin email, serial |
| SRV | Specifies host and port for a specific service | `_sip._tcp 10 60 5060 sip.example.com` |
| PTR | Maps an IP back to a hostname (reverse DNS) | `34.216.184.93.in-addr.arpa` |
| CAA | Declares which certificate authorities may issue SSL | `0 issue “letsencrypt.org”` |
A and AAAA records are the foundation of any website. The A record connects a name to an IPv4 address; the AAAA record does the same for IPv6. When you “point your domain to a host,” you are almost always editing an A record.
CNAME records create an alias. Instead of pointing to an IP, a CNAME points to another hostname. A classic use is making `www.example.com` resolve to `example.com`, so you only maintain the IP in one place.
MX records are dedicated to email. They tell sending mail servers which machines accept mail for your domain, and the priority number decides which to try first. For a full walkthrough of mail routing, see .
TXT records are the most versatile. They hold free-form text used for domain verification and for email authentication standards — SPF (which servers may send mail for you), DKIM (a cryptographic signature on your mail), and DMARC (the policy that ties SPF and DKIM together).
The remaining records are more specialized. NS records delegate authority to your nameservers, SOA carries zone administration metadata, SRV advertises specific services and ports, PTR provides reverse lookups (commonly used to improve mail deliverability), and CAA restricts which certificate authorities can issue SSL certificates for your domain.
How do DNS records work together?
This is where most confusion dissolves. People assume a domain “points to” one place. It does not.
Here is the mental model that makes everything click: a domain is a switchboard, not a single address. Different record types route different services independently. Your website lives wherever your A record points. Your email is delivered wherever your MX record points — which can be an entirely different provider on entirely different servers. Your domain verification is proven by a TXT record that may satisfy a third service that touches neither your site nor your mail.
All three coexist under the same domain, simultaneously, without conflict. Once you stop thinking “where does my domain go?” and start thinking “where does each *service* on my domain go?”, configuration and troubleshooting become obvious instead of mysterious. A bouncing email is never a website problem — it is an MX, SPF, or DKIM problem, and you now know exactly which records to inspect.
A typical small business zone might route the apex domain to a web host via an A record, route mail to a separate email provider via MX records, publish SPF and DKIM via TXT records, and prove ownership of an analytics tool with another TXT record. Four services, one domain, four independent routing rules.
What is TTL and how does propagation work?
TTL stands for Time To Live. It is a number (in seconds) attached to each record that tells resolvers around the world how long they may cache the answer before checking again. A TTL of `3600` means resolvers can reuse the cached value for one hour.
TTL is the lever behind DNS propagation — the delay between changing a record and the change being visible everywhere. If your TTL is set high, old values linger in caches longer after you make a change. A practical habit: before a planned migration, lower the TTL on the records you intend to change (for example to 300 seconds) a day in advance, make the change, then raise it back afterward. This minimizes the window where some visitors see the old destination and others see the new one. For a deeper look at why changes take time to spread, see .
Where and how do you edit DNS records?
You edit records wherever your domain’s authoritative DNS is hosted. That is usually one of two places: your domain registrar (where you bought the domain) or your DNS host / hosting provider (if you have pointed your nameservers to them). The interface is called a DNS zone editor, and the location of authority is determined by your NS records and nameserver settings. If you are deciding which to use, our guide to explains the relationship.
Inside the zone editor you add, edit, or delete records by choosing a type, entering a name (often `@` for the root domain or a label like `www` for a subdomain), supplying the value, and setting a TTL. The mechanics are the same everywhere even though the layout differs.
Here are the common tasks mapped to the records they require:
| Task | Records to add or edit |
|---|---|
| Point your domain to a host | A record (and AAAA if using IPv6) |
| Set up email | MX records, plus TXT for SPF and DKIM |
| Tighten email security | TXT record for DMARC policy |
| Verify a service (analytics, search console, mail) | TXT record with the provided string |
| Add a subdomain | A record (to an IP) or CNAME (to a hostname) |
| Restrict SSL issuance | CAA record |
What are synthetic or auto-managed DNS records?
A practical wrinkle in the rules above involves the apex (root) domain — for example `example.com` with no `www`. Strict DNS rules say you cannot put a CNAME on the apex, yet many modern services hand you a hostname rather than a fixed IP. To bridge that gap, some providers offer auto-managed records — sometimes called synthetic, dynamic, or aliased records — that behave like a CNAME at the apex.
Conceptually, these are records the provider generates and resolves on your behalf. When a resolver asks for the apex, the provider looks up the target hostname behind the scenes and returns the current address as if it were a normal A record. If the target’s IP changes, the provider updates the answer automatically, so you never edit anything. The same idea covers records a provider auto-populates for you when you enable a feature — created and maintained dynamically rather than typed in by hand.
The practical takeaway: if your host offers an alias-style or auto-managed record, it solves the “I have a hostname but need to point my apex” problem without violating DNS rules. The implementation differs between providers, but the concept is consistent — a dynamically generated record standing in for one you would otherwise have to maintain manually.
Managing DNS records with DarazHost
DarazHost gives you a simple DNS zone editor to manage every record type — A, CNAME, MX, TXT, and more — with sensible defaults and quick propagation. That means pointing your domain to your host, setting up email authentication (SPF, DKIM, and DMARC), and adding subdomains is straightforward rather than intimidating. You get full DNS control backed by 24/7 support, so whether you are launching a first site or migrating an established domain, the routing just works. Manage your domain’s complete DNS zone from one clear dashboard.
What are the most common DNS record mistakes?
Most DNS problems trace back to a short list of avoidable errors:
- Editing records at the wrong place. If your nameservers point elsewhere, the registrar’s zone editor is ignored. Always edit at the authoritative host.
- Putting a CNAME on the apex. This breaks DNS rules; use an A record or an alias-style auto-managed record instead.
- Forgetting SPF/DKIM after setting MX. Mail may route but land in spam without proper authentication.
- Multiple conflicting SPF records. A domain should publish exactly one SPF TXT record; merge includes instead of adding a second.
- Expecting instant changes. A high TTL means caches hold old values; lower TTL before migrations.
- Deleting the wrong record during cleanup. Removing an active A, MX, or NS record can take a service offline immediately.
A methodical approach — change one record, confirm it resolves, then move on — prevents nearly all of these.
Frequently asked questions
What is the difference between an A record and a CNAME? An A record points a name directly to an IP address. A CNAME points a name to *another name*, which then resolves to an IP. Use an A record for the apex domain and a CNAME for subdomains that should follow another hostname.
Can I have email and my website on different providers? Yes. This is normal. Your A record can point your website to one host while your MX records send email to a completely separate provider. They operate independently under the same domain.
Why isn’t my DNS change taking effect? The most likely cause is caching governed by TTL. Resolvers hold the old value until the TTL expires. Confirm you edited the record at the authoritative nameserver, then wait for propagation.
Do I need a TXT record for email? For reliable delivery, yes. TXT records publish SPF and DMARC, and a TXT or CNAME publishes DKIM. Without them, mail you send may be flagged as spam or spoofing.
What is a TXT record used for besides email? Domain and service verification. Many platforms ask you to add a TXT record with a unique string to prove you control the domain before they enable a feature.
