Spamhaus published updated Sender Guidelines in October 2026, and one line in them is going to cost outbound teams their November. Starting this month, it is gradually rolling out a requirement for every sending IP to have a valid HELO, a reverse DNS (PTR) record and a matching A record. Reverse DNS email deliverability stopped being a best practice and became a gate.
None of the three requirements is new guidance. Forward-confirmed reverse DNS has been in every serious deliverability checklist for twenty years. What changed is that the Spamhaus Sender Guidelines now describe enforcement of basic DNS requirements over several months, on a rollout with no published end date and no published phases, against data that protects 4.5 billion user mailboxes.
And the listing zones involved are not the gentle ones. Spamhaus names CSS, its Email Spam IPs zone, and XBL, its compromised IPs zone. A poorly configured mail server looks identical from outside to a compromised one, so it gets treated like one. That is a block, not a filter.
The reason this lands harder on cold email than on anything else is ownership, and it is worth being precise about why.
What The Reverse DNS And HELO Requirement Actually Says
Spamhaus requires three things of every sending IP: a reverse DNS entry pointing to a fully qualified domain name, a HELO or EHLO hostname that resolves to the connecting IP and stays consistent across connections, and a forward A record that resolves the rDNS hostname back to the same IP.
That last condition is the one teams get wrong. Forward-confirmed reverse DNS means the loop closes in both directions. The IP has a PTR pointing at a hostname, and that hostname has an A record pointing back at the IP. Half of that configuration is worse than none, because it looks deliberate and wrong rather than merely absent.
| REQUIREMENT | WHAT IT MEANS IN PRACTICE | WHO PUBLISHES IT | FAILURE MODE |
|---|---|---|---|
| Reverse DNS (PTR) on the sending IP | The IP resolves to a fully qualified domain name you recognise, not a hosting-provider default | The holder of the IP address block | Listing on CSS or XBL, treated as misconfigured or compromised |
| Forward A record for that hostname | The rDNS hostname resolves back to the same sending IP | You, in your own DNS zone | Reverse lookup succeeds, forward confirmation fails, still non-compliant |
| HELO or EHLO hostname resolves to the sending IP | Your mail server announces a name that matches the IP it is connecting from | You, in the mail server or sending platform config | Generic or placeholder HELO reads as a compromised host |
| HELO consistency across connections | The same IP always announces the same name | You, across every device sending on port 25 | Multiple HELO values from one IP can read as proxy or malware behaviour |
| SPF, DKIM, DMARC | Domain-level authentication, aligned with the From domain | You, in your own DNS zone | The failure everyone already monitors, and not what changed this month |
Spamhaus itself says missing reverse DNS, an invalid HELO, or no matching A record is one of the most common reasons for listings. That is the tell. It is the most common cause precisely because almost nobody checks it, which is also why an enforcement push finds so much to list.
There are two free ways to test it, both published in the guidelines: the Spamhaus HELO checker, and sending a message to helocheck@abuseat.org from the server in question and reading the reply. Both take minutes. Neither requires a vendor conversation, which makes them the right first move before you start one.
Why Reverse DNS Email Deliverability Is Not In Your DNS Zone
A PTR record lives in the reverse DNS zone for an IP address block, which is delegated to whoever holds that block. Adding a PTR entry to your own domain's DNS zone does nothing at all, and this is the single most common misunderstanding about reverse DNS email deliverability.
Think about what that means for the way outbound actually gets built. Every other deliverability control an outbound team owns is a TXT record away. SPF, DKIM, DMARC, BIMI, MTA-STS: you write them, you publish them, you verify them in an afternoon. We walked through exactly that kind of domain-level work when DMARCbis changed what sending domains have to publish, and the whole exercise was within one team's control.
Reverse DNS breaks that pattern. You can configure the HELO hostname, and you can publish the forward A record, but you cannot set the PTR. You can only ask. Which turns a technical requirement into a procurement question, and procurement questions take weeks that a gradual enforcement rollout does not promise to give you.
The irony is that the teams most exposed are the ones who did the most work. A company sending through Google Workspace or Microsoft 365 inherits properly configured reverse DNS on infrastructure maintained by people whose job it is, and will sail through this without knowing it happened. A team that built private sending infrastructure to escape bulk-sender limits now owns a requirement it cannot satisfy alone.
“Every deliverability control you can publish yourself, you already monitor. The one you cannot publish yourself is the one nobody has checked in two years.”
Who Owns Your PTR Record, By Sending Setup
Ownership of the PTR record follows ownership of the IP address, so the answer differs completely across the four ways outbound mail gets sent. Work out which row you are in before you open a support ticket, because three of the four need a different conversation.
| SENDING SETUP | WHO CONTROLS THE PTR | TYPICAL EXPOSURE | YOUR MOVE THIS WEEK |
|---|---|---|---|
| Google Workspace or Microsoft 365 mailboxes | The provider, on shared outbound infrastructure | Low. Reverse DNS on these ranges is maintained as a matter of course | Verify with the HELO check, then spend the time on list quality instead |
| Managed cold email infrastructure with dedicated IPs | The vendor, who provisions the IP and sets the PTR | Medium. Several vendors automate PTR setup on provisioning, but automation is a claim until you have tested it | Run the HELO check per IP and get the vendor to confirm branded rDNS in writing |
| Shared-IP SMTP relay or bulk sending service | The provider, across many unrelated senders | High. Shared ranges carry other senders' behaviour and generic provider rDNS | Test it, and if the rDNS is a hosting default, move off shared IPs for outbound |
| Self-hosted mail server on a VPS or cloud instance | You, but only through the hosting provider's control panel | High, and entirely yours. Default rDNS on a fresh cloud instance is a provider hostname | Set branded rDNS on your own domain, add the matching A record, align the HELO |
The managed-infrastructure row is where most outbound programmes now sit, and it is the row that needs the most scepticism. Vendors in this category do claim automatic PTR configuration on provisioning, and the serious ones deliver it. The problem is that the claim is cheap to make and the failure is invisible from the dashboard you are paying for.
Two questions settle it. First: does the PTR for each of my dedicated IPs resolve to a hostname on a domain I recognise, with a forward A record pointing back? Second: what HELO name does your platform announce from that IP, and is it the same name every time? A vendor that cannot answer both in a day is telling you something.
This also reopens an argument the outbound world has been having all year. We laid out the case on both sides when the debate was private networks against simply buying more domains, and at the time the scoring was close. IP-layer enforcement moves it. Private infrastructure still wins on control and on volume headroom, but the cost column just grew an audit obligation that the more-domains approach never had, because somebody else's reverse DNS was always somebody else's problem.
Which deliverability controls an outbound team can publish without asking anyone, scored as full control, partial, or none. Configuration ownership, not a difficulty score
The Trap: Correct Reverse DNS On An IP With No History
Fixing the records is necessary and not sufficient. Spamhaus states that HELO domains with no sending history are subjected to additional filtering, and separately advises treating any IP or domain that has not sent for 90 days as new and warming it accordingly.
Read those two sentences next to the standard cold email infrastructure playbook and the conflict is obvious. That playbook rotates. New domains, fresh IPs, pools cycled out when a blocklist hit lands, sending spread thin across many identities so no single one accumulates damage. It is a sensible response to per-identity reputation. It also guarantees that a large share of your sending estate is permanently in new-sender status, which is exactly the state that now attracts extra filtering.
We argued a version of this when warmup pools, blocklist hits and domain rotation stopped being independent decisions, and the mechanism here is the same one. Rotation buys you insulation from a single bad identity and pays for it in permanent newness. The November change raises that price without changing the benefit.
What To Fix This Week
The whole remediation path fits in one working day for a team that knows where its IPs are, and the first half of it needs no vendor cooperation at all. Test every sending IP, publish the forward records you control, then escalate only the PTR entries you cannot set.
Start by listing every IP that sends mail on your behalf, which is harder than it sounds and is usually where the surprise lives. Then test each one. Then split the results into what you can fix in your own DNS zone and your own mail server config, which is the HELO hostname and the forward A record, and what needs the IP holder, which is the PTR.
For the second pile, the ask is specific and should be sent as one message per vendor: set the PTR for these IPs to these hostnames on our domain, confirm when done. Vague tickets about deliverability get queued. A named record change on a named IP gets actioned.
Then be honest about what this episode exposed, because the records are the small half of it. A deliverability programme that only monitors what it can publish itself has a blind spot shaped exactly like its vendor boundary. Everything inside the boundary is instrumented and everything outside it is assumed. The guidelines did not create that blind spot. They just picked a month to look into it.
Worth saying plainly: this is a gradual rollout with no published end date, which cuts both ways. There is a real chance your IPs are already compliant, your vendor already configured branded rDNS, and the whole exercise closes in an hour with nothing to do. That is a good outcome and it is also unknowable until you run the check. The asymmetry is what decides it. An hour of testing against an IP-level block on the channel that books your meetings is not a close call.
See where you are cited today
A free snapshot audit of your rankings and AI citations before we ever talk.
Josh leads work at the intersection of SEO and generative engines at Something Inc., helping B2B brands get ranked and cited across every major AI engine.