The Weekly Deliverability Review: What to Check on Every Client Domain

Monday morning, and eleven domains have your name attached to them: your own, plus ten belonging to clients who assume email is a solved problem. Nothing is on fire. That is the problem. Nothing tells you that a contractor edited a DNS zone on Thursday, or that the shared IP behind a client’s newsletter picked up a blocklist entry over the weekend.

A weekly review is how most agencies handle that. It works up to a point, and where that point sits matters as much as the checks.

The four signals that actually drift

Deliverability has a wide surface area and a short list of things that change week to week without anyone deciding to:

1. Auth records. People edit DNS. A vendor gets added and the SPF record ends up split in two. A key gets rotated by the sending platform and the new selector never gets published.
2. Blocklist status. Often nothing to do with the sender. A shared IP inherits a neighbour’s mistake, or an old address on a list turns out to be a spam trap.
3. The DMARC source mix. A new sending source appearing in the reports is either a tool nobody mentioned or someone spoofing the domain.
4. Provider-side reputation. Lagging and slow to move, but it is the only view Gmail offers of how it actually treats the domain.

Everything else either does not move on a weekly clock (list hygiene, templates, sending practice) or moves so slowly a weekly check is the wrong instrument. Scope the review to those four per domain and nothing else.

Signal 1: the auth records, against a known baseline

What a healthy set of records looks like when queried directly:

dig +short TXT example.com
"v=spf1 include:_spf.google.com include:sendgrid.net ~all"

dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; fo=1"

Three failure shapes cover almost everything found in practice. Two separate TXT answers that both start with v=spf1, which is invalid under RFC 7208 and fails the whole check rather than merging the two. An empty answer on a DKIM selector, which means the key was rotated or never finished publishing. And a missing _dmarc record on a domain that had one last month, usually because the zone was rebuilt at a new DNS host.

Worth checking beyond existence: the SPF lookup count. A vendor can add an include: inside their own record and push a domain past the ten-lookup limit without anyone touching its DNS. The SPF flattener shows the whole tree when a record is close to the line, and the email health check returns one verdict per domain instead of three raw answers.

The catch no amount of discipline fixes: a query says what the record holds right now, and the review only means something against a saved baseline. Keeping that baseline current for eleven domains, by hand, is the part that quietly stops happening by month three. LitInboxes re-runs these checks every six hours per domain and stores each result, so the comparison is already made and a change carries the date it happened on. Either way, the review needs a before, not just an after.

Signal 2: the four blocklists worth acting on

Blocklist status is a DNS answer. For IP-based zones, the octets of the sending IP are reversed and the zone appended:

dig +short 24.100.51.198.zen.spamhaus.org
127.0.0.4

Any 127.0.0.x answer is a listing, and the final octet identifies which dataset caught the IP. No answer means clean. The one that misleads people is 127.255.255.254, which is not a listing: it is Spamhaus refusing a query that came through a large public resolver such as 8.8.8.8 or 1.1.1.1. Their DNSBL usage FAQ documents the codes.

Domain-based zones take the hostname instead of a reversed IP:

dig +short example.com.dbl.spamhaus.org

Four lists reliably correspond to real inbox damage: Spamhaus ZEN and DBL, Barracuda, and SpamCop. Check the sending IP and the domain separately, because they get listed for different reasons and usually only one of them is yours to fix. The blocklist checker runs the wider set on a single domain when you need a fast answer.

The manual cost here is arithmetic. Two lookups per list, times four lists, times eleven domains, is eighty-eight queries on a Monday, and each one describes only this moment. A listing that arrives on Tuesday and surfaces six days later has had a full sending week to do damage. LitInboxes queries eight high-signal zones on a schedule and alerts on the transition rather than the state. If the review stays manual, record the date of every clean pass, so a later listing can at least be bracketed to a week.

Signal 3: the DMARC source delta, not the reports

Nobody reads DMARC aggregate reports in full. A raw RUA report is XML with one record block per source, and the part that carries information looks like this:

<record>
  <row>
    <source_ip>198.51.100.24</source_ip>
    <count>412</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>example.com</header_from></identifiers>
</record>

Three questions per source, and only three: who failed, is it ours, and is it new. A known forwarder failing SPF every week is noise, because forwarding breaks SPF by design and DMARC alignment through DKIM is what survives it. A source nobody recognises, sending 400 messages under a client’s From domain, is the reason to open the reports at all.

