Checkpoint: the diagnosis capstone

Every checkpoint so far pointed you at your own domain and asked what you found. This one hands you somebody else's, on paper, and asks for the whole job: read the evidence, name the root causes, order the repair, prove the fix landed. It is the exam before the practitioner track, and it works the way the work works. Nobody emails a consultant a tidy problem statement. You get a worried owner's account, a pile of DNS output, a delivery failure, and a message fished out of a spam folder, and the diagnosis has to come out of that pile.

Two habits get graded. The first is evidence order, the discipline the triage tree drilled: work the measurable layers before the interpretive ones. The second is cross-checking. Every artifact below describes the same domain over the same weeks, and the artifacts corroborate each other the way real evidence does; when a header names a selector, that selector should be findable (or conspicuously missing) in the DNS transcript, and when a gateway cites policy, some record failed to satisfy it.

Vocabulary first, though. The drill is cumulative as always and weighted to this part, because the report you write at the end is expected to use these words precisely. A findings table that says "the DNS thing is broken" bills at a very different rate than one that says "permerror".

Term drill

1/20

Return-Path

an SPF evaluation failure that makes the record unusable to receiversthe envelope sender; bounces go there and SPF evaluates its domainhow many seconds resolvers may keep serving a cached DNS answerthe match between the visible From domain and an authenticated domain

The case file: fern-and-frond.example

Fern & Frond is fictional. The shop, the people, the providers and every hostname below live on reserved documentation names, and that is the one artificial thing about the case. Its shape is taken from life: a website agency migrates DNS, some records don't survive the trip, and the owner spends a season wondering why nobody reads the newsletter. In the domains we monitor, the DKIM selector that quietly vanishes during a site migration is one of the most common breaks we see, and by the time anyone looks, it is rarely the only fault in the zone.

Treat the four exhibits as your complete case file. They describe one domain across one timeline. Cross-check them; they were built to agree with each other, the way real evidence does.

The intake email

From: Rosa Marchetti <hello@fern-and-frond.example>
Subject: Newsletter and email trouble since our website move
Date: Fri, 17 Jul 2026 09:02:44 +0100

Hi,

We're a small plant nursery with a shop and a wholesale side. In April
an agency rebuilt our website and moved our domain settings onto their
platform, SiteGrow (the move happened on 17 April; they said nothing
else would change). The website is fine.

The email is not. Our newsletter goes out on the first Thursday of the
month to about 4,000 subscribers through PetalPost. Open rates sat
around 40 percent for years. May was 12 percent, June was 11. Our
wholesale buyer at Thistle Trade says the July issue never arrived at
all, and PetalPost's delivery log shows a failure notice for their
address. My sister Ivy is subscribed on her PlumeMail address; her July
copy went to her spam folder, and she sent me the message source.

