Spamhaus has not published a specific enforcement date for its DNS check. The Sender Guidelines page announces a gradual rollout starting in November 2026 (page viewed on October 27, 2026). Every sending IP must present a valid HELO and a matching PTR/A pair, or risk being listed in the CSS or XBL zones.
CRM teams know the symptom: “my emailing tool says everything is fine,” and yet campaigns land in spam. A DNS defect on the sending IP is enough to trigger a listing, and the tool’s interface won’t necessarily tell you about it.
What Spamhaus announces and what it leaves unsaid
According to the Spamhaus sender guidelines, Spamhaus is gradually rolling out the requirement of a valid HELO and a PTR with its matching A record for every sending IP.
The pages I reviewed give neither a phased schedule nor details of the penalty. The only consequence named is a listing on the CSS (Combined Spam Sources) or on the XBL, the list of compromised IPs. No new standard appears in these pages. For background on the organization and its zones, see our overview of Spamhaus.
One limit to keep in mind: the check tool’s pages state that results are not available for every IP and may not reflect recent changes. Rerun a passing test after every DNS change.
Google and Yahoo have required authentication from senders of more than 5,000 messages per day since February 2024. Microsoft announced similar rules for Outlook.com on April 2, 2025, enforced since May 5, 2025. Spamhaus adds a check at the IP-list level.
HELO: the name your server gives when it introduces itself
A freshly rented sending server introduces itself with the hostname supplied by the host, something like vps-4821.hosting.example (never the sender’s domain name), as long as nobody touches the EHLO command. In Postfix 3.x, the smtp_helo_name parameter in main.cf sets this name and defaults to the value of myhostname. Spamhaus rules out exactly this kind of name.
Section 4.1.1.1 of RFC 5321 (2008) requires the EHLO argument to be the fully qualified domain name of the SMTP client when one exists. Spamhaus reads it more strictly: that name must resolve to the connecting IP. It prohibits localhost and generic names from the host or the access provider. A name pointing to infrastructure that plays no role in sending is rejected, and so is imitating the HELO of a mailbox provider such as Gmail or Hotmail.
Consistency matters as much as the name. According to the guidelines, multiple HELO values resolving to different IPs point to residential proxy or malware activity. A fleet of hand-configured relays, each with its own name, can fall into that category without anyone intending it.
Spamhaus also recommends aligning the HELO with the reverse DNS name and publishing a web page on that domain explaining what the server is used for.
PTR and A record: closing the loop
The check follows a round trip. The sending IP has a PTR pointing to a fully qualified name. That name has an A record (AAAA in IPv6) that points back to the same IP. The announced HELO reuses that name. This is called forward-confirmed reverse DNS (FCrDNS).
The check.spamhaus.org tool (IP & Domain Reputation Checker module) returns three verdicts: “HELO Resolution,” “PTR Record,” and “PTR Resolution.” According to the troubleshooting page, a red cross means a delisting request is unlikely to succeed. The Gmail 550 5.7.25 rejection tied to the PTR is covered in our article on SMTP error 550 5.7.25.
Testing the loop before November
Two dig queries (bind9-dnsutils package on Debian 12) reproduce the check. For a sending IP of 203.0.113.25 (a documentation address), the command dig -x 203.0.113.25 +short returns the PTR, for example mail.example.com. The command dig +short A mail.example.com must then return 203.0.113.25, and the SMTP session must announce mail.example.com in the EHLO.
To check the HELO actually used in production, Spamhaus mentions the address helocheck@abuseat.org, inherited from the CBL (Composite Blocking List), whose data feeds the XBL.
Who owns these records on your setup?
It depends on how you send. On a shared IP pool at a provider (Twilio SendGrid, Mailjet, or Brevo, for example), HELO, PTR, and A are the provider’s responsibility. You can’t change anything there. Your leverage is limited to requesting compliance in writing and monitoring the sender reputation and complaint rate of your sends.
On a dedicated IP or your own server, everything is yours. The PTR is set with the holder of the address block, usually the host (OVHcloud, Hetzner, or Scaleway, for example), through its customer area or a ticket. The A record and the HELO are set on your side: the DNS zone on one hand, the SMTP server configuration on the other.
Spamhaus advises against leaving the auto-generated reverse DNS in the host’s name on a dedicated IP. It recommends a name on the sender’s domain. For IPv6, the page also requires an allocation of at least a /64 with valid reverse DNS, as summarized in the minimum requirements section. The choice between dedicated and shared IPs is covered in the article dedicated vs. shared IP. The PTR mechanism has its own page: the reverse DNS lookup.
Does compliant DNS protect you from being listed?
No. Spamhaus’s minimum requirements are a list of five points that opens with confirmed opt-in and cites purchased or rented lists as a frequent source of spam traps. Reverse DNS comes second, HELO third, IPv6 fourth, and SPF, DKIM, and DMARC fifth.
Clean DNS won’t protect you from a stale database: by the time a hard bounce comes back, it has already been counted against the sending IP. An IP with flawless DNS that writes to dead addresses piles up those bounces like any other. On the Gmail side, Google’s help page asks you to stay under a 0.10% complaint rate in Postmaster Tools and to avoid reaching 0.30%. The other lists worth monitoring besides Spamhaus are reviewed in email blocklists: which ones to really monitor in 2026.
Before your next campaign, run a sample of your list through an address verifier to measure its hard bounce rate, then open check.spamhaus.org with your sending IP.