Two of those three questions are answered by comparison, not by reading. “Is it new” needs last week’s source list for the same domain, so the review depends on a record somebody kept. LitInboxes ingests the reports and surfaces the sources that changed, which is bookkeeping worth handing to something that does not forget. Either way, chase what is new or above roughly one percent of volume and leave the rest alone.

Signal 4: reputation, and the number that has a threshold

Google Postmaster Tools is free and it is the only place Gmail says anything. Two numbers matter: domain reputation, and the spam rate against the 0.3% ceiling in Google’s sender guidelines, specified for bulk senders since February 2024. Below a few thousand messages a day the graphs get gappy, so a single bad day at low volume is weather, not climate.

The manual version is one browser login per client, per week, with nothing watching in between and no alert when a line crosses the threshold. Reputation moves slowly in both directions, so the signal is the trend across weeks rather than Monday’s value, and a trend needs history a weekly glance does not create. Note the reputation state for each domain in writing, because the value of that number lives in its previous value.

Triage order when one goes red

Two signals go red at once often enough that order matters. Work top down and stop at the first cause found:

1. A broken auth record. Fix the DNS, then prove it with a fresh message, because a corrected record does nothing for mail already sent. Read the Authentication-Results line of the new message in the header analyzer before calling it fixed.
2. A blocklist listing on the sending IP or domain. Delist through the list’s own free process, then find the cause, in that order. Never pay for express delisting.
3. Spam rate above 0.3%. Stop the next send. Look at the last campaign and the segment it went to, not at the template.
4. A new failing source in DMARC. Identify the source before touching the policy. Tightening to p=reject while a legitimate vendor is misaligned breaks real mail.
5. Reputation down while everything else is clean. That is engagement, which is a list problem rather than a DNS problem. The full diagnostic order is here.

What a weekly review deliberately leaves out

The review stays short because of what is not in it. Templates that have not changed do not need re-scoring. The long tail of minor blocklists is not worth acting on, since a listing there rarely moves real placement and several of those operators want payment to remove you. Open rate is no longer a deliverability signal worth trusting, for reasons covered in the write-up on the CNIL pixel rule. Seed placement tests belong after a change, or monthly, not weekly.

Adding something to the review means taking something out of it.

Where the weekly model breaks

A review every seven days means the worst-case detection delay is six days. A DKIM key that stops publishing on Tuesday sends unsigned mail until the following Monday, and across eleven domains that exposure multiplies. Running the checks more carefully changes nothing, because the limit is the interval, not the method.

Three responses, in increasing order of how well they hold:

• Tighten the interval. Twice a week halves the exposure and doubles the work. It scales badly past three or four domains.
• Shrink the scope. Review auth records and blocklists weekly, reputation monthly. Cheaper, and it accepts a blind spot on purpose.
• Stop reviewing on a clock. Have the checks run continuously and read only what changed. This is what LitInboxes does: it re-runs the DNS checks on every domain every six hours, keeps the dated history that turns “something broke in July” into “the SPF record lost the SendGrid include on July 16”, watches the blocklists and reputation signals, and sends the change through email, Slack, Discord or a webhook. Monday becomes reading a changelog instead of running eighty-eight queries.

The free tools linked above answer today’s question for one domain. Continuous monitoring answers next Tuesday’s question for all of them, which is a different job. There is a walkthrough here if you want to see it without signing up for anything.

The review, in order

Per domain:

1. Confirm exactly one v=spf1 answer, matching the expected record, and inside the ten-lookup limit.
2. Confirm a non-empty DKIM key for every selector in use.
3. Confirm the DMARC policy and rua address are what was set.
4. Check ZEN, DBL, Barracuda and SpamCop, for the sending IP and the domain separately.
5. Compare this week’s DMARC sending sources against last week’s, and chase only what is new or large.
6. Read domain reputation and spam rate in Postmaster Tools against the 0.3% line.
7. Record one dated line per domain, even when nothing happened, especially when nothing happened.
8. If something is red, work the triage order above and stop at the first cause.

Steps 1 through 6 are the review. Step 7 is what makes next week’s review possible, and it is the step that gets skipped first. Anything running these checks between Mondays writes step 7 for you, which is most of the argument against doing this by hand once the domain count reaches double digits.

The same eight steps are available as a one-page printable, with a checkbox per item and the triage order on it, sized to tape next to a monitor and tick through client by client. The form below sends it over.