Every lesson in this domain covered one mechanism in isolation. This closing lesson is a realistic incident report, the way this curriculum's own other domains have used a real postmortem as a capstone — applying this domain's entire vocabulary to diagnose one genuinely common, avoidable mistake.
3 min read
"We moved our marketing site to Vercel last week. Since then, contact-form confirmation emails aren't arriving, and a few customers say emails from us are landing in spam. Nothing about our email setup changed — we didn't touch it."
Following Vercel's own custom-domain instructions (that domain's own lesson 7) means adding the A record Vercel specifies for the apex, and a CNAME for www — but depending on how this was done (through a DNS provider's UI that replaced the entire record set for a name, rather than adding to it), this step can silently delete an existing MX record that was sitting at the exact same apex name, if the tool used treats "set the A record" as "replace everything at this name" rather than "add this one record alongside what's already there."
dig example.com MX +short returns nothing — this is the actual finding. The record that tells the internet where to deliver example.com's email is simply gone.dig example.com TXT +short shows no SPF record either — it was removed in the same action.No MX record at all means mail sent to example.com addresses has nowhere to be delivered — this explains the missing contact-form confirmations directly (assuming the form sends a reply to an @example.com address that no longer resolves anywhere). The SPF record's removal explains the separate spam-folder symptom: lesson 7's own mechanism — any mail genuinely sent from example.com (via whatever transactional email service the form actually uses to send) now fails SPF entirely, since there's no record at all authorizing any sender, and receiving servers treat an apex domain with zero SPF record as a real, if milder, red flag.
Re-adding the original MX and SPF TXT records (exactly as they were before, assuming they were captured or can be recovered from the email provider's own setup documentation, lesson 8's own territory) alongside Vercel's A/CNAME records — not instead of them — resolves both symptoms completely, because nothing about Vercel's own configuration was ever actually the problem; the web hosting and email hosting pieces (lesson 8's own point) were always independent, and the only real mistake was a DNS-editing tool silently clobbering one while configuring the other.
Every mechanism covered across these twelve lessons — nameserver delegation, the apex workaround, verification, wildcard certs, SPF/DKIM/DMARC, the troubleshooting order — converges on one underlying discipline: a domain's DNS configuration is a shared resource multiple, genuinely independent concerns (the website, email, subdomains on other platforms) all depend on simultaneously. Changing one concern's records without checking what else currently lives at that exact name is the single most common, avoidable class of real incident this domain exists to prevent — not through any one clever fix, but through the habit of checking the full current record set before changing any part of it.
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. What actually caused the email outage in the capstone's postmortem scenario?
2. Why did the incident produce two distinct symptoms — missing confirmation emails AND spam-folder placement?
3. What is the actual, general discipline this capstone argues the whole domain has been building toward?
Domain Names, DNS & Subdomains