DNS Records: How the Web Finds Your Server
Every time you type a domain name into a browser, a DNS lookup happens behind the scenes. The browser asks a DNS server what IP address belongs to that domain. The DNS server responds, the browser connects to that IP, and the website loads. DNS is the directory service that makes human-readable domain names usable instead of remembering strings of numbers like 192.0.2.42.
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 subtle ways that are hard to diagnose. Understanding what each record does makes you more self-sufficient instead of dependent on whoever set things up originally.
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. 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 IP address. You can find it on your server by running:
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 the www prefix. Set the TTL (Time to Live) to a relatively low value like 3600 seconds while you are setting things up. This means changes propagate within an hour rather than waiting 24 to 48 hours for old records to expire from DNS caches.
If you want www.yourdomain.co.uk to work alongside the bare domain, you need a separate A record for www, or a CNAME that points www to the bare domain.
AAAA Records: IPv6 Addresses
AAAA records do for IPv6 addresses what A records do for IPv4. If your server has an IPv6 address, create a AAAA record so visitors connecting over IPv6 reach your site:
Name: @
Type: AAAA
Value: 2001:0db8:85a3:0000:0000:8a2e:0370:7334
TTL: 3600Most modern servers have an IPv6 address assigned by default. Even if you do not actively configure AAAA records, having them set correctly improves your site's compatibility with IPv6-only networks and is increasingly considered a best practice for modern web hosting.
You can check whether your server has an IPv6 address using:
ip -6 addr showCNAME 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 or another CNAME.
The most common use case is www.yourdomain.co.uk pointing to yourdomain.co.uk:
Name: www
Type: CNAME
Value: yourdomain.co.uk
TTL: 3600CNAMEs are also used for subdomains that serve content from third-party services. For example, pointing cdn.yourdomain.co.uk to your-cdn-provider.fastly.net, or docs.yourdomain.co.uk to readthedocs.io. When you are setting up a CDN for your business website, CNAME records are the standard way to route traffic through the CDN provider's infrastructure.
CNAMEs cannot be created for the bare domain (@) on all DNS providers. Some allow it, while others require an A record for the bare domain and only permit CNAMEs for subdomains. Check with your DNS provider if you are unsure about their specific rules.
MX Records: Where Email Is Delivered
MX (Mail Exchange) records tell mail servers where to deliver email sent to your domain. Unlike A and CNAME records, MX records have a priority value. Lower numbers have higher priority. Mail servers try the highest priority record first and fall back to lower priority records if the primary server is unavailable.
For most small businesses using a third-party email provider, the configuration looks like this:
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: 3600The Google Workspace MX records shown here have two entries: the primary and the backup. Most business email providers give you two or three MX records to configure. Set them all, in order, even if you think you only need one. If the primary provider has an outage, mail queues on the secondary server and delivers when the primary comes back online.
Properly configured MX records are essential for reliable email delivery. If you are setting up your own mail server, you will find a detailed walkthrough of the full email system and SMTP configuration on Ubuntu useful for getting both the DNS records and the mail server software working together correctly.
TXT Records: Verification and Policy Instructions
TXT records serve two main purposes: domain verification and policy instructions for receiving mail servers.
Domain verification records prove you own the domain when setting up third-party services. Google Workspace, Microsoft 365, Mailchimp, and many other services ask you to add a TXT record to your DNS. The record contains a unique string that the service generates. The verification process checks that the record exists in your DNS, confirming you control the domain.
SPF (Sender Policy Framework) records use TXT format to specify which mail servers are allowed to send email for your domain. This prevents email spoofing and is one of the three core email authentication methods alongside DKIM and DMARC:
Name: @
Type: TXT
Value: v=spf1 mx ip4:203.0.113.42 -all
TTL: 3600This tells receiving mail servers: only the servers listed in your MX records and the IP address 203.0.113.42 are authorised to send email from @yourdomain.co.uk. The -all means "reject everything else".
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 marketing emails through Mailchimp in addition to your own mail server, the SPF record would include both:
v=spf1 mx include:servers.mcsv.net -allDKIM: 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.
DKIM is typically enabled from your email provider's control panel. The provider generates a public key and gives you a DKIM record to add to your DNS. The record name follows a specific pattern:
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. Follow the DKIM setup instructions from your provider because they generate the exact record for you. The public key published in DNS allows any receiving mail server to verify that emails claiming to come from your domain were actually signed by your mail server's private key.
Setting up DKIM properly requires both DNS configuration and correct mail server settings. If you are configuring this yourself, the process for Postfix SMTP authentication setup covers how to enable DKIM signing in your mail server software.
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. DMARC records are also TXT records, with a specific naming convention that starts with _dmarc:
Name: _dmarc.yourdomain.co.uk
Type: TXT
Value: v=DMARC1; p=quarantine; rua=mailto:[email protected]
TTL: 3600The p=quarantine policy tells receivers to treat failing emails as suspicious and move them to spam. p=reject tells them to reject the email entirely. The rua parameter specifies an email address that receives aggregate reports of authentication failures.
Starting with p=none (monitor only) while you test your configuration is a sensible approach. This allows you to see reports of authentication failures without affecting email delivery. Once you are confident SPF and DKIM are working correctly, you can move to p=quarantine and eventually p=reject.
A full explanation of how these three protocols work together, including common configuration mistakes and how to read 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 DNS server, your router, your operating system, and individual applications. When you change a DNS record, you are changing the authoritative answer, 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 DNS resolver that cached the record will hold it for one hour. The maximum propagation time for any change is equal to 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, you can increase the TTL to a higher value (86400 or more) to reduce DNS query load on your nameservers.
Test DNS changes before they are fully propagated using dig or online tools. These tools query multiple DNS servers worldwide and show you what the global DNS system is returning, rather than what your local ISP cache is serving:
dig A yourdomain.co.uk @8.8.8.8
dig A yourdomain.co.uk @1.1.1.1Common DNS Mistakes That Break Things
Several DNS errors appear frequently and cause problems that are harder to diagnose than they should be.
- MX records pointing to an IP address: MX records must point to a hostname with an A record, not directly to an IP. Some providers allow IP addresses in MX records, but this behaviour is non-standard and causes delivery failures with many mail servers.
- Leaving old DNS in place when switching hosts: Both sets of records answer queries until propagation is complete, which causes intermittent behaviour. Remove old records after confirming the new ones are working.
- Forgetting @ versus bare domain differences: 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 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 the same name causes unpredictable results.
After making 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.
Tools for Checking Your DNS Configuration
Several tools help you verify and troubleshoot DNS records.
The dig command is available on Linux and macOS. It queries DNS servers directly and shows you the full response:
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, which is useful for identifying where resolution is failing.
Online tools like WhatsMyDNS show what DNS records are returned from servers around the world. This helps confirm whether propagation has completed globally rather than just locally.
If you are moving hosting providers, check the DNS configuration on both the old and new servers before cutting over. Run a full DNS report comparing the two sets of records to identify any differences that need attention.
When to Seek Help With DNS Configuration
Most DNS tasks are straightforward once you understand what each record does. However, some situations benefit from professional help.
If your email is not being delivered and you have already verified your MX, SPF, DKIM, and DMARC records are correct, the issue may be with your mail server configuration or reputation. Configuring a complete email system with proper authentication involves several interdependent components that need to work together correctly.
Businesses that rely on their website and email for revenue should consider a professional review of their DNS configuration, particularly for records related to email authentication. Misconfigured SPF, DKIM, or DMARC records can cause legitimate emails to be rejected or marked as spam, which is difficult to detect without monitoring.
If you are planning a hosting migration, having someone check your DNS plan before making changes reduces the risk of downtime during the transition.
Understanding DNS Helps You Maintain Control
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. Once you are comfortable creating A records, CNAMEs, MX records, and TXT records, most DNS tasks become straightforward. The more specialised records like DKIM and DMARC follow the same pattern: add the record your provider generates, verify it propagates, and monitor the results.
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.