Technology · · 6 min read
What a Custom Domain Actually Involves
The custom domain takes about twenty minutes. Registrars, DNS records, HTTPS, and email at your own address, demystified.
Photograph © Ken Reid
What a Custom Domain Actually Involves
I first made my website when I did my undergraduate degree, in 2012-2013. I hosted it via my university, as they had a means to drop an html file into your main directory and it would become your student homepage. It was a very simple affair, nothing like it is today. The thing I hated most about it was having to give my university's URL to let people see my page. I wanted it to represent me professionally, act as a CV / resume of sorts for future employers - and I knew upon leaving university I would lose the benefits of their hosting, so one of the things I had to look into was custom domains.
It has its own vocabulary (registrars, DNS, A records, MX records), the settings pages kind of looks like a programmer's encyclopedia, and one wrong entry feels like it might break the internet for everyone else too. Nothing you do here is hard to undo, and you do most of it once then forget how it's done (until you write a blog post on it, I guess).
Quick jargon guide
- Registrar: the company you rent your domain name from, annually. Renting is all anyone does. Domains are never owned outright.
- DNS: the internet's phonebook. When someone types your domain, DNS answers "that name lives at this address". Your registrar gives you a settings page to write those entries.
- A record: a DNS entry mapping your bare domain to a server's numeric IP address.
- CNAME record: a DNS entry mapping a name to another name, like pointing
www.kenreid.co.ukat GitHub's servers by name rather than number. - MX record: the DNS entry that routes your domain's email, entirely separately from the website.
- Apex / bare domain: the domain with nothing in front:
kenreid.co.ukas opposed towww.kenreid.co.uk. - HTTPS / TLS certificate: the padlock. Proof to browsers that the site at your name is really yours, issued free and automatically these days.
Step one: rent the name
Pick a registrar (mine is Bluehost through historical inertia, and Cloudflare, Porkbun and Namecheap are the usual modern recommendations), search for the name, pay. A .co.uk or .com runs roughly £10–15 a year. If you host via GitHub, this is your only expense - pretty cheap, right?
Register it in your own account, not a friend's, not a freelancer's, and definitely not your employer's. Turn auto-renew on and keep the payment card current, because expired domains get bought by squatters within hours (if your website is big enough to warrant that). And treat the registrar account like a bank login (real password, two-factor), because whoever controls it controls everything downstream, including your email!
On the name itself: your own name is a fine default for a personal site (this one is proof), shorter beats cleverer, and any mainstream ending is fine. The exotic endings (.io, .dev, .pizza) work identically but often cost more at renewal, and might make it difficult to convince people of your email address (I've had people ask me if "I'm sure" that my email address really does end with @kenreid.co.uk - yes, it does!). Introductory first-year discounts are the industry's favourite trick.
Step two: point it at your host
Your registrar's DNS page is where the twenty minutes happens, and you add a handful of records that say where web traffic should go. For this site, hosted on GitHub Pages, that means four A records pointing the apex at GitHub's published IP addresses, and one CNAME record pointing www at my GitHub Pages hostname. Every host publishes the records it wants and the shape is always the same few lines. Mine, conceptually:
| Type | Name | Points to |
|---|---|---|
| A | @ (the bare domain) | 185.199.108.153 |
| A | @ | 185.199.109.153 |
| A | @ | 185.199.110.153 |
| A | @ | 185.199.111.153 |
| CNAME | www | drkenreid.github.io |
Then you tell the host which domain to answer for. On GitHub Pages that's a one-line file named CNAME in the repository (mine says www.kenreid.co.uk), or the same setting in the repository's Pages settings, plus a checkbox to enforce HTTPS. The certificate is issued automatically within the hour, free, and renews itself forever. In 2012 the padlock cost real money and real ceremony, and now it is free generally.
DNS changes take anywhere from minutes to a day to spread across the internet - be patient.
Step three (optional, recommended): email at your name
The domain routes email separately from the website, via MX records, so ken@kenreid.co.uk works without GitHub ever seeing an email. I pay Fastmail a few pounds a month to host the mailbox. Adding their MX records at the registrar took five minutes with their guide open in another tab.
An email address you own outlives every provider, every job, and every free service's pivot to enshittification. Mine will follow me to any mail host forever, because the name it lives at is rented in my name.
Whether your site's official address is the bare domain or the www one. Both work (one redirects to the other), but pick one and use it everywhere, because search engines treat them as different sites. This site standardised on www.kenreid.co.uk and every page declares it. The metadata post covers the tags that keep that consistent.
What ongoing maintenance looks like
Approximately none. The domain renews itself annually (you get an email and a small charge), the certificate renews itself without telling you, and the DNS records sit untouched for years. The one day they change is the day you switch host or email provider. You edit a few lines, and everything else follows the name across.
Register it in your own account, turn auto-renew on, and then ignore it for a year. Well worth the minor cost, in my opinion.
Steps, concisely
- Buy: register your domain and turn on auto-renew.
- Point: add A and CNAME records at your registrar to send traffic to your host (GitHub's DNS guide).
- Connect: tell your host your domain name and turn on HTTPS (hosting on GitHub Pages).
- Email (optional): add MX records to send mail to your provider (Fastmail's custom domain guide).
- Forget: keep your payment details current, let auto-renew run, and use your chosen address everywhere (the metadata post).
Common questions
Can I break anything permanently in the DNS settings?
No. Wrong records make your site or email unreachable while the records are wrong. Fix the record and reality resumes, minutes to hours later. The two dangerous acts both live at the account level: letting the domain expire, and losing the registrar login. Guard those and everything else is reversible tinkering.
Should I buy the .com and .net and every other version too?
For a personal site, buy the one you'll use. Defensive registration of every ending is a business concern (and a registrar upsell that has been told to sound like security advice). Nobody is squatting the .net of a personal blog, and if they someday are, congratulations on the fame.
What about domain privacy / WHOIS protection?
Registration details go into a public directory unless the registrar masks them, and most now do it free by default. Check the box exists before paying. A registrar charging extra for privacy in 2026 is telling you something about their other prices.
My host offers a free subdomain. Why pay for a domain at all?
yourname.github.io works and costs nothing, and for a project site it's fine. The problem is that the free name belongs to the host. Switch hosts and every link to your site breaks, forever. For £12 a year, moving host becomes a settings change instead of a change of identity. I have never regretted the twelve quid.
