A DNS record is a data entry stored in a DNS zone on an authoritative nameserver that provides specific instructions about how to handle requests for a domain or subdomain. Every domain on the internet is associated with a set of DNS records that define where its web traffic goes, where its email goes, how its SSL certificates are validated, and how other services interact with it.

When a browser looks up example.com to find the IP address of its web server, it is ultimately retrieving a DNS record: specifically an A record, that maps the domain name to the server’s IP address. When an email server looks up where to deliver a message addressed to someone@example.com, it retrieves a MX record that specifies the mail server responsible for that domain. When a service needs to verify that someone controls a domain before issuing an SSL certificate, it checks for a TXT record containing a specific verification string.

DNS records are the instructions that make the internet’s domain name system function. Without them a domain name is just a string of characters with no connection to any server, service, or functionality. With the right records configured a domain can route web traffic, receive email, prove ownership for SSL issuance, and connect to any number of services, all through the DNS record layer.

How DNS records work

DNS records are stored on authoritative nameservers, the servers that hold the definitive, current records for a domain. When any DNS resolver anywhere in the world needs to look up information about a domain it ultimately queries the authoritative nameserver for that domain and retrieves the records stored there.

Each DNS record has several components that together define what it does and how it behaves.

Name: the domain or subdomain the record applies to. example.com for the root domain, www.example.com for the www subdomain, mail.example.com for a mail subdomain. The @ symbol is often used as shorthand for the root domain in DNS management interfaces.

Type: the record type that defines what kind of information the record contains and how it is used. A, AAAA, CNAME, MX, TXT, NS, and others. Each type has a specific purpose and specific rules about what values it can contain.

Value: the actual data the record contains. For an A record this is an IP address. For a CNAME record this is a domain name. For a TXT record this is a text string. For an MX record this is a mail server hostname with a priority value.

TTL: Time To Live. The duration in seconds that DNS resolvers should cache the record before querying the authoritative nameserver again for a fresh copy. A TTL of 3600 means the record is cached for one hour. Lower TTLs mean faster propagation of changes. Higher TTLs reduce DNS query load but slow down how quickly changes take effect.

Priority, used by certain record types, most notably MX records, to specify preference order when multiple records of the same type exist. Lower numbers indicate higher priority.

The main DNS record types

Understanding the different DNS record types and their specific purposes is essential for anyone managing domains, configuring redirect management, or troubleshooting DNS issues.

A record: the most fundamental DNS record type. Maps a domain or subdomain directly to an IPv4 address, the four-number format like 93.184.216.34. When a browser resolves example.com to connect to its web server, it is retrieving an A record. A records are used for root domains and subdomains that need to point directly to a server IP address.

A records cannot point to another domain name, only to an IP address. This creates a specific challenge for root domains, also called apex domains, because many hosting and redirect management services provide a domain name rather than an IP address for connection. Since root domains cannot use CNAME records, the record type for pointing one domain to another domain, they must use an A record, which requires knowing the IP address of the target infrastructure.

AAAA record: the IPv6 equivalent of an A record. Maps a domain or subdomain to an IPv6 address, the longer hexadecimal format like 2606:2800:220:1:248:1893:25c8:1946. As IPv6 adoption grows, AAAA records are increasingly important alongside A records for complete IP connectivity.

CNAME record: Canonical Name record. Maps a domain or subdomain to another domain name rather than directly to an IP address. When a resolver encounters a CNAME it follows the alias, looking up the target domain and returning its IP address. www.example.com → example.com means the resolver looks up example.com‘s IP address and returns it for www.example.com as well.

CNAME records are the most common way to connect domains to redirect management services, CDNs, and hosted platforms. When connecting a domain to Redirect Supply, adding a CNAME record pointing www.yourdomain.com to the redirect infrastructure tells the DNS system to route all requests for that subdomain to the redirect service’s servers. Redirect rules configured in the platform then handle where visitors are ultimately sent via HTTP redirects.

CNAME records cannot be used for root domains, example.com rather than www.example.com, because the DNS specification prohibits CNAME records at the zone apex. Some DNS providers offer ALIAS or ANAME records as extensions that provide CNAME-like behaviour at the apex, resolving a domain name to an IP address dynamically, but these are not standard DNS record types and are implemented differently by different providers.

TXT record: stores arbitrary text data associated with a domain. TXT records have no specific technical function in DNS routing; they are used as a flexible mechanism for storing verification strings, policy information, and configuration data that other services check.

Common TXT record uses include domain ownership verification: a service instructs the domain owner to add a specific TXT record, then checks for its presence to confirm control of the domain. SSL certificate issuance via DNS validation follows this pattern. SPF records, specifying which mail servers are authorised to send email for a domain, are stored as TXT records. DKIM public keys for email authentication are stored as TXT records. When connecting a domain to many redirect management and hosting services a TXT record verification step is typically required.

