list-health

---
name: list-health
description: Finds out why your emails stopped arriving - the DNS records, the bounces, the dead addresses and the complaint rate - and returns the fixes in the order that actually restores delivery. Use when opens have fallen off a cliff, when customers say they never got it, or before you send to a list you have not used in months.
---

# Find out why your emails stopped arriving, and fix it in the right order

You give this your sending domain, your last few months of send and bounce reports, and the list itself. You get back what your domain is publishing to the world right now, which of the three authentication records is missing or broken, how many addresses on your list are dead, what your complaint rate is, and a numbered fix list in the order that restores delivery fastest. It reports what it read, not what it assumes, and anything it could not read it says it could not read.

## What it does

1. **Read the three DNS records as they are published today, not as somebody set them up two years ago.** Query the domain for its SPF record, its DKIM selector records and its DMARC record and print the raw text of each. An SPF record is defined in RFC 7208 as "a DNS record that declares which hosts are, and are not, authorized to use a domain name for the 'HELO' and 'MAIL FROM' identities", and section 4.5 requires records beginning "with a version section of exactly 'v=spf1'". DMARC lives at `_dmarc.<domain>`. DKIM lives at `<selector>._domainkey.<domain>` and you need the selector your sending platform actually uses, which is in the DKIM-Signature header of any message you have already sent. Print what came back. Half of all delivery problems are visible in these three lines and nobody has ever looked at them.

2. **Count the SPF lookups, because ten is a hard ceiling and nothing warns you.** Every `include:`, `a`, `mx`, `ptr`, `exists` and `redirect` in an SPF record costs a DNS lookup, and nested includes count too. RFC 7208 section 4.6.4 states that "SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS". Exceed it and SPF returns a permanent error, which is a fail, not a pass. Microsoft's own sender FAQ says the same thing in plainer words: "If you exceed 10 DNS lookups, your SPF check might fail." A venue that has added a booking platform, a review platform, a payroll system and a newsletter tool over four years is usually at twelve or thirteen and has no idea.

3. **Check alignment, which is the thing that fails while every individual record passes.** DMARC does not care that SPF passed. It cares that the domain that passed matches the domain in the From line the customer sees. RFC 7489 section 3.1 puts it as: "When the domain in the RFC5322.From address matches a domain validated by SPF or DKIM (or both), it has Identifier Alignment." Google states the requirement directly for bulk senders: "For direct email, the domain in the sender's From: header must be aligned with either the SPF domain or the DKIM domain." This is the classic small-business failure. The newsletter goes out From your own domain, SPF passes for the platform's own domain, DKIM signs with the platform's domain, DMARC fails alignment, and the mail lands in junk while every individual check looks green.

4. **Read the DMARC policy and the reporting address, and say what it is currently doing to your mail.** RFC 7489 section 6.3 defines the `p` tag values: `none` means "The Domain Owner requests no specific action be taken regarding delivery of messages", `quarantine` means the owner "wishes to have email that fails the DMARC mechanism check be treated by Mail Receivers as suspicious", and `reject` means the owner "wishes for Mail Receivers to reject email that fails the DMARC mechanism check". If the policy is `quarantine` or `reject` and step 3 found an alignment failure, that is the whole answer and everything else in this check is secondary. Also read the `rua` tag, "Addresses to which aggregate feedback is to be sent". If there is no `rua`, nobody has ever seen a report, and the first fix is to add one and wait a week.

5. **Classify the bounces, because hard and soft mean opposite things.** A hard bounce is a permanent rejection: the address does not exist. Those come off the list immediately and never go back on. A soft bounce is temporary: a full mailbox, a server down, a greylist. Those are retried and only removed after repeated failures across separate sends. Yahoo's guidance is to "Monitor hard and soft bounces as well as inactive recipients" and to "Remove invalid recipients from your list promptly", and Microsoft's is to "Remove invalid addresses regularly to reduce spam complaints, bounces, and wasted messages" and, on frequency, to "Aim to remove inactive or invalid addresses regularly - monthly or quarterly." One specific rejection string is worth recognising on sight: Microsoft returns "550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level" when a high-volume sender fails authentication, and that message means steps 1 to 4 are the problem, not the list.

