A domain can be registered, paid for and ready to use, yet still show a parking page or fail to receive email. In most cases, the missing piece is DNS. Knowing how to configure DNS records gives you control over where your website, email, verification services and subdomains point.

DNS, or the Domain Name System, is often described as the internet’s address book. That is useful, but it leaves out the practical detail: each DNS record tells browsers, mail servers and third-party services what to do with a specific part of your domain. A correct record gets visitors and messages to the right place. An incorrect one can take a live website or business email offline.

Start by finding where your DNS is managed

Before adding or changing anything, establish which provider holds the authoritative DNS for your domain. This is not always the company where you bought the domain or hosting.

Check the domain’s nameservers. If they point to your hosting provider, you will normally manage records in that provider’s DNS zone or control panel. If they point to a CDN, specialist DNS provider or website platform, make changes there instead. Editing records in the wrong dashboard has no effect because the internet is reading a different DNS zone.

It is also worth checking whether your domain is using custom nameservers. Changing nameservers can replace access to an existing DNS zone, which may remove working website and email records. For a simple record update, edit the current zone rather than changing nameservers unless you are deliberately moving DNS management.

The DNS records you will use most often

You do not need to memorise every DNS record type. Most website owners and small businesses use a handful of records repeatedly.

• A record connects a hostname to an IPv4 address. It is commonly used to point `example.co.uk` or `www.example.co.uk` to a web server.
• AAAA record does the same job for an IPv6 address. Only add it when your hosting provider has supplied an IPv6 address and supports it for your service.
• CNAME record makes one hostname an alias of another hostname. It is often used for `www`, service integrations and hosted platforms.
• MX record directs incoming email to the right mail server. MX records use priorities, so lower numbers are tried first.
• TXT record stores text-based settings. It is widely used for domain ownership checks and email authentication, including SPF, DKIM and DMARC.
• SRV record identifies the host and port for certain services, such as communications tools or Microsoft-related services.
• CAA record states which certificate authorities can issue SSL certificates for your domain. It is an optional but useful control for organisations with clear certificate-management policies.

Each record has a host or name field, a value or destination field, and a TTL. The host tells DNS which label the record applies to. In many control panels, `@` represents the root domain, while `www` represents `www.example.co.uk`. The value might be an IP address, hostname, verification token or email server address.

How to configure DNS records safely

The safest approach is to make one planned change at a time, particularly when email is involved. Collect the exact values from your hosting, email or software provider before opening the DNS manager. Do not rely on values from an old setup guide if the service has issued new details.

1. Record the current configuration

Take a copy of existing records before editing them. A screenshot is helpful, but a written record is better for long TXT values and MX priorities. Note the hostname, type, value, priority and TTL.

This simple step gives you a rollback option if a change does not behave as expected. It also helps identify records that must remain in place, such as the MX and TXT records supporting business email.

2. Add or edit the right hostname

If you are connecting a new website to hosting, your provider may ask you to point the root domain to an IP address using an A record. They may also ask you to create a CNAME for `www`.

For example, an A record could use `@` as the host and an IP address as the value. A separate `www` CNAME might point to the hostname supplied by the hosting platform. The exact combination depends on the hosting setup. Some providers use A records for both root and `www`; others need a CNAME for `www`.

Avoid placing a CNAME at the root domain if your DNS provider does not support it. Root domains often need other record types, such as MX and TXT, and standard DNS rules can make a root CNAME unsuitable. Use the record format your provider specifically recommends.

3. Keep email records intact when changing a website

Website DNS and email DNS are related because they use the same domain, but they are not the same service. Updating the A record for a website should not require deleting MX records, SPF records or DKIM records.

This is a common source of disruption during a hosting move. A customer removes every record in the zone, adds the new website entry and then discovers that email has stopped arriving. Unless you are also moving email, preserve the active MX and relevant TXT records exactly as they are.

If you are moving email, add the new provider’s MX records and authentication records carefully. Remove old MX records only when the new provider confirms the mailbox setup is ready. Mixed MX records from two unrelated providers can cause messages to go to the wrong place.

4. Use sensible TTL settings

TTL means Time To Live. It tells DNS resolvers how long they may cache a record before checking for an update. A shorter TTL can make planned changes appear sooner, while a longer TTL reduces repeated DNS lookups.

For day-to-day records, a TTL of one hour is a practical starting point. Before a planned migration, reduce it to 300 seconds a day or two in advance if your provider allows it. Once the move is stable, increase it again. Low TTLs are helpful during changeovers, but they do not force every network or device to refresh immediately.

5. Save, then check for duplicates and conflicts

A record can look correct and still fail because another record conflicts with it. Check for duplicate A or AAAA records, outdated `www` entries, and old CNAMEs left over from previous platforms.

Be especially cautious with TXT records. A domain can have multiple TXT records, so do not overwrite an SPF or verification entry merely because you are adding another service. SPF is the exception: you should have one SPF policy for a hostname. If a new email provider gives you an SPF value, it may need to be merged with the existing policy rather than added as a second SPF record.

Verify the change before assuming it has failed

DNS updates are not always instant. The provider may publish a record within minutes, but cached results can take longer to clear. The time depends on the previous TTL, local network caching and the resolver being used.

First, confirm the record is saved in the authoritative DNS zone. Then test it with a DNS lookup tool or command-line query, checking the record type and hostname you actually changed. Test the root domain and `www` separately because they can resolve differently.

For website changes, open the domain in a private browser window and test from a mobile connection as well as your usual Wi-Fi. For email changes, send a test message from an external address and check delivery, not just whether the message appears in a webmail sent folder.

If a service says a verification record cannot be found, compare every character of the host and value with the supplied instructions. Long DKIM values and verification tokens are easy to truncate or paste into the wrong field.

Common DNS mistakes that cause avoidable downtime

The most damaging DNS changes are usually small ones. Entering a full domain name into a host field that already appends the domain can create a duplicated address such as `www.example.co.uk.example.co.uk`. Other panels expect the full hostname, so read the field hint rather than assuming.

Another frequent problem is using an IP address in a CNAME value. CNAME records must point to hostnames, not IP addresses. Use an A or AAAA record for an IP address.

Email authentication deserves particular care. SPF, DKIM and DMARC improve legitimate mail delivery and help protect your domain from spoofing, but a malformed record can affect sending. Start with the values supplied by your email provider, publish them precisely and test after changes. If you manage several sending tools, such as a mailbox provider, website form service and newsletter platform, their requirements may need to be combined.

Treat DNS changes as operational changes

For a personal test site, a quick update may be enough. For a trading website, agency client or organisation relying on email, DNS deserves a simple change process. Make updates outside busy periods where possible, keep a record of what changed, and ensure someone has access to the domain account if a rollback is needed.

Blended Hosts customers can use the hosting control panel to manage DNS records for domains using the appropriate nameservers, while 24/7 technical support is available when a record requirement is unclear. Support can help interpret hosting-related settings, but third-party email or software providers remain the source of truth for their own DNS values.

DNS is not difficult once each record has a clear purpose. Make the smallest change that achieves the result you need, protect the records supporting email, and verify the live result before moving on. That approach keeps your domain dependable while leaving room to grow your website and services with confidence.