Spamhaus's New Reverse DNS Rule: We Checked 11,846 Sending IPs Before It Goes Live

Spamhaus is introducing a requirement that every IP sending email has a valid HELO name, a reverse DNS (PTR) record, and a forward DNS record pointing back to the same IP address. Enforcement begins gradually in November 2026, and IPs that don’t comply can be listed.

I wanted to know how many legitimate senders this would catch, so we ran the check on our own DMARC data that's fed by hundreds of companies: every IP that sent authenticated mail for our clients' domains over the last 30 days.

99.74% of those IPs already pass. Among the IPs sending spoofed mail as the same domains, 81% fail. Most of the legitimate IPs that fail sit on small hosting providers and office internet lines, and almost half of them belong to Microsoft 365.

What Spamhaus requires

Spamhaus's Sender Guidelines list three DNS requirements for every sending IP:

1. A PTR record that resolves to a fully qualified hostname, such as mail.example.com.
2. Forward confirmation (FCrDNS), meaning that hostname resolves back to the same IP through an A or AAAA record.
3. A HELO name that resolves to the sending IP and stays the same across connections.

IPs that fail can be listed on the Combined Spam Sources (CSS) or Exploits (XBL) lists. Both are part of Spamhaus ZEN, which many receiving mail servers check on every incoming connection.

Spamhaus also discourages generic, auto-generated PTR names on dedicated IPs, like ec2-203-0-113-25... or static-203-0-113-25.hosting.example.net, and asks IPv6 senders to use an allocation of /64 or larger with valid reverse DNS. These have been standard mail server practices for years, and from November 2026 Spamhaus enforces them.

What we checked

We provide free DMARC monitoring to our clients, so we receive aggregate (RUA) reports from dozens of mailbox providers and security email gateways. Each report lists the IPs that sent mail as a client's domain and whether that mail passed authentication.

We took 30 days of these reports and kept only mail that passed DMARC-aligned DKIM or SPF. That gave us 11,846 publicly routed sending IPs (9,016 IPv4 and 2,830 IPv6), 13.97 million messages, and 494 client domains.

For each IP we looked up the PTR record, checked that it was a valid hostname that resolved back to the same IP, flagged generic provider-default names, and mapped the IP to the network that owns it.

Results

31 of the 11,846 legitimate IPs (0.26%) fail forward-confirmed reverse DNS. Together they sent 3,262 messages, or 0.023% of legitimate volume. 20 had no PTR record at all, and 11 had a PTR whose hostname didn't resolve back to the IP.

Another 17 IPs pass but use generic PTR names. All of them are on hosting and VPS providers such as OVH, GMO, pair Networks, Hivelocity and AWS EC2.

We recalculated the failure rate five different ways, including counting DNS errors as failures, excluding forwarded mail, and dropping IPs that sent only one message. It stayed between 0.18% and 0.28%.

The same reports showed 18,619 IPs sending mail that failed both SPF and DKIM, most of it spoofing. 81% of those IPs fail FCrDNS, and more than half have no PTR record at all. If your mail goes out through a major provider, the reverse DNS part of this rule is very unlikely to affect you.

Almost half of the failures are Microsoft 365

15 of the 31 failing IPs belong to Microsoft, and 14 of them are inside the ranges Microsoft publishes in its own SPF record for Microsoft 365 (40.92.0.0/15 and 2a01:111:f403:c000::/51). They carried 76% of the failing legitimate mail and account for 123 of the 137 client domains that had any legitimate mail from a failing IP.

On October 27 we checked all 15 again, in two rounds, against four public resolvers (Cloudflare, Google, Quad9 and OpenDNS) and against Microsoft's own authoritative name servers for each reverse zone.

• 13 IPs still have no PTR record. All of them are inside Microsoft's current published ranges, and Microsoft's authoritative servers return "non-existent domain" for every one.
• 2a01:111:f403:c206::1 now has a PTR (mail-ukwestazlp170100001.outbound.protection.outlook.com) that forward-confirms. On October 23 it had none.
• 2a01:111:f403:e000:: has no PTR either, but it's no longer in Microsoft's SPF, so we excluded it.

Spamhaus's DNS checker shows the same thing for 2a01:111:f403:c000::1 and 40.93.1.7: no PTR record and a failed reverse DNS check.