6. **Get the complaint rate from the provider, not from the sending platform.** Google's requirement is to "Keep spam rates reported in Postmaster Tools below 0.30%", and its Postmaster documentation defines the user-reported spam rate as "The percent of your messages that are delivered to engaged recipient's Inbox and then marked as spam by the recipient". Yahoo's threshold is the same: "Keep your spam rate below 0.3%." Postmaster Tools also reports domain reputation on a four-step scale where High is "History of very low spam rates, and complies with Gmail's sender guidelines", Medium is "History of sending legitimate email, but occasionally sends spam", Low is "History of sending a significant volume of spam regularly" and Bad is "History of sending a high volume of spam regularly". If nobody has ever verified the domain in Postmaster Tools, that is a ten-minute job and it is the only place these numbers exist.

7. **Separate the dead addresses from the disengaged ones and treat them differently.** A dead address bounces. A disengaged address accepts every message and nobody ever opens one, and that is worse, because it looks like a delivered email while teaching the provider that your mail is ignored. Group by how many consecutive sends a person has received without opening or clicking. Yahoo suggests you "Consider sending a reconfirmation email to inactive subscribers periodically", so the disengaged group gets one plainly worded message asking whether they still want to hear from you, and everybody who does not answer is suppressed rather than deleted. The ICO's position supports keeping them suppressed rather than erased: a suppression list "isn't for direct marketing purposes", it is kept so you can comply with an objection, and it stops the same address being re-added from a future import.

8. **Check the From and Reply-To actually work, because a dead reply address is a reputation problem as well as a rudeness.** Microsoft's guidance asks senders to "Ensure the 'From' or 'Reply-To' address is valid, reflects the true sending domain, and can receive replies", and to use "accurate subject lines, avoid deceptive headers, and ensure your recipients have consented to receive your messages". Send a real reply to your own reply-to address and confirm it lands somewhere a person reads. A `noreply@` that bounces is a signal to every provider that this is bulk mail from somebody who does not want to hear back.

9. **Write the fix list in the order that restores delivery, with a date beside each one.** Authentication first, because nothing else matters while mail is being rejected: fix SPF and its lookup count, publish or correct DKIM, publish DMARC at `p=none` with a `rua` address and leave it there long enough to read the reports before tightening it. Then hygiene: remove hard bounces, run the reconfirmation to the disengaged, suppress the non-responders. Then the send pattern: resume at a lower volume to the most recently engaged segment and build back up. Doing it in the other order, cleaning the list first while SPF is still broken, produces a smaller list with the same problem and a month lost.

## Then it checks

1. The raw text of the SPF, DKIM and DMARC records appears in the output exactly as returned by DNS, with the query date, and any record that could not be resolved is reported as "not published" rather than left blank.
2. The SPF DNS lookup count is stated as a number, counting nested includes, and is compared explicitly against the limit of 10.
3. The alignment result is stated separately from the SPF result and the DKIM result, and the output names which domain appears in the From header and which domains passed.
4. The DMARC policy value is quoted from the published record and the output says in plain words what that value is currently doing to failing mail.
5. Hard bounces, soft bounces, disengaged addresses and suppressed addresses are four separate counts that add up alongside the active count to the total rows read, and no address moves category without the send it failed on being named.
6. Every complaint or reputation figure in the output names the provider tool it was read from and the date it was read, and no figure is described as typical, average or industry standard.

Any check fails: name it, redo that step once. Failed twice: say what is wrong and stop.

## Rules
- Public information only.
- Never invent a fact, a number or a quote.
- Anything sent in someone's name says whose name it is.
- Never move DMARC straight to `p=reject`. Microsoft's own advice is to move "gradually (none to quarantine to reject) to avoid unintended mail loss", and a venue whose booking confirmations, invoices and newsletters leave from four different systems will silently stop delivering some of them the day the policy tightens.
- Never delete an address that unsubscribed or failed a reconfirmation. Suppress it. A deleted address comes back on the next import from the booking system and gets emailed again, which is the exact breach the suppression list exists to prevent.
- Never guess at a figure a provider tool can give you. If Postmaster Tools has not been set up, the honest output is "complaint rate unknown, Postmaster Tools not verified for this domain", not an estimate.
- This output is a working document prepared for the owner's IT provider, web host or data protection adviser to check before any DNS record is changed. A wrong SPF or DMARC record can stop every email the business sends, including invoices and booking confirmations, and nothing here is advice on your particular setup.

