DNS records explained: a practical beginner’s reference

A DNS record is a structured piece of information associated with a name. Some records help a browser find a website; others route email, identify authoritative servers or publish information used by another service.

You do not need to memorise every record type to manage a small website. You do need to know which type the provider requires, where the active zone is hosted and what each field means before editing it.

Read the common fields first

The type says what kind of data the record contains. The name identifies the hostname or other label to which it applies. The value or content holds the address, target or text. TTL describes how long an answer may be cached.

Some types need additional fields. MX has preference values; SRV includes priority, weight and port. An interface may combine fields into one text box or present them separately, so follow the provider's format.

Many panels use @ for the zone apex and short labels such as www for subdomains. Others expect a complete name. Check whether the interface appends the domain automatically before entering a fully qualified hostname.

A: associate a name with IPv4

An A record contains an IPv4 address for the named service. A web host may tell you to create or replace one for the main domain. Use the address assigned to your hosting account or platform.

Do not put https://, a page path or an email address in the value. Those are different kinds of information. If a provider supplies a hostname rather than a number, it may require another record type or a platform-specific alias feature.

Several A records at one name can be intentional. Do not remove them merely because a tutorial shows one; compare the complete set with your provider's documented configuration.

AAAA: associate a name with IPv6

An AAAA record serves the corresponding address role for IPv6. Publish it when the destination service supports the supplied IPv6 address correctly.

A stale AAAA record is a common reason some connections reach an old service while others work. Updating the IPv4 A record does not update IPv6 automatically unless the platform specifically manages both.

During a migration, review both types. Test the actual website over the supported routes and confirm the certificate and host configuration at each destination.

CNAME: alias one DNS name to another

A CNAME identifies another hostname as the canonical target for the alias. A common use is connecting www or an application subdomain to a provider's assigned hostname.

The target is a name, not an IP address or a full URL. Ordinary CNAME records cannot coexist with other data at the same name. This also makes a normal CNAME unsuitable at an apex that requires its own zone information.

Some DNS platforms offer apex aliasing or flattening features. Follow their instructions rather than assuming the feature is standard CNAME behaviour everywhere.

A CNAME is not an HTTP redirect. It does not change the address in the browser or redirect /old/ to /new/. Configure those behaviours in the web service.

MX: route incoming email

MX records identify mail servers for a domain. They include preference numbers; lower values are generally preferred before higher ones. Use the complete set supplied by the mail provider.

The target is a mail-server hostname, not an email address or an IP field. The named service must also be configured to accept mail for your domain. Creating MX records does not create users or mailboxes.

MX does not authenticate your outgoing mail. SPF, DKIM and DMARC use additional records and policies. Keep those roles distinct when diagnosing delivery problems.

TXT: publish text for defined purposes

TXT records carry text interpreted according to the service using them. They can prove domain control, publish an SPF policy or support email-authentication information. Copy verification tokens exactly.

A single name can have multiple TXT records serving different purposes. However, publishing multiple competing SPF policies at the same name is not a valid way to add another mail sender. Combine the authorised sources according to SPF rules.

Do not remove an unfamiliar token until you know whether it supports an active service. Also avoid placing passwords or private application secrets into public DNS. A verification value is intentionally published according to its provider's process; that does not make TXT a private storage location.

NS: identify authoritative nameservers

NS records identify servers authoritative for a zone or delegated part of the namespace. The parent delegation and the child zone's own records have related roles in helping resolvers find the right source.

To move the domain's main authoritative service, update the registrar's nameserver settings through the appropriate process. Editing NS records only inside an old zone is not a substitute for changing the parent delegation.

A nameserver move can affect every service in the zone. Copy website, mail, authentication and verification records first. Private nameservers under the domain itself may also need parent-level glue arrangements.

SRV: locate a supported service

SRV records describe service locations for clients that know to use them. They specify a service and protocol name, target hostname, port, priority and weight.

Lower priority values are preferred; weight helps distribute choices among records with the same priority according to the protocol. These fields are not interchangeable with an MX preference or a percentage of website visitors.

Only use SRV where the application requires it. An ordinary browser does not automatically use an arbitrary SRV record to send a website to a different port. Follow the exact service documentation.

Other records you may encounter

SOA records hold administrative information about a zone and are usually managed by the DNS provider. DNSKEY and DS are part of DNSSEC's validation arrangements. CAA can express which certificate authorities may issue certificates under its policy.

These types deserve their own documented procedures. Do not delete an unfamiliar system-generated record simply to make the panel shorter. Ask the provider about its role and dependencies first.

Keep the required type with the value

When asking a colleague to make a change, send the record type, complete intended name, value and any additional fields together. A target hostname without its type can be ambiguous. Include the requesting service and purpose, then ask for a lookup of the exact record after saving. This makes the handover clearer than sending an isolated screenshot or number.

A safe edit-and-check routine

1. Confirm which provider is authoritative for the domain.
2. Export or record the current zone and identify the entry's purpose.
3. Copy the exact type, name and value from the relevant service instructions.
4. Review additional fields such as priority, port or TTL.
5. Save one planned change and query that record type.
6. Test the actual website, mail or application behaviour.
7. Record the successful configuration and responsible service.

Use example.com only as a documentation placeholder when following sample commands. For your domain, dig example.com MX illustrates an MX lookup and nslookup -type=txt example.com a TXT lookup. Replace the name with the one you control.

When a saved change is not visible

First check that you edited the active zone. Then query the authoritative server directly and compare a recursive resolver's answer. Correct source data with an old cached answer needs a different response from incorrect authoritative data.

TTL and negative-answer caching mean updates are not instant everywhere. DNSSEC inconsistencies can cause validation failure after a nameserver move. Once DNS returns the expected answer, continue testing the destination service rather than repeatedly changing correct records.