A domain-level blocklist, not an IP-level one
Validity launched the Heatwave blocklist on 3 September 2026. The distinction that matters most for senders used to older blocklists like Spamhaus's IP-based lists: Heatwave evaluates sending domains, not just IP addresses. That means switching sending IPs - a common tactic for recovering from an IP-based listing - does nothing to clear a domain-level Heatwave listing, because the reputation signal is tied to the domain itself, not the infrastructure sending on its behalf.
What triggers a Heatwave listing
Validity built Heatwave on the same underlying signal set its Sender Score and certification products have used for years: spam complaint patterns, spam-trap hits, and engagement quality, but aggregated at the domain level and cross-referenced against Validity's own seed network and partner data. A domain can end up listed because of problems on a single subdomain or a single sending platform if that activity is visible to Validity's monitoring and severe enough, even if the rest of the domain's sending is clean.
How to check your status
Check your domain against Heatwave at lookup.validity.tools. Unlike some older blocklists that require scraping a DNS-based zone file, Validity's lookup tool gives a direct domain-level result. Check this alongside - not instead of - the blocklists you may already be monitoring; a domain can be clean on Spamhaus and still appear on Heatwave, since the two organisations use different data sources and methodology.
The delisting path
Validity runs its own review path for Heatwave, reached through the /delist review process on the same tool. The general pattern for any reputation-based blocklist delisting applies here too:
- Confirm the listing and read whatever reason code or category Validity's lookup provides.
- Fix the underlying cause - this usually means pausing the specific sending source responsible, cleaning the list segment involved, and confirming SPF/DKIM/DMARC alignment is correct for that domain.
- Submit the delist request through the review path, with a clear, honest description of what caused the listing and what you changed.
- Expect a review period rather than instant removal - reputation-based blocklists verify that the fix is real before delisting, not just that a request was submitted.
- Monitor afterward. A second listing within a short window after delisting is treated more severely than a first-time listing.
Quick reference
| Step | Where |
|---|---|
| Check listing status | lookup.validity.tools |
| Identify affected sending source | Your own sending logs, cross-referenced with the listing reason |
| Fix root cause | Pause bad source, clean list, verify authentication |
| Request delisting | /delist review path on lookup.validity.tools |
| Monitor after delisting | Ongoing - don't assume it's resolved permanently |
How Heatwave fits alongside Validity's other products
Validity also runs Sender Score, a long-standing IP-level reputation score, and a certification program that some senders use to improve inbox placement with participating providers. Heatwave is a separate product from both - a domain-level blocklist rather than an IP-level score or a certification scheme - and a clean Sender Score or active certification doesn't guarantee a domain is clear of a Heatwave listing, since the evaluation criteria and scope differ between the products even though they come from the same company.
If you already monitor Sender Score as part of your regular reputation checks, add a Heatwave lookup as a separate, additional step rather than assuming good standing on one Validity product implies good standing on all of them. The two measure different things - IP reputation versus domain-level blocklist status - and a problem can show up on one without the other flagging it at all. Participating in Validity's certification program, where eligible, is a separate decision from monitoring Heatwave - certification can improve placement with participating receiving networks specifically, but it doesn't make a domain immune to a Heatwave listing if the underlying sending practice triggers one. Treat the two as complementary rather than one substituting for the other. Review your standing on both fronts - Heatwave status and certification eligibility - on the same recurring schedule, since treating them as separate, unrelated checks on separate schedules tends to mean one of the two gets forgotten over time.
What not to do
Do not rotate to a new sending domain to avoid a Heatwave listing - since the list evaluates domains, this works short-term at best and burns a fresh domain's reputation in the process if the underlying sending practice hasn't changed. Do not submit a delist request before actually fixing the cause - a rejected or reversed delisting is worse for ongoing review than taking an extra day to fix the real problem first. Do not assume being clear of the older IP-based blocklists means you're clear of Heatwave; check both.
MailPilot tracks per-mailbox and per-domain reputation daily, including bounce and complaint signals that correlate with the kind of activity blocklists like Heatwave monitor, so a problem is visible on your own dashboard before it escalates to a domain-level listing.
Ready to reach the inbox every time?
Automated email warmup across real peer mailboxes. Live inbox placement monitoring. Free 7-day trial - no credit card required.
Start free trial