DNS records are the instructions that tell the internet where your website, email, and connected services belong. This practical reference explains the most common record types, shows which one to use in typical scenarios, and gives you a safe checklist for editing DNS settings without creating avoidable conflicts.
Overview
When you register a domain name, the domain itself does not automatically know which web server should display your site or which provider should receive your email. DNS, or the Domain Name System, supplies that information through records stored with your DNS provider or domain registrar.
Each record has a specific job. An A record points a hostname to an IPv4 address. An AAAA record points it to an IPv6 address. A CNAME record points one hostname to another hostname. MX records identify email servers, while TXT records hold text-based instructions used for verification and email authentication. An SRV record identifies the host and port for certain services.
| Record | Primary purpose | Typical use |
|---|---|---|
| A | Maps a hostname to an IPv4 address | Pointing a domain or subdomain to a web server |
| AAAA | Maps a hostname to an IPv6 address | Supporting a service with an IPv6 address |
| CNAME | Aliases one hostname to another hostname | Connecting a subdomain to a hosted service |
| MX | Specifies mail servers and delivery priority | Setting up email for a domain |
| TXT | Stores text used by services and administrators | SPF, DKIM, DMARC, and ownership verification |
| SRV | Specifies a service location, port, and priority | Applications that publish service connection details |
The exact field names vary between DNS dashboards. You may see fields labeled Name, Host, or Record; Value or Target; and Priority or Preference. Use the provider's current instructions when entering values, especially for email authentication and service verification.
Checklist by scenario
Pointing a website with an A record
- Confirm the web host has given you the correct IPv4 address.
- Add an A record for the required hostname. The root domain is often represented by @, although some dashboards use the full domain or leave the field blank.
- If the site also uses www, follow the host's instructions for that hostname. It may use a CNAME pointing to the root domain or to a provider-specific target.
- Check for older A, AAAA, or CNAME records on the same hostname that could send visitors elsewhere.
- Test both the root domain and the www version after allowing time for the change to become visible.
An A record is not interchangeable with a CNAME. Use the record type required by the hosting provider, and do not add several competing records simply because they appear in different setup guides.
Use a CNAME for a hosted subdomain
A CNAME is common when a service gives you a hostname such as service.example-provider.com. You might create app.example.com and point it to that target. Enter the alias as the name and the provider's hostname as the target. Do not add an IP address unless the provider specifically instructs you to use an A record instead.
Many DNS systems do not allow a CNAME and other record types to coexist on the same hostname. Keep the hostname clear of conflicting A, AAAA, MX, or TXT records unless your DNS provider explicitly supports the arrangement.
Set up email with MX records
- Obtain the complete MX record list from your email provider's current setup documentation.
- Add each mail server with the specified priority or preference value. Lower numerical values commonly indicate higher delivery preference, but follow the provider's instructions.
- Remove obsolete MX records only after confirming that the domain no longer needs the previous email service.
- Check the domain's TXT records for any required SPF, DKIM, or verification entries.
- Send test messages to and from an address on the domain, then review delivery results and authentication information where available.
MX records control where incoming mail is delivered. They do not create mailboxes, activate a subscription, or replace the email provider's account setup.
Add SPF, DKIM, and DMARC with TXT records
SPF identifies servers authorized to send mail for your domain. It is published as a TXT record, and a domain should have one consolidated SPF policy rather than several separate SPF records. If multiple services send email, combine their authorized mechanisms according to their documentation.
DKIM uses a provider-generated public key, usually published as a TXT record at a selector-based hostname such as selector._domainkey. The provider keeps the corresponding private key and signs outgoing messages. Copy the value exactly, including any required formatting.
DMARC is also published as a TXT record, commonly at _dmarc. It tells receiving systems how to handle messages that do not align with the domain's authentication signals and can provide reporting instructions. Start with a policy appropriate for your confidence in the domain's legitimate senders, then strengthen it after reviewing results. Do not copy an unfamiliar policy without understanding its reporting addresses and enforcement effect.
Verify ownership of a service
A service may ask you to add a TXT record with a unique token. Create the record at the exact hostname specified, preserve punctuation and capitalization when instructed, and do not remove existing TXT records. Verification can fail if the token is placed at the root when the service expects a subdomain, or if quotation marks are entered even though the dashboard adds them automatically.
Use an SRV record when a service requires one
SRV records generally include a service name, protocol, priority, weight, port, and target hostname. They are not a general replacement for A or CNAME records. Copy every field from the service's setup guide and confirm whether the dashboard expects a combined value or separate fields. SRV syntax is easy to misread, so avoid guessing.
What to double-check
- Where DNS is hosted: Make changes in the active DNS provider, which may differ from the company where you completed domain registration.
- Hostname format: Some dashboards automatically append your domain. Entering the full domain when only a host label is expected can create an unintended name.
- Existing records: Export or screenshot the current zone before editing. Record the old value, purpose, and date of each change.
- Conflicts: Check for duplicate MX records, multiple SPF records, an A record alongside a CNAME on the same name, and stale verification tokens.
- TTL: Time to live controls how long resolvers may cache a response. A shorter TTL can make planned changes easier to adjust, while a longer TTL can reduce repeated lookups. Use the default unless you have a reason to change it, and lower it before a planned migration when the provider recommends doing so.
- Propagation versus errors: Different networks may see old and new answers during caching. If the result remains wrong beyond the expected window, inspect the record, nameservers, conflicts, and provider-specific requirements rather than repeatedly editing it.
- Security: Protect the registrar and DNS provider accounts with strong, unique credentials and multi-factor authentication where available. Limit access to people who need to manage DNS.
Common mistakes
Editing the wrong DNS zone: A domain can be registered with one company while its nameservers direct DNS queries to another. Confirm the authoritative nameservers before making changes.
Leaving old email records in place: An outdated MX record can continue directing mail to a previous provider. Review the full MX set during an email migration.
Publishing several SPF records: Multiple SPF TXT records can make authentication fail. Consolidate authorized senders into the single policy required by your setup.
Replacing every TXT record: Verification, DKIM, SPF, and other services may share a domain. Add the new entry without deleting unrelated records.
Using an IP where a hostname is required: CNAME and SRV targets are typically hostnames, not IP addresses. Follow the requested record type and value format.
Changing DNS repeatedly while testing: Frequent edits make it difficult to know which version is cached. Make one documented change, check it with more than one DNS lookup method, and then test the actual website or email service.
When to revisit
Return to this checklist before launching a website, moving to new web hosting, changing email providers, adding a marketing or analytics platform, or verifying a domain with a third-party service. Recheck DNS before seasonal campaigns or other high-traffic periods so that an old redirect, expired service, or unreviewed email record does not go unnoticed.
Also review the zone after a domain transfer, nameserver change, security incident, or major change to who can access your registrar account. Provider instructions can change, so use this article to understand the record type and workflow, then confirm the exact syntax in the current documentation for your hosting or email service.
A safe final checklist is simple: identify the active DNS provider, back up the existing records, confirm the exact hostname and value, check for conflicts, set a sensible TTL, make one change at a time, and test the affected service. Document what you changed and why. That record will make the next DNS update faster and safer.
