Checkpoint: reputation

Reputation is where confident wrong beliefs cluster. The earlier parts of this course dealt in checkable facts: a record parses or it doesn't, a signature verifies or it doesn't. This part dealt in scores you will never see, and opacity breeds folklore. The classic failure runs like this: a sender spends two weeks pursuing delisting from blocklists no receiver consults, while the chart that names the actual problem, the spam-rate line in Google Postmaster Tools, sits unread in a browser tab. Vocabulary is what prevents that. Someone who can tell a blocklisting from a complaint problem, or a PTR record from a placement test, fixes the right thing first.

So the drill below is cumulative and deliberately dense: every reputation term from this part, plus a few pulled forward from the authentication module, because alignment and DMARC policy don't stop mattering once reputation enters the picture. If two definitions feel interchangeable to you, that's the drill working. The distinctions it forces are the ones that matter under pressure.

Term drill

1/20

SNDS

the DNS record that maps an IP address back to a hostname; the reverse-DNS half of a sending server's identityMicrosoft's IP-organized view of how your traffic to its mailboxes is treated, usable only by senders who control their sending IPsa published list of IPs or domains that receiving servers consult before accepting mail, usually queried over DNSthe holding area where Microsoft 365 detains suspect mail, surfaced through admin review and digest emails rather than the spam folder

Vocabulary is the entry ticket; judgment is the job. What follows is one sender's spring compressed into three decisions, each built on the answer before it. Reputation trouble in the wild doesn't arrive as a quiz question: it arrives as a gradual slide with a plausible wrong turn at every step, and several of the wrong turns cost real money. Take the decisions in order, and read the feedback on the options you didn't pick, because the wrong options are where the teaching is.

The newsletter that grew too fast

You run the newsletter for a small outdoor-gear shop: 12,000 subscribers, sent weekly through a mainstream ESP on shared IPs. In March a partnership promotion added 4,000 new addresses in three weeks. It's now late April, and your open rate at Gmail addresses has fallen by a third while Outlook and everything else hold steady.

What do you do first?

Rewrite the subject lines; the last few campaigns probably tripped spam words.Open Google Postmaster Tools and read the spam-rate and domain-reputation charts.Buy a warm-up service to rebuild engagement automatically.Upgrade to a dedicated IP so other senders can't drag you down.

The lab

Two checks, and the second one starts a habit this course will keep returning to.

First, the blocklists. Take your domain, and the sending IP you dug out of a Received header earlier in this part, and run both through a blocklist checker that queries the major lists. Spamhaus's own lookup tool is the one to trust for its lists, because it also tells you which component matched and why. Then apply this part's filter to whatever comes back: a listing matters only if real receivers consult the list. Spamhaus-class rows are findings. Red rows on obscure zones are decoration, and any list offering paid removal has identified itself as noise. The free health check covers the domain side in one pass, checking your domain against domain-level listings of the DBL class, and it's a fair cross-check on your manual lookups.

Second, Postmaster Tools. Sign in at postmaster.google.com and confirm the thing everyone forgets to confirm: that it's actually collecting. You want a verified domain and charts with recent data points on the spam-rate line. Empty charts are a finding too; Google only draws them above an unpublished volume threshold, so "not enough Gmail volume yet" is worth knowing and worth writing down rather than shrugging at.

The artifact this checkpoint wants is one line in a note: today's date, your listing status, and your current spam rate (or "charts empty, volume below threshold"). That line is the first entry in a monitoring log, and by Part 5 you'll know exactly why the date matters.

No domain of your own yet? Run the blocklist half read-only against a domain you know, any large retailer will do, and read a clean result end to end. The Postmaster half needs ownership, so park it until you own a domain, which the practitioner track will expect anyway.

The gate out of this part is the Part 3 exam; the drill and scenario above were the training for it.