DNS Records: How the Web Finds Your Server
Every time you type a domain name into a browser, a chain of events happens silently in the background. The browser asks a DNS server what IP address belongs to that domain. The DNS server responds, the browser connects to that address, and your website loads. Without DNS, you would need to remember strings of numbers like 192.0.2.42 for every site you visit.
When you set up a website, you configure DNS records so that your domain points to your server. Getting these wrong means your site becomes unreachable, email stops working, or services break in ways that are harder to diagnose than they should be. A clear understanding of what each record type does makes you more self-sufficient when things go wrong and helps you make better decisions about your hosting setup.
What DNS Records Actually Do
DNS records are instructions stored on authoritative nameservers. These nameservers answer queries from other DNS servers around the world. When someone types your domain into their browser, their ISP's resolver queries your nameservers and returns the appropriate record based on the record type requested.
Each record type serves a specific purpose. A records resolve domain names to IPv4 addresses. AAAA records do the same for IPv6. CNAMEs create aliases between domain names. MX records direct email to the right mail servers. TXT records hold verification strings and policy data. Together, these record types form the backbone of how your domain communicates across the internet.
The way you configure these records depends on your hosting setup, email provider, and what services you run. A small business in the UK running a WordPress site on a VPS needs different DNS configuration than a company using Google Workspace with cloud-hosted applications. Understanding the fundamentals helps you adapt to either situation.
A Records: Pointing a Domain to an IPv4 Address
An A record maps a domain name to an IPv4 address. It is the most fundamental record type and the starting point for most website configurations. When someone visits yourdomain.co.uk, the DNS system looks up the A record and returns your server's IP address.
To create an A record, you need your server's public IPv4 address. You can find it by running this command on your server:
curl ifconfig.meIn your DNS provider's control panel, add an A record with these values:
Name: @ (or yourdomain.co.uk)
Type: A
Value: 203.0.113.42 (your server IP)
TTL: 3600 (1 hour)The @ symbol represents the bare domain without any prefix. Some DNS providers require the full domain name instead of @. Check your provider's documentation if you are unsure which format they use.
Set the TTL (Time to Live) to a lower value while you are setting things up. A TTL of 3600 seconds means changes propagate within an hour rather than waiting 24 to 48 hours for cached records to expire. After confirming everything works correctly, you can increase the TTL to reduce DNS query load on your nameservers.
If you want www.yourdomain.co.uk to work alongside your bare domain, you need a separate record for www. You have two options: create another A record pointing to the same IP, or create a CNAME that points www to your bare domain. The CNAME approach is often cleaner because you only need to update one A record if your server IP changes.
AAAA Records: IPv6 Addresses
AAAA records map domain names to IPv6 addresses. The name comes from the record type being four times the length of an A record, reflecting the longer IPv6 address format.
If your server has an IPv6 address assigned, creating AAAA records improves your site's compatibility with visitors connecting over IPv6. Many modern servers have IPv6 addresses by default from their hosting provider. You can check whether your server has one configured:
ip -6 addr showA typical AAAA record configuration looks like this:
Name: @
Type: AAAA
Value: 2001:0db8:85a3:0000:0000:8a2e:0370:7334
TTL: 3600IPv6 adoption varies by network and region. Having correct AAAA records does not hurt your site if IPv6 is not widely available to your visitors, but having incorrect AAAA records pointing to addresses your server does not actually use can cause connectivity issues for IPv6-capable visitors.
CNAME Records: Aliases for Subdomains
A CNAME record (Canonical Name) creates an alias by pointing one domain name to another domain name rather than directly to an IP address. The canonical domain it points to must itself have an A record, AAAA record, or another CNAME that eventually resolves to an address.
The most common use case is directing www.yourdomain.co.uk to yourdomain.co.uk:
Name: www
Type: CNAME
Value: yourdomain.co.uk
TTL: 3600CNAMEs are also used when subdomains serve content from third-party services. Pointing assets.yourdomain.co.uk to your-cdn-provider.example.net, or pointing shop.yourdomain.co.uk to your online store platform are both typical CNAME configurations. When you route traffic through a load balancer or reverse proxy, CNAME records can point subdomains to the appropriate service endpoint.
One important restriction applies: CNAMEs cannot coexist with other record types for the same name. If you create a CNAME for www, you cannot also have an A record for www. The CNAME effectively replaces all other records for that subdomain. Some DNS providers enforce this strictly, while others may allow conflicting records that cause unpredictable results.
Additionally, not all DNS providers allow CNAME records on the bare domain (@). Some permit it, while others require an A record for the bare domain and restrict CNAMEs to subdomains only. If you need a CNAME on your bare domain and your provider does not support it, consider using a redirect service at your registrar level instead.
MX Records: Where Email Is Delivered
MX (Mail Exchange) records tell mail servers where to deliver email sent to your domain. Unlike other record types, MX records include a priority value. Lower numbers have higher priority. Mail servers attempt delivery to the highest priority record first and fall back to lower priority records if the primary server is unavailable.
For small businesses using a third-party email provider, the configuration typically looks like this using Google Workspace as an example:
Name: @
Type: MX
Value: 1 aspmx.l.google.com
Priority: 1
TTL: 3600
Name: @
Type: MX
Value: 5 alt1.aspmx.l.google.com
Priority: 5
TTL: 3600Most business email providers give you two or three MX records to configure. Set them all, in the correct priority order, even if you think you only need the primary server. If the primary provider has an outage, mail queues on the secondary server and delivers when the primary comes back online. Missing secondary MX records means mail is lost when the primary is unavailable.
A common mistake is setting MX records to point to a CNAME rather than an A record. MX records must point to a hostname with an A record, not directly to an IP address or a CNAME alias. Some DNS providers allow non-standard MX configurations, but these cause delivery failures with many receiving mail servers.
If you are setting up your own mail server, getting the DNS configuration right is only part of the process. The full email system setup involves configuring your mail transfer agent, enabling authentication, and ensuring proper security records are in place. A complete walkthrough of email system and SMTP configuration on Ubuntu covers both the DNS records and the server-side configuration needed for reliable delivery.
TXT Records: Verification and Policy Instructions
TXT records serve two main purposes: domain verification and policy instructions for receiving systems.
Domain verification records prove you own the domain when setting up third-party services. Google Workspace, Microsoft 365, Mailchimp, and many other platforms ask you to add a TXT record to your DNS during setup. The record contains a unique string that the service generates. When the service queries your DNS and finds the matching record, it confirms you control the domain.
SPF (Sender Policy Framework) records use TXT format to specify which mail servers are authorised to send email for your domain. This prevents other servers from sending email that appears to come from your domain, a technique called email spoofing. SPF is one of three core email authentication methods alongside DKIM and DMARC.
A basic SPF record looks like this:
Name: @
Type: TXT
Value: v=spf1 mx ip4:203.0.113.42 -all
TTL: 3600This tells receiving mail servers that only the servers listed in your MX records and the IP address 203.0.113.42 are authorised to send email from addresses at yourdomain.co.uk. The -all at the end means emails from any other server should be treated as failed authentication.
If you use multiple services to send email on behalf of your domain, you need to include all of them in your SPF record. For example, if you send transactional emails from your own server and marketing emails through a third-party platform, both need to be listed:
v=spf1 mx ip4:203.0.113.42 include:servers.mcsv.net -allUsing include: directives pulls in the SPF records of third-party services without needing to list their individual IP addresses. Most major email service providers publish SPF records that you can include this way.
DKIM: Cryptographic Email Signing
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to emails sent from your domain. Receiving mail servers verify this signature using a public key published in your DNS as a TXT record. This proves that emails claiming to come from your domain were actually signed by your mail server's private key.
DKIM is typically enabled from your email provider's control panel. The provider generates a public/private key pair and asks you to add a DKIM record to your DNS. The record name follows a specific pattern that your provider specifies:
Name: google._domainkey.yourdomain.co.uk
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB...
TTL: 3600The name prefix (google in this example) is specific to your email provider and identifies which DKIM key to use if your provider uses multiple keys. Follow your provider's DKIM setup instructions exactly because they generate the exact record for your configuration.
Setting up DKIM requires both DNS configuration and correct mail server settings. For those configuring their own mail server, enabling DKIM signing in Postfix SMTP authentication involves generating keys, configuring the mail transfer agent, and publishing the public key in DNS.
DMARC: Telling Receivers What to Do With Suspicious Email
DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM. It tells receiving mail servers what to do when an email fails authentication checks. Without DMARC, receiving servers make their own decisions about how to handle authentication failures. DMARC gives you control over that decision.
DMARC records are TXT records with a specific naming convention starting with _dmarc:
Name: _dmarc.yourdomain.co.uk
Type: TXT
Value: v=DMARC1; p=quarantine; rua=mailto:admin@yourdomain.co.uk
TTL: 3600The p=quarantine policy tells receiving servers to treat failing emails as suspicious and move them to spam. The p=reject policy tells them to reject the email entirely. The rua parameter specifies an email address that receives aggregate reports of authentication failures, which is essential for monitoring whether your email authentication is working correctly.
When starting out, set p=none to monitor only. This lets you see reports of authentication failures without affecting email delivery. Once you have confirmed SPF and DKIM are working for all legitimate email sources, move to p=quarantine, and eventually to p=reject for maximum protection.
A full explanation of how SPF, DKIM, and DMARC work together, including common configuration mistakes and how to interpret DMARC reports, is available in the guide to SPF, DKIM and DMARC explained.
DNS Propagation: Why Changes Take Time
DNS records are cached at multiple levels: your ISP's resolver, your router, your operating system, and individual applications. When you change a DNS record, you update the authoritative answer on your nameserver, but cached copies of the old record persist until their TTL expires.
The TTL value on your records determines how long caches hold the old value. A TTL of 3600 means any resolver that cached the record will return the old value for up to one hour. The maximum time for any change to fully propagate equals the TTL of the original record.
Before making DNS changes, reduce the TTL to a low value (300 to 3600 seconds) several hours in advance. After the change has propagated and you have confirmed everything works, increase the TTL to a higher value like 86400 seconds to reduce DNS query load on your nameservers.
Test DNS changes before they are fully propagated using dig against public DNS servers. These tools query nameservers directly rather than your local cache, showing you what the authoritative answer is:
dig A yourdomain.co.uk @8.8.8.8
dig A yourdomain.co.uk @1.1.1.1If you see different results from different servers, propagation is still in progress. Online tools that query multiple DNS servers worldwide help you confirm whether changes have reached the global DNS system or are still limited to specific regions or providers.
How to Check Your DNS Configuration
Verifying your DNS records after making changes prevents problems before they affect your visitors or email delivery.
The dig command is available on Linux and macOS by default. On Windows, you can use nslookup or install dig separately. Query specific record types to check what is currently published:
dig MX yourdomain.co.uk
dig TXT yourdomain.co.uk
dig +trace yourdomain.co.ukThe +trace option follows the full DNS resolution path from root servers down to your authoritative nameservers. This is useful for identifying where resolution is failing if visitors report problems reaching your site.
Online tools like WhatsMyDNS and intoDNS query multiple DNS servers worldwide and display the results in a readable format. These are particularly useful for confirming global propagation after making changes.
When moving hosting providers, check the DNS configuration on both old and new servers before cutting over. Run a full comparison to identify any records that exist in one place but not the other. Missing records during a migration cause intermittent failures that are frustrating to diagnose.
Common DNS Mistakes That Break Things
Several DNS errors appear regularly and cause problems that are harder to diagnose than they should be.
- MX records pointing to CNAMEs or IP addresses: MX records must point to a hostname with an A record. Pointing directly to an IP or a CNAME alias causes delivery failures with many receiving mail servers.
- Forgetting the bare domain versus www distinction: Some DNS providers use @ to mean the bare domain, while others require the full domain name explicitly. Using the wrong format creates records that never match incoming queries.
- CNAMEs conflicting with other records: A CNAME record replaces all other record types for that name. Creating a CNAME for www while keeping an A record for www causes unpredictable results depending on which record the resolver finds first.
- Removing old records before new ones work: When switching hosting providers, both sets of records answer queries during propagation. Remove old records only after confirming the new ones are working everywhere.
- SPF records with too many lookups: SPF has a limit of 10 DNS lookups per record. Each
include:ormxdirective counts as a lookup. Exceeding this limit causes SPF to fail, which may result in emails being rejected.
After making any changes, verify the records are correct using dig or nslookup. Check that the record type, name, and value all match what you intended to set. Pay particular attention to spaces and punctuation because DNS records are sensitive to exact formatting.
Understanding the Full Picture Helps
DNS configuration is one of those areas where a basic understanding pays off repeatedly. When your email stops working, your website goes down, or you are switching hosting providers, knowing how DNS records function means you can diagnose problems faster and make informed decisions about what needs to change.
The record types covered here handle the vast majority of website and email setups. A records and CNAMEs handle web traffic. MX, SPF, DKIM, and DMARC handle email authentication. Once you are comfortable with these, most DNS tasks become straightforward. More specialised configurations follow the same pattern: add the record your provider generates, verify it propagates correctly, and monitor the results over time.
If you need a practical review of your current DNS setup or help with a specific configuration issue, you can get in touch with details of what you are trying to achieve.