Also, since May at least two customers have told us that quote replies
from our normal shop mailboxes (we're on MailHaven for those) landed in
their junk folders.

Nothing changed on our end. We switched the newsletter from Bloomsend
to PetalPost back in February last year, if that matters. The agency
says they copied all our settings and the website is fine. Can you tell
us what is actually wrong, and how bad it is?

Rosa

What DNS says today

You ran the lookups yourself, from outside the shop's network. The transcript is trimmed to the load-bearing answers.

$ dig +short NS fern-and-frond.example
ns1.sitegrow.example.net.
ns2.sitegrow.example.net.

$ dig +short A fern-and-frond.example
203.0.113.80

$ dig +short MX fern-and-frond.example
10 mx1.mailhaven.example.net.
20 mx2.mailhaven.example.net.

$ dig +short TXT fern-and-frond.example
"v=spf1 include:spf.mailhaven.example.net ip4:203.0.113.10 include:spf.bloomsend.example.net ~all"

$ dig +short TXT _dmarc.fern-and-frond.example
"v=DMARC1; p=none;"

$ dig TXT pp1._domainkey.fern-and-frond.example
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 17552

$ dig TXT mh._domainkey.fern-and-frond.example
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40219

$ dig TXT spf.bloomsend.example.net
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23984

$ dig +short TXT spf.mailhaven.example.net
"v=spf1 ip4:192.0.2.128/26 -all"

(pp1 is the selector PetalPost's dashboard says it signs with; mh is the selector MailHaven documents for hosted mailboxes.)

The bounce

From PetalPost's delivery log: the July issue's copy to the wholesale buyer.

From: Mail Delivery System <MAILER-DAEMON@petalpost.example.net>
Subject: Delivery Status Notification (Failure)
Date: Thu, 2 Jul 2026 10:14:52 +0000

Your message to orders@thistle-trade.example.com could not be
delivered.

Reporting-MTA: dns; mail-out-3.petalpost.example.net
Final-Recipient: rfc822; orders@thistle-trade.example.com
Action: failed
Status: 5.7.1
Remote-MTA: dns; gateway.thistle-trade.example.com
Diagnostic-Code: smtp; 550 5.7.1 Unauthenticated mail from
    fern-and-frond.example rejected: no aligned SPF or DKIM pass
    for the From domain (local policy GW-AUTH-04)

The copy from a spam folder

The raw source of Ivy's July issue, abbreviated. She received it; her provider filed it in spam.

Return-Path: <bounces+ff-2841@bounces.petalpost.example.net>
Authentication-Results: mx.plumemail.example.com;
       spf=pass smtp.mailfrom=bounces.petalpost.example.net;
       dkim=fail (no key for signature) header.d=fern-and-frond.example
         header.s=pp1;
       dmarc=fail (p=none) header.from=fern-and-frond.example
Received: from mail-out-3.petalpost.example.net
        (mail-out-3.petalpost.example.net [198.51.100.24])
        by mx.plumemail.example.com with ESMTPS id q7r8s9
        for <ivy.marchetti@plumemail.example.com>;
        Thu, 2 Jul 2026 03:15:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=fern-and-frond.example; s=pp1;
        h=from:to:subject:date; bh=...; b=...
From: "Fern & Frond" <hello@fern-and-frond.example>
Subject: July at the nursery: repotting season

Read the pile once on your own before the scenario walks it. It is all there.

Working the case

The case file is open on your desk: the intake email, the dig transcript, the bounce, and the spam-folder copy. Rosa is waiting to hear something, and the agency has already told her the website is fine.

Where do you start?

Log into PetalPost and MailHaven, pull the DNS values they expect, and re-add whatever is missing.Pin the symptoms to the timeline: two separate mail streams went bad, and both date from the 17 April migration. Then read the DNS evidence layer by layer.Run the domain and the sending IP through blocklist lookups first; a cliff in open rates usually means a listing.Ask the agency to move DNS back to the old provider and restore the previous zone.

Write it up

The scenario walked the reasoning. The deliverable is written, and it is the artifact this checkpoint exists to produce: a findings report Rosa could hand to her agency, and you could defend line by line. One row per finding, five columns.

| # | Finding | Evidence | Severity | Fix | Verification | |---|---------|----------|----------|-----|--------------| | 1 | | | | | | | 2 | | | | | | | 3 | | | | | | | 4 | | | | | | | 5 | | | | | |

There are five findings in this case file. Four live in the exhibits; the fifth is about process, and it is the one this whole course has been building toward. How to fill the columns:

Finding is one plain-English sentence naming the broken thing. Evidence cites the exhibit and the exact line (a finding you can't point at is an opinion). Severity grades by cost and speed: critical means mail is being rejected or junked right now, high means it will be soon, medium means you are flying blind, housekeeping means it works today and bites later. Fix names the change and where it gets made, and across rows the fixes must land in dependency order. Verification is the external proof, TTL patience included; "the dashboard went green" does not appear in this column.

Grade yourself on the fifth row. The break happened on 17 April and the intake email is dated 17 July. Three months passed because nothing watched the records and no reports flowed to anyone; the rua tag was the cheapest insurance in the whole zone, and it was missing. Notice, too, what the timeline says about the other rows: one fault was an event (the migration dropped the CNAMEs on a known day) and one was rot (the Bloomsend include sat harmless after the ESP switch and turned toxic whenever that hostname went dark, with nobody watching either way). A diagnosis has to hold both kinds in mind, which is why the timeline step never gets skipped.

One honest aside: on a live engagement, the record layer of this file is what the free health check reads in under a minute. The capstone hands you raw dig output instead because the skill being graded is the reading, not the clicking, and a practitioner has to be able to do it the slow way before trusting any tool to do it fast.

Keep your finished table; the practitioner track turns this five-column format into a client deliverable. The Part 6 exam closes the part first: breadth across the whole craft, scored.