Domains, DNS, SSL and Email: The Launch-Day Setup Nobody Teaches

Most DNS confusion comes from a single conflation. When you buy a domain at Namecheap, Porkbun or Cloudflare, three separate roles get bundled into one checkout, and because the same dashboard handles all of them, they feel like one thing. They are not, and the moment you point a domain at a host, the seams show.

The registrar rents you the name. Its actual job is narrow: it tells the global registry that you control the domain until your renewal date, and it records which nameservers are allowed to answer questions about it. That is the whole job. A registrar does not serve your website, and it does not have to host your DNS records either — it usually does both by default, which is exactly why people conflate them.

The nameservers are the authoritative source of truth for your domain. When anything on the internet — a browser, a mail server, a certificate authority — wants to know where your domain points, the question eventually lands at your nameservers, and whatever they say goes.

The records are the answers themselves: the website lives at this IP, email for this domain goes to that server, here is a verification string proving ownership. Records live inside the nameservers the way rows live inside a database.

Resolution is a chain of questions. You type a domain, your operating system asks a resolver (your ISP's, or a public one like 1.1.1.1), and the resolver walks down the hierarchy: the root servers say which servers handle .dev, the .dev servers say which nameservers speak for your domain, and your nameservers return the record. Every answer gets cached along the way, which is the detail that will matter enormously in a few sections.

The practical takeaway: where you bought the domain, where your DNS lives, and where your site runs are three independent choices. You can buy at Namecheap, host DNS at Cloudflare, and run the app on Vercel — or collapse all three into one provider. Neither is wrong. But until you see them as three separate decisions, every hosting guide reads like it is skipping steps.

The DNS specification defines dozens of record types. Launching a SaaS, you will touch five:

• A — maps a name to an IPv4 address; the original record, and still what most hosting docs mean by point your domain at us.
• AAAA — the same thing for IPv6; mostly handled for you, but a stale AAAA left over from an old host will quietly serve the wrong server to IPv6 users while the A record looks perfect.
• CNAME — an alias that says this name has no answers of its own, go ask that other name instead; hosts love it because they can change the underlying IPs without you touching anything.
• TXT — arbitrary text attached to a name; almost everything that is not routing lives here, including domain-ownership verification and all three email authentication records.
• MX — where email sent to your domain should be delivered; it is about receiving mail, which is a different problem from sending it, and mixing the two up is a classic launch-day mistake.

One limitation explains roughly half of all hosting documentation: you cannot put a CNAME at the apex of your domain. A CNAME means this name has no other records, but the apex must carry NS and SOA records for the zone to function at all, so the spec forbids it. That is why every guide says add an A record for example.com and a CNAME for www.example.com — not because the two are different in spirit, but because the rules of the protocol force the split. DNS providers paper over this with proprietary workarounds (ALIAS records, CNAME flattening) that behave like a CNAME but answer like an A record. If your provider offers one, use it; if not, the plain A record your host documents is fine.

There are exactly two ways to connect a domain to a host, and the choice is about who manages your records from now on.

Road one: change the nameservers at your registrar to the ones your host gives you. The host now owns your entire DNS zone. Every record — site, email verification, the TXT string Google Search Console asks for next month — gets managed in the host's dashboard or CLI, and the registrar fades into a renewal invoice. The trade-off is concentration: your DNS now lives and dies with that host, moving away later means rebuilding the whole zone record by record, and any DNS conveniences your registrar offered (email forwarding is the common one) stop working the moment you switch.

Road two: keep your registrar's nameservers and add individual records pointing at the host — an A record for the apex, a CNAME for www. Your DNS stays independent of your hosting, so switching hosts later is a two-record edit instead of a migration. The trade-off is that you are now the DNS administrator: every future record goes through the registrar's panel, and registrar DNS panels range from decent to actively hostile.

This site took road one and moved its nameservers to Vercel, for a reason that matters when you operate alone: every future record is one CLI command instead of a login, a dashboard hunt, and a form. The deploy side of that decision is covered in the Vercel deployment guide; the DNS side looks like this:

# see every record in the zone
vercel dns ls codefromscratch.dev

# add the DKIM record your email provider hands you
vercel dns add codefromscratch.dev resend._domainkey TXT "p=MIGfMA0GCSq..."

# add an MX record for the sending subdomain
vercel dns add codefromscratch.dev send MX "feedback-smtp.eu-west-1.amazonses.com" 10

If you expect to change hosts within a year, or you already keep DNS at a dedicated provider like Cloudflare for other domains, road two is the better default. If you are a solo operator shipping on one platform for the foreseeable future, road one removes a whole category of friction.

Pick one front door: www or apex

Your site will be reachable at both example.com and www.example.com, and search engines treat those as two different sites with identical content — which dilutes ranking signal across both. Pick one as canonical, redirect the other with a permanent redirect, and never link to the loser again. Which one you pick matters less than picking: apex looks cleaner in print, www gives you slightly more DNS flexibility because it can be a true CNAME. Most platforms, Vercel included, set up the redirect with one click when you add both domains. Do it on day one — retrofitting canonical URLs after Google has indexed both is tedious.

Every DNS answer carries a TTL — time to live — which tells resolvers how long they may cache it. When you change a record, your nameservers update instantly. The internet does not, because thousands of resolvers are still serving the old cached answer and will keep serving it until their copy expires. That is all propagation is. Nothing is propagating anywhere; caches are expiring at different times.

This is why the site works on your phone but not your laptop. Your phone is on mobile data, asking your carrier's resolver, which happens not to have the old record cached. Your laptop is asking your ISP's resolver — or its own OS cache — which does. Both are behaving correctly. Neither tells you anything about whether your change worked.

So stop refreshing the browser and ask the system directly:

# what the world currently sees (cached)
dig +short A codefromscratch.dev

# what your nameservers actually say (no cache)
dig @ns1.vercel-dns.com +short A codefromscratch.dev

# confirm the nameserver delegation itself
dig +short NS codefromscratch.dev

# Windows without dig installed
nslookup codefromscratch.dev

If the authoritative query returns the new value, your change is correct and live — everything after that is waiting for caches, not a problem to solve. If the authoritative answer is wrong, no amount of waiting will fix it. This one distinction turns an anxious hour into a thirty-second check.

In 2026 you should never buy an SSL certificate and never run a certbot command for a normal web app. Every serious platform — Vercel, Netlify, Cloudflare, Fly, Railway — provisions certificates automatically through Let's Encrypt or an equivalent ACME authority the moment your domain points at them, and renews them forever. If you are doing manual certificate work for a standard deployment, something upstream is misconfigured.

When automatic issuance fails, it is almost always one of two things. First, a CAA record: a record type that whitelists which certificate authorities may issue for your domain. Some registrars set one by default, and if it does not include the authority your host uses, issuance silently fails. Check with dig +short CAA yourdomain.com — if it returns anything, make sure the host's CA is on the list, or delete the record if you never knowingly created it. Second, stale DNS: the certificate authority validates that the domain actually points at your host before issuing, and if an old A or AAAA record still points at your previous server — or a cached answer does — validation fails until DNS is genuinely clean.

Your app will send email from day one — sign-up confirmations, password resets, receipts. Whether those emails reach the inbox or the spam folder is decided by three TXT records, and since Gmail and Yahoo began enforcing authentication for senders in 2024, this is no longer optional hygiene. Unauthenticated mail from a fresh domain goes to spam. Not sometimes — reliably.

The cleanest way to understand the trio is as a bouncer checking ID at the inbox door. SPF is the guest list: a TXT record on your domain naming the servers allowed to send mail on its behalf. The receiving server checks whether the connection actually came from one of them. DKIM is the tamper-proof seal: your email provider cryptographically signs every outgoing message, publishes the public key as a TXT record under your domain, and the receiver verifies that the message really came from you and was not altered in transit. DMARC is the bouncer's instructions: a policy record telling receivers what to do when a message claiming to be from your domain fails the other two checks — let it through, quarantine it, or reject it — and where to send reports about who is sending mail in your name.

The practice is far less intimidating than the theory. You will not write any of these records yourself. Your email provider — Resend, Postmark, SES, whichever — generates the exact values when you add your domain, you paste them into your DNS, and you click verify. With nameservers at Vercel, the whole ceremony is three CLI commands and a five-minute wait. What the records look like once they exist:

# SPF — who may send for this domain
dig +short TXT send.codefromscratch.dev
# "v=spf1 include:amazonses.com ~all"

# DKIM — the public key receivers verify signatures against
dig +short TXT resend._domainkey.codefromscratch.dev
# "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ..."

# DMARC — the policy tying it together
dig +short TXT _dmarc.codefromscratch.dev
# "v=DMARC1; p=quarantine; rua=mailto:dmarc@codefromscratch.dev"

One honest caveat: perfect authentication does not guarantee the inbox. Content, sending volume and domain reputation still matter, and a brand-new domain blasting a thousand emails on day one will get filtered regardless. But missing authentication guarantees spam. Set the records up before you send your first real email, not after a user reports that the confirmation never arrived.

Everything above compresses into a list you can run in under an hour — ideally the day before launch, so TTLs and certificate issuance have time to settle while nothing is at stake:

• Domain points at the host — either nameservers switched or A plus CNAME records added — and both apex and www resolve.
• One canonical chosen (www or apex); the other returns a permanent redirect.
• HTTPS certificate issued; if it stalls, check for a CAA record and for stale A or AAAA records before anything else.
• Old records from previous hosts or registrar parking pages deleted, AAAA included.
• Email provider domain verified: SPF, DKIM and DMARC records added and showing verified.
• One real transactional email sent to a Gmail address you control; confirm it lands in the inbox, not spam.
• TTLs raised back to 3600 after the migration settles.
• Authoritative answers confirmed with dig against your nameservers, not by refreshing the browser.

Two follow-ups belong in the same sitting. Point an uptime check at the new domain immediately — not the old preview URL — so you find out about expiry and misconfiguration before your users do; the observability guide covers setting that up in an evening. And remember that the domain is one slice of going live: the production launch guide walks the full path from working code to a site you can stand behind, with this checklist as one stop on it.

DNS will never be the part of your stack you enjoy. But it rewards exactly one investment: understanding the system once, instead of re-deriving it under pressure every launch. Buy the domain, pick your road, set the email trio, run the checklist — and then go back to building the thing the domain points at.