Checkpoint: how email actually works

Four lessons ago you didn't know what an MTA was. Now you can follow a message from the send button through the MX lookup, the SMTP conversation, acceptance, and the silent second gate, and you know which of an email's two from addresses the servers actually read. This checkpoint is where you prove it.

Nothing new gets taught below, deliberately. Part 2 is built directly on this part's model: authentication is the envelope-versus-letter split with cryptography attached, and every record you'll learn to write lives in the DNS you just learned to read. A term that makes you hesitate here becomes confusion at triple volume once SPF syntax arrives, so if one does, follow it back to its lesson before going on.

The checkpoint has three parts. A terminology drill covering everything so far; checkpoint drills are cumulative, and they stay that way for the rest of the course, so these terms will keep resurfacing until they're reflexes. Then a single scenario played in three decisions, with the situation evolving after each answer. It's built backwards from a failure our health check catches on real domains, so treat it as a preview of the job. And then a lab, because at some point you have to stop reading about DNS and go look at some.

Term drill

1/16

Received header

The header where the receiver records the envelope senderA routing stamp each handling server adds; read bottom-upNames the servers that accept a domain's incoming mailThe address failure notices go to; invisible to readers

Vocabulary is the cheap half. The model is what Part 1 was really for: two gates instead of one, and two froms instead of one, with the whole configuration sitting in public DNS where the wrong person can edit it. The scenario below runs that model against a problem the way problems actually arrive, which is unlabeled and mid-panic. Every option's feedback tells you what that choice costs, so read the feedback even when you're right.

The newsletter that half vanished

You run a 4,000-subscriber newsletter for your company through an ESP. This week's issue shows 97% delivered in the dashboard. But replies are down to almost nothing, and two long-time readers separately mention they never received it.

What do you make of the dashboard's 97%?

It means 97% of subscribers got the issue in their inbox, so the quiet week must be a content problemIt means 97% were accepted by receiving servers; where each one landed is a separate, unreported decision, so ask those two readers to check their spam foldersRe-send the issue to everyone who didn't open itRewrite next week's subject line to sound less promotional

The lab: go read some records

Reading about DNS and pulling records yourself are different skills, and only the second one is worth money. This lab takes about fifteen minutes, changes nothing, and needs no signup: every lookup is read-only, public, and free. Use your own domain if you have one. If you don't, pick any well-known domain (your favorite newspaper, a brand you buy from) and read theirs instead; DNS answers anyone who asks, and owning a domain of your own becomes worth the few euros a year later in the course.

For tooling, dig is built into macOS and Linux terminals. On Windows, nslookup does the same job (nslookup -type=MX yourdomain.com). If terminals aren't your thing, search for an online dig tool: a page where you type a domain, pick a record type, and see the raw answer. Same data either way.

Pull three record types, in this order.

Start with the nameservers: dig NS yourdomain.com +short (the +short trims the output to just the answers). The hostnames that come back tell you which company holds your zone, which is where any future record edit must happen. If that company isn't the one you bought the domain from, you've just learned the single most useful fact in this lab, and you learned it calmly instead of mid-outage.

Then the mail servers: dig MX yourdomain.com +short. Each line is a priority number and a hostname, lowest number tried first, and the hostnames usually give away who runs the domain's mailboxes. An empty answer here means no MX is published: the domain isn't set up to receive mail, and for a business domain that's a real finding, since domains that can't receive mail look disposable to the filters judging their outgoing mail.

Last, the junk drawer: dig TXT yourdomain.com +short. Expect clutter; verification strings from every service the domain ever touched pile up here. What you're hunting for is a line starting with v=spf1. That's an SPF record, the subject that opens Part 2. If it's there and you can't read it yet, perfect: that's exactly the gap the next part closes. If it's missing on a domain that sends mail, you've found something Part 2 will teach you to fix.

An empty answer, on any of these, isn't an error. It means nothing is published at that name and type (or you typed the domain wrong, which is worth ruling out first). Well-known domains will have all of this present, which is what makes them useful practice targets.

Keep the output. Paste it into a note with today's date: this is the start of the record inventory the DNS lesson argued for, and the baseline you'll compare against later in the course. If you ran the lab on your own sending domain and want the graded version of what you just read, the free health check reads the same public records and tells you what each finding means.

One step remains in this part: the Part 1 exam, the committed run that says whether to move on.