A new website can be fully built, paid for and ready to launch, yet still show an error page if its DNS is not pointing to the right place. DNS is the setting that tells browsers and email services where to find your domain. Learning how to configure DNS records gives you control over that connection without needing to manage a server.
For most small businesses, DNS changes are needed when launching a website, moving hosting, connecting Microsoft 365, verifying a third-party service or setting up a subdomain. The settings themselves are usually straightforward. The difficulty is knowing which records to change, where they are managed and what must be left alone.
What DNS records do
DNS stands for Domain Name System. Think of it as the address book for your domain name. When someone enters your domain into a browser, DNS directs them to the server hosting your website. When they send an email to your business address, DNS helps route that message to the correct mail service.
Each instruction is stored as a DNS record. Your domain may have several records working together, and they can be managed through your domain registrar, hosting control panel or a specialist DNS provider. Only one provider should be authoritative for the DNS zone at any given time.
Before making any changes, establish where your nameservers point. Nameservers determine which company controls the live DNS records. It is common for a domain to be registered with one provider while its DNS is managed by another. Editing records in the wrong control panel will not affect the live website or email.
The DNS records most website owners need
You do not need to memorise every record type. In day-to-day website and email setup, these are the ones you are most likely to encounter:
| Record type | What it does | Typical use | |—|—|—| | A | Points a domain or subdomain to an IPv4 server address | Connecting a website to its hosting server | | AAAA | Points a domain or subdomain to an IPv6 address | Used where hosting supports IPv6 | | CNAME | Points one hostname to another hostname | Connecting www or a service verification record | | MX | Directs incoming email to a mail server | Hosting business email or Microsoft 365 email | | TXT | Holds text-based verification and email policy information | SPF, DKIM, DMARC and service verification |
An A record is often the main website record. For example, the record for `@` may point your main domain, such as `yourbusiness.co.uk`, to the IP address supplied by your web host. The `www` version is commonly a CNAME record pointing to the main domain, although the correct setup can vary by provider.
MX and TXT records deserve particular care. They are essential for reliable business email, and changing or deleting them accidentally can stop messages arriving or cause them to fail security checks. If your website and email are supplied by different companies, your DNS zone will need records for both services.
How to configure DNS records safely
Start by gathering the exact values from the service you are connecting. A hosting provider may provide an IP address for an A record, while Microsoft 365 or another email provider will provide a set of MX, CNAME and TXT values. Copy these exactly, including dots, hyphens and any priority numbers.
Next, sign in to the account that manages your live nameservers. Look for an area labelled DNS management, DNS zone, zone editor or advanced DNS. Take a screenshot or make a written copy of the existing records before altering anything. This gives you a reliable way back if a setting is entered incorrectly.
When adding a record, pay close attention to the host or name field. Many control panels use `@` to represent the main domain. A host of `www` means `www.yourdomain.co.uk`, while a host of `shop` creates `shop.yourdomain.co.uk`. Some systems automatically add the domain name to the entry, so entering the full domain where only `www` is expected can create an incorrect address.
Enter the value supplied by your service provider, select the right record type and save the change. If you are replacing an old website address, update the relevant A record rather than creating a second conflicting record. Two A records can be valid when deliberately used for load balancing, but they are not normally appropriate for a standard small-business website.
Finally, check whether existing records are still required. For example, changing your website A record should not require you to remove MX records for email. A hosting move and an email move are separate jobs unless you are intentionally moving both services.
Choose a sensible TTL
TTL means Time To Live. It tells DNS resolvers how long they may keep a record in their cache before checking for an updated version. It is usually shown in seconds.
A lower TTL, such as 300 seconds, can be useful shortly before a planned website or email migration because changes may be picked up sooner. Once everything is working, a more typical value such as 3600 seconds can reduce unnecessary lookups. Lower is not always better, but using a temporary lower TTL gives you more flexibility when a change is time-sensitive.
It is best to reduce the TTL several hours before a planned migration, not at the same moment you make the switch. Existing cached responses may still follow the old setting until their original expiry time has passed.
Common DNS mistakes to avoid
The most disruptive mistake is changing nameservers when only a single record needs updating. Nameserver changes can replace the entire live DNS zone with another provider’s version. If that new zone does not include your email, verification and subdomain records, services may stop working.
Another common problem is duplicate or conflicting records. A domain should not normally have an A record and a CNAME record for the same hostname. Similarly, old MX records can conflict with a new mail provider’s settings. Follow the instructions supplied for your particular service and remove only the records that the provider says should be replaced.
Email authentication settings can be especially unforgiving. SPF records should generally be combined into one TXT record rather than added as several separate SPF entries. DKIM records often contain long values, so copy them carefully. DMARC should be introduced gradually if you are unsure how all your legitimate systems send email, as a strict policy may reject valid messages that are not correctly authorised.
A final source of confusion is propagation. DNS changes are often visible within minutes, but there is no guaranteed instant change everywhere. Different networks and devices may retain cached information until the TTL expires. Allow up to 24 to 48 hours for global propagation, particularly after a nameserver change, before assuming a record has failed.
Checking that your DNS changes work
After saving a website record, test both the main domain and the `www` version in a private browser window. Check that the correct website loads over HTTPS and that there are no certificate warnings. If you have changed an email record, send a test message to and from an external address, not only between addresses on the same system.
You can also use DNS lookup tools or command-line checks to confirm which record is publicly visible. Compare the result with the value your provider gave you. If the public result is correct but your own computer still shows the old website, clear your browser cache or wait for local DNS caching to expire.
If a change is urgent and something is not behaving as expected, avoid making several speculative edits. Recheck the record type, host name, value and nameservers first. One carefully verified correction is safer than a series of changes that make it harder to identify the cause.
When to ask for support
DNS is manageable for many routine tasks, but support is worthwhile when a domain has business-critical email, a live online shop or several connected services. It is also sensible to ask for help before moving nameservers, changing MX records or editing email authentication settings.
A good hosting provider can confirm which DNS entries are needed for your website and help ensure that a hosting move does not interrupt mail. Pac Web Hosting customers can also use technical support when they need practical guidance rather than having to work through unfamiliar settings alone.
Treat DNS as part of your business continuity, not just a one-off launch task. Keep a record of where your domain, hosting, email and DNS are managed, and future changes will be far less stressful.
