Spamhaus has started rolling out a requirement that every IP sending mail has three things: a valid HELO name, a reverse DNS (PTR) record, and an A record that points the PTR's hostname back at the same IP. Its Sender Guidelines spell out the cost of missing them: "Failure to do so can result in IPs being listed on the Email Spam IPs (CSS) or compromised IPs (XBL) zones." Both zones are part of ZEN, the combined Spamhaus list that many receivers reject on during the SMTP conversation. A listing there bounces your mail at every one of them at once.
What Spamhaus Announced
The details came in a Spamhaus blog post on October 21: "Starting in November 2026, we're gradually rolling out enforcement of basic DNS requirements over several months." That's all the timing there is. Spamhaus hasn't published a date for individual senders or said how listings will be applied while the rollout runs, so the safe reading is that any of your IPs could be checked starting this month.
The three requirements, as the guidelines state them:
| Requirement | What Spamhaus asks for | Who sets it |
|---|---|---|
| HELO / EHLO | The hostname your server announces resolves to the IP it connects from, and stays the same on every connection from that IP | Your MTA config |
| Reverse DNS (PTR) | The sending IP has a PTR record pointing to a fully qualified hostname | Whoever controls the IP block |
| Matching A record | That hostname resolves back to the same sending IP | Your DNS |
The last two together are forward-confirmed reverse DNS, or FCrDNS. Receivers have checked all of this for years, and our post on reverse DNS for mail servers covers how the lookups work. What's changed is the penalty. A gap that used to cost a few points in one receiver's spam score can now put the IP on a list that receivers all over the internet query.
The guidelines also name the values that count against you: placeholder HELOs such as localhost, hosting-provider default hostnames in either the HELO or the PTR, a HELO that resolves to infrastructure that doesn't send mail, and any HELO impersonating a mailbox provider like Gmail or Hotmail.
Who This Catches
If your mail goes out through Google Workspace, Microsoft 365 or a major email service provider, the provider owns the sending IPs and already gets HELO and reverse DNS right. The exposure is mail that leaves from your own IPs, and it's usually the box nobody thinks of as a mail server:
| Sender | How it typically fails |
|---|---|
| A new VPS or cloud instance running Postfix or Exim | Provider's default PTR, like 203-0-113-25.static.hosting.example.net |
| A web server sending password resets and receipts | HELO of localhost.localdomain or a short hostname that doesn't resolve |
| A printer, scanner or appliance relaying straight out | No PTR at all, and a HELO that's a bare IP |
| An app server whose DNS was migrated | PTR names a host whose A record now points somewhere else |
| Several servers sharing one NAT address | Each announces its own HELO, so the name changes between connections from the same IP |
That last one surprises people. Spamhaus calls HELO values that vary from one connection to the next a sign of misconfiguration or compromise, which is exactly what the XBL exists to list.
Check Your Sending IPs
Spamhaus has a HELO and DNS checker at the top of the Sender Guidelines page: enter the sending IP and it checks the HELO and DNS setup against the guidelines. Spamhaus notes that results aren't available for every IP. You can also send a message from the server to helocheck@abuseat.org to see the HELO it uses.
Or mail yourself at an outside mailbox and read the top Received: header. Postfix and most other MTAs record the HELO first, then the PTR and IP in brackets, so one line shows both halves of the problem:
Received: from localhost.localdomain (203-0-113-25.static.hosting.example.net [203.0.113.25])
by mx.example.org (Postfix) with ESMTPS id 4XkP2r1QbZz9t
for <you@example.org>; Mon, 2 Nov 2026 09:14:02 -0500 (EST)
A placeholder HELO and a generic PTR: that server fails twice.
For the reverse DNS half, two lookups. The PTR first, then the A record for whatever name comes back:
$ dig +short -x 203.0.113.25
mail.example.com.
$ dig +short A mail.example.com
203.0.113.25
That one passes. These don't:
# no PTR at all
$ dig +short -x 198.51.100.40
$
# a PTR, but the provider's generic name
$ dig +short -x 192.0.2.77
192-0-2-77.static.hosting.example.net.
# a custom PTR whose name points at a different IP
$ dig +short -x 203.0.113.60
mail.example.com.
$ dig +short A mail.example.com
203.0.113.25
Run them from outside your network, or with a DNS lookup tool that queries PTR directly, since a local resolver can hand you a cached answer that the rest of the internet no longer sees.
Then check what the MTA announces. On Postfix the HELO is smtp_helo_name, which defaults to myhostname:
$ postconf myhostname smtp_helo_name
myhostname = localhost.localdomain
smtp_helo_name = $myhostname
That server says hello as localhost.localdomain, which fails on its own. On Exim, exim -bP primary_hostname shows the default, and a helo_data option on the outbound smtp transport overrides it.
Fixing It
Pick one fully qualified name under a domain you control, such as mail.example.com, and make all three records agree on it. Order matters:
- Create the A record (AAAA for IPv6) pointing the name at the sending IP. Some providers check for it before they'll set a PTR; Akamai's Linode Cloud Manager returns an error without it.
- Set the PTR. The IP's owner controls it: on a cloud instance or VPS it's usually a reverse DNS field on the IP in the provider's console; for an ISP or colo block it's a support request.
- Set the HELO to the same name.
- Re-run the checks from step one.
For Postfix, in /etc/postfix/main.cf, then postfix reload:
myhostname = mail.example.com
smtp_helo_name = $myhostname
For Exim, in the main section of the configuration:
primary_hostname = mail.example.com
The smtp transport's helo_data defaults to $primary_hostname, so if yours sets it explicitly, change it to the same name.
Servers sharing a NAT address need one name between them: either send everything through a single relay, or set every server's HELO to the hostname the shared IP's PTR names. Spamhaus also recommends putting a web page on the HELO domain that says what it's for, or redirects to your main site.
If an IP already got listed, fix the records first and then use the removal process for the zone it's on. Our walkthrough on reading a Spamhaus listing maps each return code to the zone and who files the removal.
Keeping It Fixed
Getting the three records to agree is a one-afternoon job. Keeping them that way is harder, because reverse DNS breaks without anyone touching the mail server: an instance gets rebuilt on a new IP and comes up with the provider's default PTR, a DNS migration moves the A record, a provider renumbers a block. The first sign is usually a bounce.
Generator Labs Blacklist Monitoring includes four email deliverability checks for IPv4 and IPv6 hosts on every plan: Reverse DNS, Forward-Confirmed Reverse DNS, Generic PTR Pattern and PTR Hostname Format. Turn them on in a monitoring profile for your sending IPs and you'll get an alert when a PTR disappears, stops resolving back, or reverts to a provider default, alongside an alert for the Spamhaus listing itself. The free plan covers one IP with no time limit.