Checklist: block lists on public pages

DNS block list findings invite drama. I prefer a checklist. On SlaySlop, DNS block lists "checks whether the domain or address appears on public block lists." The checks catalog places it under Security. Treat that definition as the ceiling for what you claim on a call.

Related drafts already cover evidence packets in depth; this checklist is the operator order before anyone says "malware."

Outcome

You know whether the scanned domain or address appeared listed on the public blocking resolvers the product uses, you have classified name versus shared-IP issues, and you have an owner for remediation or justification.

Boundaries

Read-only. Permission required. Not a pentest. A listing is not proof you authored malware. The check does not delist you. It does not replace TLS, headers, or Client-side secrets. Do not probe random third parties to "see if they are listed too."

Checklist

1. Confirm the hostname in the finding matches the production brand you mean.
2. Open DNS block lists evidence (resolver rows / summary, do not invent counts).
3. Note whether the hit is on the name, the address, or both.
4. Check for shared hosting / CDN anycast reality before brand-level panic.
5. Open adjacent Domain insights (DNS records, mail configuration) if delivery issues co-occur.
6. If listed, follow the list operator's published remediation path, or document why the listing is expected for a shared address.
7. Do not "fix" by switching to an unlisted IP and forgetting to move DNS correctly.
8. Rescan DNS block lists after DNS settles.
9. Keep headers/secrets triage on a separate clock unless evidence ties them together.

# Authorized domain, orientation only
dig www.example.com A +short
dig example.com MX +short

Those digs do not replace multi-resolver product evidence. They stop you from triaging the wrong name.

Pitfalls

Escalating a shared-IP listing as a unique brand conviction. Ignoring a clean block-list row while mail is broken for other reasons. Pasting full resolver tables into public blogs. Claiming SlaySlop "cleared malware" because a rescan went quiet.

Related next step

Run the checklist, classify name versus IP, act, rescan. Glossary entry: slayslop.com/glossary/block-lists.

Writing the ticket subject

Good subjects look like "DNS block lists: www.example.com listed on (IP shared?)" Bad subjects look like "WE ARE BLOCKED EVERYWHERE." The checks catalog also includes Mail configuration and Client-side secrets as separate concerns, do not stuff them into the same subject line unless evidence truly links them.

After rescan, archive the prior evidence beside the new summary. Quiet rescans without history teach the wrong lesson when a listing returns.

Coordination with mail and security siblings

If customers report spam-folder issues while DNS block lists is clean, open Mail configuration next. If block lists is red and Client-side secrets is also red, still use separate tickets, leaked keys and list listings can co-occur without sharing a root cause. Connect them only when evidence connects them.

Engineers sometimes want to "verify" a listing by hitting obscure resolvers manually. Prefer the product's multi-resolver evidence. Manual digs are orientation. They are easy to misread as the full set.

When leadership asks for a one-line status, use: "Public blocking resolvers list/do not list this name or address as of scan time X; remediation owner Y." That sentence stays inside the glossary definition.

Done criteria

You are done when resolver evidence matches the story you told the client, DNS changes have propagated, a rescan shows the expected clear or accepted shared-IP state, and the ticket links both old and new evidence. Anything less is a pause, not a close.