These 13 IPs are a small share of the nearly 9,000 Microsoft IPs in our data, and they carried about 2,400 of the 1.75 million Microsoft messages. Almost all of that went through 2a01:111:f403:c000::1, which Google and Microsoft's enterprise reporting both saw sending DKIM-signed mail for more than 100 of our clients' domains.

Microsoft 365 customers can't fix this themselves, because only the owner of an IP can set its PTR record. Microsoft can, and the IP that gained a PTR between our two checks shows these records do get added.

Who else fails

Outside Microsoft, most failures came from servers that someone set up and configured by hand.

On small hosting providers such as DataBank, InMotion Hosting, Unified Layer and StormWeb, servers had either no PTR or one that didn't resolve back. These are usually websites or apps sending mail straight from the web server.

On business internet lines, the typical case is a mail server in an office sending through the ISP's connection. The ISP controls reverse DNS for those IPs, and nobody had asked it to set a record.

Two dedicated SendGrid IPs had branded reverse DNS pointing to the client's own domain, but the A record behind it had been deleted, so the PTR now points to a hostname that doesn't exist.

Only 14 of 494 domains (2.8%) had legitimate mail from a failing IP outside the large providers, and usually it was a small share of their mail. Just 3 domains had more than 10% of their legitimate volume on a failing IP, and none had more than half. In practice, that's the contact form on a website, an invoicing app on a VPS, or an office scanner that emails PDFs.

HELO isn't covered by our data

DMARC reports don't include the HELO name, so this research covers two of Spamhaus's three requirements.

HELO is where self-hosted servers most often go wrong. Common problems are a server announcing itself as localhost or by its internal machine name, using the hosting provider's default hostname instead of your own domain, a HELO name that doesn't resolve or resolves to a different IP, and several servers behind one IP announcing different names.

We found 88 legitimate IPs that look like self-hosted mail servers. Two of them failed reverse DNS, but we can't tell from DMARC data how many would fail on HELO. If you run your own server, step 4 below takes a couple of minutes.

How to check your own setup

1. List everything that sends mail as your domain

That means your email platform, but also website forms, CRMs, billing tools, servers and office devices. DMARC reports are the quickest way to find them.

2. Set aside the large providers

Google Workspace, Microsoft 365, SendGrid, Mailchimp, Amazon SES and similar providers manage reverse DNS for their IPs. If you have a dedicated IP with branded reverse DNS, check that the A record behind it still exists.

3. Check the PTR and forward record

For every other system, run:

dig -x 203.0.113.25 +short
# returns e.g. mail.example.com.

dig A mail.example.com +short
# must return 203.0.113.25

If the first command returns nothing, there's no PTR. If the second returns a different IP, forward confirmation fails. Reverse DNS is set by whoever owns the IP, which usually means your hosting provider or ISP.

4. Check your HELO

Send an email from the server to a Gmail address and open Show original. The first Received: line looks like this:

Received: from mail.example.com (mail.example.com. [203.0.113.25])

The first hostname is your HELO and the one in brackets is your PTR. They should match, and both should resolve to the sending IP. You can also send a message from the server to helocheck@abuseat.org, which replies with the HELO it saw.

5. Run the IP through Spamhaus's tools

The DNS checker on the guidelines page tests HELO, PTR and FCrDNS together. The Reputation Checker shows whether the IP is already listed.

Methodology and limits

We used 30 days of DMARC aggregate reports for the domains we monitor, with duplicate reports removed. An IP counts as legitimate if it sent at least one message that passed DMARC-aligned DKIM or SPF.

We excluded 152 IPs with no public route, mostly internal Microsoft hops reported by Microsoft itself, because they can't be reached from the internet. Each IP was checked once, with retries on timeouts, and lookups that still errored are reported separately rather than counted as failures. The Microsoft IPs were re-checked on October 27 against four public resolvers and Microsoft's authoritative name servers.

Network owners were mapped by ASN and then split using providers' published sending ranges, for example Microsoft 365 versus Azure, or Google Workspace versus Google Cloud.

There are limits to what this data shows:

• HELO isn't covered, as explained above.
• Domains under DMARC monitoring tend to be better configured than average. Cold email operations and abandoned servers, the senders most likely to fail, are underrepresented here.
• Google sent 70% of the reported volume, Yahoo 17% and Outlook.com 8%. Receivers that don't send DMARC reports aren't visible to us.
• DNS was checked up to 30 days after the mail was sent, so some records may have changed in between.

Sources: Spamhaus Sender Guidelines · SH Consulting DMARC aggregate data, September–October 2026.