MX record: Mail Exchanger record. Specifies the mail server or servers responsible for receiving email for a domain. MX records contain a hostname, the mail server’s domain name, and a priority value. Multiple MX records can exist for a domain with different priorities, lower priority numbers are tried first, higher numbers are fallbacks.

example.com MX 10 mail.example.com means email addressed to @example.com should be delivered to the server at mail.example.com, with priority 10. MX records are critical for email delivery; without them email addressed to the domain has nowhere to go.

NS record: Nameserver record. Specifies the authoritative nameservers for a domain. NS records delegate DNS authority: they tell the global DNS system which nameservers hold the definitive records for a domain. example.com NS ns1.registrar.com means ns1.registrar.com is an authoritative nameserver for example.com.

Changing NS records, pointing a domain to different nameservers, moves DNS authority from one provider to another. This is what happens when a domain is transferred between registrars or when DNS is moved to a dedicated DNS provider like Cloudflare. After NS records change all DNS lookups for the domain query the new nameservers. NS record changes propagate more slowly than other record changes because nameservers are cached more aggressively throughout the DNS hierarchy.

CAA record: Certification Authority Authorization record. Specifies which certificate authorities are permitted to issue SSL certificates for a domain. example.com CAA 0 issue "letsencrypt.org" means only Let’s Encrypt is authorised to issue certificates for example.com. If a different CA attempts to issue a certificate it checks the CAA record and refuses if it is not listed. CAA records are a security measure that prevents unauthorised certificate issuance.

SOA record: Start of Authority record. Every DNS zone has exactly one SOA record containing administrative information: the primary nameserver for the zone, the email address of the zone administrator, a serial number for tracking zone changes, and timing parameters for zone transfers. SOA records are managed by DNS providers and rarely need to be manually configured by domain owners.

SRV record: Service record. Specifies the location of servers for specific services and protocols. SRV records contain service name, protocol, priority, weight, port, and target hostname. Used by protocols like SIP for VoIP and XMPP for messaging to locate the appropriate servers for specific services.

PTR record: Pointer record. The reverse of an A record, maps an IP address back to a domain name. Used for reverse DNS lookups. PTR records are important for email deliverability, mail servers often check the PTR record of the sending server’s IP address to verify it matches the sending domain.

ALIAS / ANAME record, not a standard DNS record type but an extension offered by some DNS providers. Provides CNAME-like behaviour for root domains where CNAME records are prohibited. The provider resolves the target domain to an IP address at the DNS level and returns the IP address to resolvers, behaving like an A record from the outside while being configured like a CNAME. Used to point root domains to CDNs, load balancers, and redirect management services that only provide a hostname rather than an IP address.

DNS records and redirect management

DNS records are the first layer of any redirect management setup: they determine whether requests for a domain reach the redirect management infrastructure at all. HTTP redirect rules handle where visitors go from there. Both layers are required for redirect management to function correctly.

Connecting a domain via CNAME: the standard connection method for subdomains. Adding a CNAME record pointing www.yourdomain.com to the redirect infrastructure ensures all requests for the www subdomain are routed to the redirect service’s servers. The redirect service then applies HTTP redirect rules to determine the response for each request.

Connecting a root domain, connecting yourdomain.com, without www, requires different handling because CNAME records cannot be used at the zone apex. Options include using an ALIAS or ANAME record if the DNS provider supports it, changing nameservers to a provider that offers apex CNAME-like functionality, or using A records pointing directly to the redirect infrastructure’s IP addresses if they are stable.

TXT record verification: many redirect management services and CDNs require domain ownership verification before activating redirect rules for a domain. The verification is typically done by adding a TXT record with a specific value to the domain’s DNS: the service checks for the presence of this record to confirm the domain owner has authorised the connection.

DNS propagation timing, after DNS records are updated to point a domain to redirect management infrastructure, there is a propagation window during which some visitors still reach the old infrastructure while others reach the new. The duration depends on the TTL of the records being changed. Lowering TTL values before making DNS changes reduces this window.

Managing DNS records

DNS records are managed through the DNS provider’s control panel or API. For most domains the DNS provider is the domain registrar, the company where the domain was purchased. For domains using external DNS, routing DNS through a provider like Cloudflare while keeping registration elsewhere, records are managed in the external DNS provider’s interface.

Adding records: specify the record type, name, value, and TTL. For a CNAME connecting www.example.com to redirect infrastructure: type CNAME, name www, value proxy.redirect.supply, TTL 3600.

Updating records: change the value of an existing record. Updates take effect after the current TTL expires for resolvers that have cached the old value.

Deleting records: remove records that are no longer needed. The impact of deletion depends on the record type, deleting an A record for the web server makes the domain unreachable. Deleting a TXT verification record may disconnect a service that relies on it.

Checking records: DNS records can be inspected using command line tools like dig - dig example.com A returns the A record for example.com, or online DNS lookup tools. Checking records is essential during redirect management setup to confirm changes have taken effect and are propagating correctly.