## Built from
- IETF, RFC 7208, "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", https://www.rfc-editor.org/rfc/rfc7208.html, April 2014, read 14 September 2026: the SPF record definition and version string in step 1 and the ten-lookup limit in step 2.
- IETF, RFC 7489, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", https://www.rfc-editor.org/rfc/rfc7489.html, March 2015, read 14 September 2026: the identifier alignment definition in step 3 and the policy and rua tag definitions in step 4.
- IETF, RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures", https://www.rfc-editor.org/rfc/rfc6376.html, September 2011, read 14 September 2026: the DKIM key record format behind the selector lookup in step 1, and the limit on what a signature proves, that verifying it "asserts that the hashed content has not changed since it was signed and asserts nothing else".
- Google, "Email sender guidelines", https://support.google.com/mail/answer/81126, effective 1 February 2024 as stated on the page, read 14 September 2026: the alignment requirement in step 3 and the 0.30% spam rate threshold in step 6.
- Google, "Postmaster Tools dashboards", https://support.google.com/a/answer/14668346, no publication date shown on the page, read 14 September 2026: the verbatim definition of user-reported spam rate and the four reputation categories quoted in step 6.
- Yahoo, "Sender Best Practices", https://senders.yahooinc.com/best-practices/, no publication date shown on the page, read 14 September 2026: the bounce monitoring and reconfirmation advice in steps 5 and 7 and the 0.3% threshold in step 6.
- Microsoft, "Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders", https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730, published 2 April 2025 and updated 30 April 2025, read 14 September 2026: the 550 5.7.515 rejection string and the monthly-or-quarterly hygiene cadence in step 5, the From and Reply-To requirement in step 8, and the gradual DMARC rollout in the rules.
- Information Commissioner's Office, "Respect people's preferences", https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/direct-marketing-guidance/respect-peoples-preferences/, no publication date shown on the page, read 14 September 2026: the suppress-do-not-delete position in step 7 and the second bespoke rule.

# Email deliverability audit

## You are given
A sending domain name, optionally the DKIM selector the sending platform uses, optionally a bounce report or send log (CSV or text), and optionally the marketing list as a CSV with an email column and a last-engagement date. You have network access and can query DNS.

## Produce
Write these files into `./list-health-output/`:

1. `dns-audit.csv`, columns `record_type`, `queried_name`, `raw_value`, `status`, `finding`. One row each for `SPF`, `DKIM`, `DMARC`, plus a row per extra DKIM selector found. `status` is `published`, `not published` or `query failed`. `raw_value` is the record exactly as returned, never reformatted or summarised.
2. `spf-lookups.csv`, columns `mechanism`, `resolves_to`, `depth`, `cumulative_count`. One row per DNS-querying term, following nested `include:` and `redirect=` to full depth. Final row has `mechanism` set to `TOTAL`.
3. `list-hygiene.csv`, columns `email_lower`, `category`, `evidence`, `last_engagement_date`. `category` is exactly one of `active`, `hard_bounce`, `soft_bounce`, `disengaged`, `suppressed`. `evidence` names the send or bounce line it came from.
4. `counts.txt`: rows read, the count in each of the five categories, their sum, and a line stating whether the sum equals the rows read.
5. `fix-list.md`: numbered fixes in this order and no other - authentication, then hygiene, then send pattern. Each states what to change, where, and what breaks if it is done wrong.

## Rules
- Query `<domain>` for TXT to find SPF, `_dmarc.<domain>` for DMARC, and `<selector>._domainkey.<domain>` for DKIM. If no selector was supplied, say so in `dns-audit.csv` and set `status` to `query failed` with `finding` reading `selector not supplied`.
- Count SPF DNS-querying terms as `include`, `a`, `mx`, `ptr`, `exists` and `redirect`, following nesting. Compare the total against 10 explicitly in `finding`.
- State the DMARC alignment risk as its own row in `dns-audit.csv` when the From domain and the SPF or DKIM domains differ.
- Never invent a complaint rate, a reputation score, an open rate or an industry average. If a figure was not supplied, write `unknown, not supplied` in the relevant `fix-list.md` line.
- Never propose `p=quarantine` or `p=reject` as a first change. The first DMARC fix is always `p=none` with a `rua` address.
- Never delete a row. Addresses leave the active set by becoming `suppressed`, never by disappearing.
- Do not send any email, change any DNS record, or contact any person. You read DNS and produce files only.

## Return
Print the absolute path of each file written, the raw SPF, DKIM and DMARC records exactly as returned, the SPF lookup total against the limit of 10, whether alignment is at risk, the five category counts with the sum check, and the first three items from `fix-list.md`. If a DNS query failed, say which name failed and what the resolver returned.