Checkpoint: authentication

Five lessons ago, SPF was three unexplained letters. Now you can read a record token by token and explain what a selector is doing inside a DKIM signature. More to the point, you can say why a message that passes both SPF and DKIM can still fail DMARC, which already puts you ahead of most people sending email for a living.

That last skill is the one this checkpoint leans on hardest. Alignment confusion fills support queues, and it is the root of the failure pattern the alignment lesson warned about: authentication that proves the tool sent the mail while proving nothing about the person paying for it.

A checkpoint is proof, not new material. The drill below runs eighteen terms, most from this module and a few carried forward from Part 1, because vocabulary that never gets revisited quietly evaporates. Then comes one case, played as three chained decisions. The lab closes it, and this lab is different from the last one: you point our health check at a real domain and read its authentication findings the way a practitioner would.

One request before you start: read the feedback even on answers you get right. The wrong options are wrong in ways real people are wrong, and those reasons are the curriculum.

Term drill

1/19

p=none

the SPF mechanism that delegates to another domain's record, so a tool's servers are authorized without listing their IPsthe policy that delivers failing mail normally while sending you reports about itthe signed chain forwarders add so a receiver can see a message authenticated properly before forwarding altered itthe record that puts your logo in supporting inboxes, gated behind DMARC at enforcement

Vocabulary settles whether you can follow the conversation; diagnosis settles whether anyone should listen to you. The case below is assembled from the pattern the alignment lesson warned about, because in the wild that pattern is not rare, it is the default. The situation updates after each answer, the way real cases do.

The agency added a tool

A friend runs a garden design business on example.com. Her setup has been solid for two years: newsletter through an ESP with the verified sending domain completed, DMARC at p=quarantine, reports flowing to a processor. Three weeks ago her marketing agency connected a review-request tool that emails customers after each finished job. This week, two customers mentioned they found her review request in spam.

Where do you start?

Rewrite the review-request email so it sounds less like spam.Open the raw source of one review request and read Authentication-Results, the Return-Path, and the DKIM d= domain.Drop her DMARC policy to p=none so the review requests stop being quarantined.Have the agency resend the campaign through her ESP instead.

The lab

Run the free health check on your own domain. No domain yet? Borrow one: point the check at a domain you know well, your employer's or a newsletter you trust, and do everything below except the fixing. The findings are read from public DNS, so looking harms nobody.

Before the results load, predict. You know which tools the domain uses and what Part 2 says should be published for them. Every gap between prediction and report is worth a minute of your attention.

Then read the authentication findings one by one.

The SPF findings answer two separate questions. Existence first: there should be a record, and exactly one. Missing means nothing vouches for the domain's servers; two records is the permerror from the SPF lesson, worse than none. Then syntax and safety: whether the record parses, whether it ends in +all (a critical finding, since that authorizes the whole internet), whether every include in the chain still resolves, and how many DNS lookups the record spends as it resolves today. That lookup count deserves the most respect of anything on the report, because it can change without anyone touching the record.

The DMARC findings split the same way. Existence is a record at _dmarc. Strength is what the record actually delivers: the p= value, whether rua= is collecting reports, and whether a pct= or a subdomain policy is quietly weakening what the p= claims. A proud p=quarantine; pct=10 grades worse than it reads, and the grade is the honest version.

The DKIM finding is a probe, and honesty requires saying what a probe can see. From DNS alone, the check tries the selector names providers actually use and reports which keys it found and how long they are, with 1024 bits as the floor. It cannot prove your mail is signed; only a delivered message proves that. Keys present at the expected selectors is evidence, not a verdict, and the report says so plainly.

Around those sit the plumbing findings: MX records (present, resolving, sane priorities), general DNS sanity (coherent nameserver records, an A record where one is expected, suspicious TTLs), then the second shelf from the last lesson: MTA-STS with TLS-RPT, and BIMI, weighted there exactly as they were weighted here, which is lightly.

Now fix one thing. One, not everything; the skill being practiced is choosing the cheapest genuine improvement, and it usually comes from this short list. No DMARC record at all: publish v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com, one TXT record that changes nothing about delivery and turns the radar on, the best first fix in email. Two SPF records: merge them into one and a permerror disappears. An existing DMARC record with no rua: add one, because you can't act on reports you never receive. A +all: change that qualifier today.

Leave the rest alone for now. Policy tightening waits for weeks of reports, and a tool's selector or key-length findings get fixed in the tool's settings, never by hand-editing DNS.

Make the edit where the domain's DNS actually lives (the zone, from lesson three), wait out the TTL, and run the check again. The finding you fixed should clear while everything else stays put. If the old value still shows, that's caching doing what caching does, not a failed fix. Keep the before-and-after pair of reports: it is your first artifact as a practitioner, and Part 6 will teach you to produce them for domains that aren't yours.

Then sit the Part 2 exam: no feedback until the end, and a verdict you can trust.