Start here
The domain and the DNS #
These two get used interchangeably and they are completely different things. Almost every serious outage we are called into starts with someone treating them as one.
Your domain is the name itself, yourcompany.co.uk. You register it, you pay
to keep it, and you own it. That is all a domain is: a name, reserved in your organisation's favour.
Your DNS is the set of instructions attached to that name. It is what decides that visitors to your website land on your web host, that email to your staff arrives at Microsoft 365, that your VPN finds its way home, and that other mail servers can tell a genuine message from your company apart from a forgery.
Think of the domain as a phone number your company owns, and DNS as the switchboard behind it. Owning the number is one thing. Deciding which calls go to sales, which go to accounts and which go to the warehouse is a completely separate job, and it is the job where things break.
The number can be perfectly fine while every single call goes to the wrong place.
There is a third piece worth naming, because it is where the confusion usually starts. The registrar is the company the domain is registered through, and the nameservers are the setting on the domain that says who is allowed to answer DNS questions about this name. Change the nameservers and you have not moved the domain. You have handed the entire switchboard to somebody else, all at once.
Background
What the records actually do #
You do not need to be able to write these. It is worth knowing they exist, because it explains why “just point it at the new website” is rarely as small a job as it sounds.
| Record | What it controls | What breaks if it is wrong |
|---|---|---|
| A | Points a name at a server's IP address. | Your website, or whatever else that name pointed at. |
| CNAME | Points one name at another name. | Website, tracking subdomains, some Microsoft 365 services. |
| MX | Says which mail server receives your email. | All incoming email. Silently, and often for days. |
| TXT (SPF) | Lists who is allowed to send email as your domain. | Outgoing email starts landing in junk, or is rejected outright. |
| TXT (DKIM) | Signs your outgoing email so it can be proven genuine. | Deliverability drops. Your mail looks more like a forgery. |
| TXT (DMARC) | Tells other mail servers what to do with forgeries. | Anyone can send email pretending to be your company. |
| TXT (verification) | Proves to Microsoft, Google and others that you own the domain. | Microsoft 365 services stop validating. Intune and Entra join fail. |
| SRV | Points services at specific ports, used by Teams and older Office setups. | Teams federation and autodiscover. |
| CAA | Says which authorities may issue certificates for your domain. | Certificate renewals fail, so sites and VPNs start showing warnings. |
| NS | Says who answers DNS questions for the domain at all. | Everything above, simultaneously. |
A typical business domain has somewhere between fifteen and forty of these. On most of them, exactly two have anything to do with the website.
When a website record is wrong, you find out in about ninety seconds, because someone loads the site and it does not work. When an MX or SPF record is wrong, nothing appears to happen. Email quietly stops arriving, or quietly starts going to junk at your customers' end, and you find out days later when somebody asks why you never replied to their invoice.
What we offer
Looking after the domain itself #
We are happy to take on management of the domain, which covers the registration and its renewals. This part is a convenience rather than a requirement, but it removes a genuinely nasty single point of failure.
A domain that expires does not degrade gracefully. It takes down, at the same moment:
- Your website.
- All incoming and outgoing email.
- Microsoft 365 sign in for everyone.
- Your VPN, and anything else that resolves by name.
And recovery is not instant. Depending on how long it has lapsed, getting a domain back can take days and can cost significantly more than the renewal would have.
Why expiry happens more often than you would think
- The renewal notice goes to the wrong person. Domains are frequently registered years ago by a director, a former employee or a web agency, using a personal address that nobody monitors.
- The card on file expires. Auto-renew silently fails, and the warning email goes to that same unmonitored address.
- Nobody knows where it is registered. We are regularly asked to help with a domain and the first job is working out which registrar even holds it.
When we hold the domain, it sits in an account we monitor, renewals are handled, and the contact details are ones that are actually read. It is a small thing that quietly removes a whole category of disaster.
Taking on management is not taking ownership. The domain remains registered to your organisation, and you can ask us to hand it over at any time. There is more on this in Who owns what.
Our position
Why we run the DNS #
This one we feel much more strongly about. For managed customers we retain DNS management, and we would rather have the conversation about why up front than after something has broken.
DNS is not really a website thing. It is the control panel for your email, your identity, your remote access and your certificates, all the services we are accountable for. Keeping it with us means:
- The settings are right. Incorrect DNS causes serious, visible problems: sites unreachable, email undelivered. We check changes before they go live rather than after.
- Critical records are protected. MX records direct your email to the right mail server. If they are removed or altered, mail stops reaching you. That is the single most common piece of collateral damage we see.
- Security keeps pace. SPF, DKIM and DMARC are what stop your domain being used to defraud your own customers, and the guidance around them changes. Keeping on top of that is our job, and it only works if the records stay under our control.
- Everything is considered together. A change for the website can quietly break email, Microsoft 365 enrolment, VPN or certificate renewal. Someone needs to be looking at the whole zone, not just the record they came to change.
- There is one place to look. When something does go wrong, we can see the current records, the history and what changed. That turns a multi-day investigation into a quick fix.
A good web developer is a specialist in building and running websites. DNS is a different specialism that happens to sit next to theirs, and it is dominated by things that have nothing to do with the website: mail routing, SPF alignment, service verification records, certificate authorisation.
We would not expect to be good at their job either. The problem is not competence, it is that a change made with only the website in view can break four services nobody was looking at.
Our position
What actually goes wrong #
We are not being cautious for the sake of it. These are the failures we get called into, and they follow a very consistent pattern.
| What was changed | What broke | How long before anyone noticed |
|---|---|---|
| Nameservers moved to a new host | Every record not manually recreated: email, Microsoft 365, VPN, certificates | Hours for the obvious things, days for email |
| Zone rebuilt from scratch | MX records missing, so all incoming mail bounces or vanishes | Often days, usually a customer complaint |
| SPF record replaced rather than amended | Outgoing mail from Microsoft 365 starts failing checks and landing in junk | A week or two of quietly worse deliverability |
| Verification TXT records tidied away | Microsoft 365 domain validation, Intune enrolment, Entra join | Whenever the next device is set up |
| CAA record added or removed | Certificate renewals fail, so browsers start warning on the site or VPN | Up to 90 days, at the next renewal |
When this happens, everybody loses. We did not make the change, so we cannot simply undo it. The original records are frequently gone, and reconstructing a zone from memory and mail logs is slow work. Meanwhile your email is down, and the person who needs it fixed is you.
Retaining DNS is how we avoid all of us ending up in that conversation.
In practice
When your web developer asks for access #
This comes up on almost every website project, and it is nearly always resolvable in a way that suits everyone. The request is usually broader than the job requires.
When launching a new site, developers commonly ask for the nameservers, for the Cloudflare or registrar
account, or for the domain to be transferred to them. In most cases none of that is necessary. A website
move is normally one or two records: an A record, a CNAME, sometimes a
verification TXT. Nothing else in the zone needs to move or change.
So the answer is almost never no. It is: tell us what the site needs and we will make that change, usually within a few hours during working hours, and everything else stays where it is. Developers are generally happy with this once it is explained, because it is less work for them too. They get their site live without becoming responsible for your email.
Do
- Ask the developer which records need to change, and send them to us.
- Agree a go-live date so we can be ready to make the change.
- Put us in touch with them directly if it is easier.
- Tell us early. A day's notice is plenty; an hour is not.
Do not
- Hand over the nameservers because it was asked for.
- Transfer the domain to a developer's own registrar account.
- Let anyone rebuild the zone from scratch at a new provider.
- Assume a website change cannot affect email. It very often does.
In practice
What to send us instead #
This section is written to be forwarded. Send it to your web developer and we will have what we need to get the site live without touching anything else.
To point a domain at a new website, we need whichever of these applies:
| What we need | Looks like |
|---|---|
| The IP address of the web server | 203.0.113.24, for an A record |
| Or the hostname to point at | sites.yourhost.com, for a CNAME |
| Which names change | The root (yourcompany.co.uk), www, or a subdomain |
| Any verification record | A TXT record the hosting or CDN provider asks for |
| Certificate requirements | Whether the host needs a CAA record, or issues certificates itself |
| The go-live date and time | So we can schedule it and be watching when it happens |
We are not trying to be a gatekeeper, and we are not going to be slow. We hold this zone because it also carries the customer's mail routing, SPF and DKIM alignment, Microsoft 365 service records and certificate authorisation, none of which relate to the website, and all of which fail quietly if the zone is rebuilt elsewhere.
Send us the records and we will apply them, confirm they have taken effect, and keep an eye on the rest of the zone while it happens. If you would rather talk it through directly, we are happy to.
Occasionally there is a real reason to move DNS hosting: a platform that requires its own nameservers, for example. We are not dogmatic about it. Tell us what the requirement is and we will work out how to do it safely, which normally means exporting the full zone, recreating it, verifying mail flow, and then switching. That is a planned piece of work rather than something to do on a Friday afternoon.
Reassurance
Who owns what #
Handing us management is not handing us ownership, and we want to be completely clear about that.
| Thing | Who owns it | Who manages it |
|---|---|---|
| The domain name | You | Us, if you would like |
| The DNS zone and records | You | Us, for managed customers |
| Your website | You | Your web developer |
| Your mailboxes and data | You | Us |
- The domain stays registered to your organisation. Not to us, and not to an individual here.
- You can have it back whenever you want. Ask, and we will provide the authorisation code and transfer it out. We will not make it difficult, and we will not hold it hostage over a billing dispute.
- You can see the records at any time. Ask for a copy of the zone and we will send one. If you want it before making a decision, that is a perfectly reasonable thing to ask for.
- If you leave us, it leaves with you. Offboarding includes handing over the domain and a full export of the DNS records.
Whoever manages it, make sure your organisation knows where the domain is registered, who the account is in the name of, and that the renewal contact is an address someone actually reads. If you are not sure of any of those right now, ask us to check. It takes us a couple of minutes.
Support
Common questions #
Our web developer says they need the nameservers. Are they wrong?
Not wrong, just asking for more than the job usually needs. Moving the nameservers is the quickest route for the website, and if the website were the only thing on the domain it would be fine. It is not, because the same zone carries your mail routing and your Microsoft 365 records.
Ask them which records need to change. In the overwhelming majority of launches the answer is an A record and a CNAME, and we can apply those the same day.
We already use Cloudflare. Does that change anything?
Cloudflare is a DNS host, so it is one of the places a zone can live rather than an alternative to having DNS. We are perfectly happy working with it. What matters is that the records are managed by people who can see the whole picture, not which provider hosts them.
Can we still see and check our DNS records?
Yes, always. Ask and we will send you the current zone. Nothing about this arrangement is intended to be opaque. Quite the opposite: the point is that there is one clear place to look.
How quickly do DNS changes take effect?
The change itself is immediate at our end, but other systems around the world cache the old answer for a while. Most changes are visible within minutes and settled within a few hours. Where we know a change is coming, we can lower the caching time beforehand so the switch is close to instant.
The website is down. Is that DNS?
Usually not. A site that loads but shows an error is a website problem for your developer. A name that does not resolve at all, or resolves to the wrong place, is one for us. If you are unsure, ask us first. Checking takes a moment and we will tell you honestly which it is.
Who pays for the domain renewal?
The domain remains yours, and so does the cost of it. We renew it on your behalf and invoice you for the renewal. Nothing changes about who is paying for what. We are simply making sure it is paid on time, by someone who is watching for it.
What happens if we leave?
We hand it over. You get the domain transferred to wherever you want it, plus a full export of the DNS zone so your next provider can pick it up cleanly. That is part of offboarding, not something you have to negotiate for.
Do we have to let you manage DNS?
For managed customers we retain DNS management, because we are accountable for the services that depend on it and we cannot support them properly otherwise. If you have a specific situation that makes that difficult, talk to us rather than working around it, because there is usually a sensible answer.
Getting help
If you have a website launch coming up, a developer asking for access, or you simply want to know where your domain is registered and what the records currently say, get in touch. Checking is quick, and it is far easier to look before a change than to reconstruct a zone afterwards.