Domains and DNS in Plain English: How Your Address, Host, and Certificate Fit Together
Whether your company website can be reached, whether your email gets delivered, and whether browsers throw up a red warning all come down to the same layer of configuration: your domain and DNS.
Nobody thinks about this layer on a normal day, but when it breaks, an entire website or mailbox simply disappears. What makes it worse is that most business owners have never seen the control panel for their own domain, and are not always sure whose name it is registered in.
Four separate things, often confused for one
A lot of the confusion comes from treating these as a single product. They are four independent services, and you can buy each one from a different provider.
Domain name: the web address itself. You are not buying it outright; you are registering the right to use it with a registrar, renewable annually.
DNS (Domain Name System): the service that translates your address into something machines can route to. Think of it as a phone directory. When someone types your address, DNS answers the question “which machine does this address point to?”
Hosting: the actual machine or cloud service that stores your website files and runs your application. Choosing a host is a separate decision in its own right; see How to Choose Web Hosting.
SSL/TLS certificate: the credential that puts the padlock in front of your address and encrypts data in transit. Most hosting plans now include automatic issuance and renewal, but you still need to confirm who is responsible and whether renewal really is automatic.
An analogy: the domain is the street number, DNS is the address book, hosting is the building itself, and the certificate is the notice at the door confirming you are who you say you are. All four are independent, and each fails in a different way.
Domain ownership: it has to be in the company name
This is the most important section in this article.
A very common situation in practice: the agency building your site offers to “take care of the domain while we are at it,” so the registrant field ends up naming the agency and the management account sits with them. While the relationship is working, you never notice. The moment you want to change vendors, cannot reach them, or find that they have closed down, you discover you cannot retrieve your company’s most central digital asset.
Three things to confirm:
- The registrant is the company — not the vendor, and not the personal details of an employee who has since left.
- The administrative email is controlled by the company — ideally a shared departmental mailbox rather than one person’s account, so it does not go dead when someone resigns.
- You hold the registrar login yourself — even if day-to-day changes are delegated to a vendor, the account should be in your hands.
If you have just discovered the domain sits in a vendor’s name, do not wait until the relationship sours. Most registrars have a process for transferring the registrant, or moving the domain to a different registrar entirely, and doing it while everyone is still on good terms is far less painful. For the wider set of questions to ask when selecting a vendor, How to Choose a Software Development Company has a fuller checklist.
Renewals and expiry: the line that fails most often
A domain is rented, not bought outright. Forgetting to renew has consequences most people underestimate: the website stops resolving one morning, company email may go down with it, and once the grace period lapses, someone else can register the name.
Ways to reduce the risk:
- Turn on auto-renewal, and check that the payment method on file has not expired
- Send renewal notices to a shared company mailbox, not to one individual
- Put a separate reminder in the company calendar rather than relying solely on the registrar’s emails
- Consider renewing important domains several years at a time to reduce the number of chances to forget
Certificates have the same failure mode. When a certificate expires the site does not vanish, but the browser shows a security warning, which from a visitor’s point of view amounts to much the same thing. For the signals worth monitoring after go-live, see The Website Launch Checklist.
What the common record types actually do
A DNS control panel presents a row of abbreviations. You do not need to configure them yourself, but knowing what each one is responsible for makes conversations with your vendor far smoother.
| Record type | What it does, in plain terms | What breaks if it is wrong |
|---|---|---|
| A / AAAA | Points your address at the host’s location | The website is unreachable |
| CNAME | Points one address at another address | Subdomains or external services stop working |
| MX | Specifies which mail service receives your email | Incoming mail is lost |
| TXT | Holds verification strings, including those used for email authentication | Verification fails; outbound mail lands in spam |
| NS | Specifies who manages DNS for this domain | The entire configuration stops applying |
Two practical points. The website and the mail service run on separate lines: A records handle the site, MX records handle mail, so changing web hosts does not have to touch email, but getting it wrong takes both down. And if the TXT records used for email authentication are not set up properly, marketing emails and transactional notifications are frequently blocked outright by the recipient’s provider, which shows up most visibly in e-commerce and membership notifications.
Principles for switching DNS when you change vendors or move
The classic migration disaster is cutting over and only then discovering the new environment was not ready. A handful of principles avoid most of that risk.
Build first, switch second. Stand the site up completely on the new host, test it thoroughly on a temporary address, and only then touch DNS. Do not switch and repair at the same time.
Shorten the TTL before you cut over. TTL is how long servers elsewhere cache your settings. Reducing it beforehand means the change propagates faster; set it back once the move is done.
Accept that the change will not be globally consistent straight away. For a period after the switch, some people will see the new site and some the old one. That is expected, which is why both environments need to keep working during the transition and why you should not rush to shut the old host down.
Verify email settings separately. When changing hosts, check specifically whether the MX and related verification records were overwritten, and send a real test message.
Record the old configuration in full. Export or screenshot every current record before anyone makes a change. It is the cheapest rollback insurance available.
If you are migrating and redesigning or restructuring URLs at the same time, the risk rises sharply; the migration steps are covered separately in the Website Redesign SEO Checklist.
Subdomains and multiple domains: problems that appear as you grow
Once a company reaches a certain size it rarely has just one address, and two kinds of planning question tend to surface.
How to allocate subdomains. The blog, live chat, campaign pages, and internal admin tools all need a home, and it is far better to have a rule from the start than to improvise a new one every time a service is launched. Worth noting: putting content on a subdomain versus in a subdirectory of the main domain has different implications for search performance and for how the thing gets maintained later, so it is worth having development and marketing agree before the decision is made.
Whether to register defensively. Some companies also register common misspellings, or the same name with other endings, to stop someone else using them for a lookalike site or to intercept mail. It is a trade-off between cost and risk, and the better known your brand is, the more it is worth considering. One caution, though: the more domains you register, the more renewals and certificates there are to manage. Keeping them with a single registrar and aligning the expiry dates helps.
One detail that regularly gets missed: confirm that the www and non-www versions of your address, and the http and https versions, all end up at the same canonical address. Without that, the same page is reachable at several addresses, which is unhelpful both for how search engines interpret your site and for your analytics.
If the company runs several brands or several websites, keep a single reference table recording which address points at which host, who maintains it, and when it expires. Once you have a number of addresses, the most common problem is not a misconfiguration; it is that nobody remembers an old campaign site is still live and its certificate lapsed long ago.
The record you should keep yourself
You do not need to be technical, but this information should be held by the company, and at least two people should know where it is:
- Which registrar holds the domain, who has the account, and when it expires
- The domain registrant details (confirming the company is named)
- Who manages DNS (the registrar, the host, or a cloud service)
- The hosting or cloud provider, the plan, and how to log in
- Who issues the certificate, and whether renewal is automatic
- The email provider and the related records
- Who to contact when something breaks, and the agreed response time
This list normally belongs in the deliverables of a maintenance contract; for the detail, see What Website Maintenance Actually Covers. NETVANA projects include deployment and DNS configuration as part of the testing and launch phase, and the process is set out in the software development process.
Domains and DNS are one of the few areas where nothing is visible day to day and everything is critical the moment it fails. Spending an afternoon confirming ownership, renewals, and access is probably the highest-return piece of administrative work available to you.
If you are not certain whose name your company domain is currently registered in, or you are changing vendors and need to migrate safely, talk to NETVANA about your situation — we start by taking stock of what you have before discussing next steps. For what each service includes and delivers, see the software services overview.
Further reading: for choosing a hosting plan, see How to Choose Web Hosting; for the order of operations on launch day, see The Website Launch Checklist; for baseline protection and incident handling, see Website Security Basics for Businesses; and for what to ask when evaluating a vendor, see How to Choose a Software Development Company. Once domains and hosting make sense, weigh whether a small shop needs a site at all, see Does a Small Business Need a Website.
