CUSTOM DOMAIN
Free course · 8 modules · ~90 minutes
Domain Fundamentals
The complete, no-fluff course on how domains actually work — DNS, TLS, verification, multi-tenant routing, and how to give your customers a branded domain without the operational pain. Built for founders, engineers, and agencies who need to actually understand this, not just Google it under deadline.
What's in the course
Eight short modules, in order. Each one stands alone if you just need one answer, but they build on each other if you read straight through.
What a domain actually is
A domain name is a human-readable label (like example.com) that maps to the machine
addresses and configuration that make a site or service reachable. It's rented, not owned — you pay
a registrar annually to keep your claim on it in a global registry.
Key building blocks:
- Registrar — where you buy/renew the domain (GoDaddy, Namecheap, Cloudflare, etc.)
- Registry — the authority for a given TLD (e.g. Verisign runs .com)
- TLD — the suffix: .com, .ai, .io, .app
- DNS zone — the set of records that tell the internet where your domain's traffic should go
- Nameservers — the servers that answer DNS queries for your zone
Everything else in this course — DNS records, TLS, verification, multi-tenant routing — sits on top of this basic structure.
DNS records, decoded
DNS records are the instructions inside a domain's zone. The ones you'll deal with constantly when connecting customer domains:
- A / AAAA — point a name straight at an IPv4/IPv6 address
- CNAME — point a name at another name instead of an IP (can't be used on a bare/apex domain in the classic spec)
- TXT — arbitrary text, used constantly for domain verification and SPF/DKIM
- MX — where email for the domain should be delivered
Propagation delay (why a DNS change doesn't show up instantly everywhere) comes down to TTL — caches around the internet hold the old answer until it expires.
Apex domains vs. subdomains vs. CNAME
An apex/root domain is the bare domain — example.com — with no
subdomain in front. A subdomain like app.example.com can use a CNAME
freely. The apex traditionally can't, because CNAME records aren't allowed to coexist with the other
record types (like MX) the apex often needs — this is why "CNAME flattening" / ALIAS-style records exist
at many DNS providers, letting the apex behave like a CNAME under the hood.
For most customer-facing setups, steering customers toward a subdomain (or using flattening automatically) avoids this whole class of support ticket.
Bring-your-own-domain (BYOD) for SaaS
BYOD is what lets a customer of your product use their own domain instead of a subdomain of yours
— e.g. shop.theircompany.com instead of theircompany.yourapp.com. It's one
of the highest-leverage "feels enterprise" features a SaaS can ship, and one of the most commonly
underestimated in engineering cost: DNS instructions, verification, per-domain TLS, and routing all
have to work for domains you don't control.
TLS/SSL without the headache
Every customer domain needs a valid TLS certificate or browsers will flag it as insecure. Doing this per-domain, for potentially thousands of customer domains, is what "multi-tenant TLS" means — and doing it without a human clicking "issue certificate" each time is "on-demand TLS," usually built on the ACME protocol (the same one behind Let's Encrypt).
Verification & domain ownership
Before a platform will serve traffic for a domain (or issue it a certificate), it needs proof the requester actually controls it. The standard approach is asking the customer to add a specific DNS record (usually TXT, sometimes CNAME) that only someone with access to the zone could add — the Domain Connect protocol is one attempt to make this a one-click flow instead of a copy-paste-and-wait one.
Multi-tenant domain routing at scale
Once you have hundreds or thousands of customer domains pointed at your platform, the hard part shifts from "how do I connect one domain" to "how do I route and terminate TLS for all of them without re-deploying every time someone adds a new one." This is the layer that services like Cloudflare for SaaS (or a dedicated custom-domains platform) exist to solve, so you don't have to build and operate it yourself.
Rolling it out: the agency & white-label playbook
If you manage domains on behalf of many clients — as an agency, site builder, or platform — the goal is a repeatable process: a simple connect flow per client, automated TLS, and one dashboard to see every client's domain status at a glance, instead of a spreadsheet and a Slack channel full of DNS screenshots.
Keep going
The full glossary and step-by-step guides if you want to go deeper on any one topic.
Ready to see it running on your product?
Everything in this course — verification, TLS, routing — is what Custom Domain runs for you, out of the box.
Book a demo