DNS records tell browsers, mail servers, and online services where to find your domain and how to trust it. This reusable cheat sheet explains the records you are most likely to configure—A, AAAA, CNAME, MX, TXT, SRV, SPF, DKIM, and DMARC—with examples, sensible TTL guidance, and a troubleshooting checklist for websites, email, and domain verification.
Overview
The Domain Name System (DNS) translates human-readable names such as example.com into information that software can use. Your DNS provider may be your domain registrar, web host, email host, CDN, or a dedicated DNS service. The interface differs between providers, but the record concepts are the same.
DNS records normally include a name or host, a type, a value, and a TTL. The name identifies the hostname, such as @ for the root domain or www for www.example.com. TTL, or time to live, tells DNS resolvers how long they may cache the answer. A lower TTL can make planned changes easier to roll back, while a higher TTL can reduce repeated lookups. Use your provider's default unless you have a reason to change it; a value around one hour is a common starting point, but provider defaults vary.
Before editing records, record the current configuration or export a DNS zone if your provider supports it. Do not replace existing records simply because another service supplied a different list. A domain can host a website, email, verification services, and other applications at the same time.
DNS records cheat sheet
| Record | Purpose | Example | Typical guidance |
|---|---|---|---|
| A | Maps a hostname to an IPv4 address. Use it when a website or server gives you an IPv4 address. | @ → 203.0.113.10 | Use the exact address supplied by your host. Do not add a port number. |
| AAAA | Maps a hostname to an IPv6 address. | @ → 2001:db8::10 | Add it only when your service provides a correct IPv6 address. An incorrect AAAA record can make some visitors reach the wrong server. |
| CNAME | Aliases one hostname to another hostname. | www → sites.example-host.com | Use a hostname as the target, not an IP address. A CNAME generally cannot share the same name with other ordinary records. |
| MX | Specifies which mail servers receive email for the domain. | @ → mail.example-provider.com | Enter the priority supplied by your mail host. Lower numeric values usually mean higher priority. |
| TXT | Stores text used for domain verification, security policies, and service configuration. | @ → verification=token-value | Copy the value exactly, including punctuation and quotation handling required by the DNS interface. |
| SRV | Publishes the host and port for a named service. | _service._tcp → 10 5 443 service.example.com | Use the service's required name, protocol, priority, weight, port, and target. Do not guess these fields. |
| SPF | Defines which systems may send email for your domain. SPF is published as a TXT record. | @ → v=spf1 include:mail.example-provider.com ~all | Maintain one effective SPF policy for a domain. Combine authorized senders instead of publishing competing SPF records. |
| DKIM | Publishes a public key that receiving mail systems use to check a sender's DKIM signature. DKIM is commonly published as TXT, though a provider may specify another format. | selector1._domainkey → v=DKIM1; k=rsa; p=public-key | Use the selector and complete key supplied by your email provider. Keep the private key out of DNS and out of public code repositories. |
| DMARC | Instructs receiving systems how to handle mail that fails authentication alignment and provides reporting options. DMARC is published as TXT. | _dmarc → v=DMARC1; p=none; rua=mailto:dmarc@example.com | Start with a monitored policy when appropriate, review reports, then tighten enforcement carefully. |
Examples use documentation-style values and are not ready to paste into a live domain without replacing them. Always use the exact values supplied by your hosting, email, CDN, or SaaS provider.
Checklist by scenario
Point a domain to a website
- Confirm whether the host wants an A record, an AAAA record, a CNAME, or a combination.
- For the root domain, add the host's supplied A and/or AAAA records if it provides IP addresses. If it supplies a hostname, follow its instructions for root-domain aliasing rather than forcing a CNAME where the DNS provider does not support it.
- For
www, use a CNAME when the host supplies a destination hostname, or use the requested A/AAAA records. - Remove obsolete records for the same hostname only after confirming they belong to the old service.
- Add the domain inside the website or hosting dashboard, then complete any verification step.
- After DNS updates are visible, test both the root domain and
www. Confirm that HTTPS is configured separately; DNS alone does not install an SSL certificate.
For background on the wider launch process, see the Domain and Hosting Setup Checklist and SSL Certificates Explained.
Set up custom-domain email
- Add the mail provider's MX records with the exact hostnames and priorities it specifies.
- Check whether the provider requires an SPF TXT record. If your domain already has SPF, edit the existing policy rather than adding a second one.
- Publish each DKIM record at the selector hostname supplied by the provider, often under
_domainkey. - Add a DMARC TXT record at
_dmarc. A monitoring policy can help you learn which systems send mail before you enforce a stricter policy. - Send test messages to more than one receiving mailbox and inspect the authentication results. Also test replies and messages sent from every legitimate platform, such as a website form or ticketing system.
Do not add an A record as a substitute for MX records. A website's server and a domain's mail-receiving servers are separate functions. Use the Custom Domain Email Setup Guide for a broader setup sequence.
Verify a domain for a service
- Choose the verification method requested: usually a TXT record, but sometimes a CNAME or a file on the website.
- Enter the host exactly as shown. Some DNS dashboards automatically append your domain, so entering the full domain can accidentally create a duplicated name.
- Preserve capitalization, hyphens, underscores, and the complete token.
- Wait for the record to become visible, then use the service's verification button. Remove the record only if the service says it is no longer needed.
Choose between A, AAAA, and CNAME
Use A for an IPv4 address, AAAA for an IPv6 address, and CNAME when the provider gives you another hostname. A CNAME follows the destination's future address changes; an IP record points directly to an address. If a provider gives both an IP and a hostname, follow its documented recommendation rather than mixing options.
What to double-check
- Nameservers: DNS records are managed wherever the domain's active nameservers point. Editing records at the registrar will not help if another DNS provider is authoritative.
- Host formatting:
@, a blank host field, and the full domain may mean different things in different dashboards. Check the provider's field description. - Trailing dots: Some systems display fully qualified hostnames with a trailing dot, while others add it automatically. Follow the interface's convention.
- Duplicate records: Multiple A or TXT records can be valid, but duplicates can also conflict. Review each one before deleting it.
- TTL and propagation: DNS changes are cached. Check authoritative DNS and multiple public resolvers instead of assuming that one device's result represents everyone.
- Email authentication: SPF, DKIM, and DMARC must account for every legitimate sending platform. Adding authentication for one provider does not automatically authorize another.
- Mail routing: Confirm that old MX records are removed when the migration is complete, unless the mail provider explicitly requires multiple destinations.
- DNSSEC: If DNSSEC is enabled, a nameserver or DNS-provider change may require updated signing information. Treat DNSSEC changes as a planned migration, not a casual record edit.
Common mistakes
Changing nameservers and records at the same time: This makes it harder to identify the cause of an outage. Decide which DNS provider should be authoritative, confirm its zone, and then make record changes there.
Using a CNAME at the wrong level: A CNAME cannot normally coexist with other records at the same hostname. For example, do not place a CNAME and MX records on the same name.
Publishing multiple SPF records: Email systems may treat separate SPF records as an error. Keep one policy and include all approved senders in it.
Copying a DKIM key incompletely: A missing character, line break, or selector can make DKIM fail. Copy the value from the mail provider and verify it after saving.
Switching MX records before the new mailbox is ready: Prepare users, aliases, forwarding, and historical-mail access before changing delivery routes.
Assuming propagation is an error: Cached answers can persist until their TTL expires. Check the record's authoritative answer first, then allow time for other resolvers to update. A DNS propagation checker can provide useful comparison points, but it does not override caching.
For a focused diagnostic workflow, use the DNS Troubleshooting Guide. Keep a record of changes in your domain portfolio documentation, especially before a registrar transfer; the Domain Portfolio Management Guide can help organize that inventory.
When to revisit
Recheck DNS whenever you move a website, change hosting, migrate email, add a CDN, connect a SaaS platform, rotate DKIM keys, or transfer a domain. Review it before seasonal planning cycles and before major launches, when a short outage or missed verification can have a larger impact.
Printable DNS checklist
- Record the active nameservers and DNS provider.
- Export or document the current zone before editing.
- Confirm the intended website records for the root domain and
www. - Confirm MX records and mail-provider priorities.
- Maintain one complete SPF policy.
- Verify DKIM selectors and public keys.
- Review DMARC policy and reporting destination.
- Check TXT and CNAME verification records for active services.
- Test website resolution, HTTPS, sending, receiving, and replies.
- Document the change, timestamp, TTL, and rollback plan.
After each change, test from an authoritative lookup and from more than one network or resolver. If the result is still unclear, compare the current records with the provider's original setup instructions rather than adding more records at random. A small, documented DNS zone is easier to secure, migrate, and troubleshoot than one filled with records whose owners and purposes are unknown.
