Spamhaus Now Wants Reverse DNS on Every Sending IP. Here's Who That Catches.

If mail from your office, your website or your own server starts bouncing this winter with a message that names Spamhaus, a new rule may be the reason. Spamhaus lists addresses for many reasons, so read what the bounce says. This rule is new, and it can catch a server that has worked fine for years.

Spamhaus publishes blocklists that many receiving mail servers consult before they accept a message. Its sender guidelines now say that, starting in November 2026, it is gradually rolling out a requirement for every sending IP address to have a valid HELO name, a reverse DNS record, and a forward record that matches. Failing that can get the address listed, and receivers that use the list may then refuse or filter its mail.

The big mail providers handle this for their own servers. The servers that fail tend to be the small ones nobody thinks of as a mail server: the office internet line, the box under the desk, the web host that sends your contact-form mail. This post is what the rule asks, who it catches, how to check your own setup in a couple of minutes, and the two ways to fix it.

What the rule asks

Two checks, both about the machine that connects to deliver your mail, not about your domain's records.

1. The IP's reverse DNS has to point back to it. Every IP address can have a reverse DNS record, a PTR, that names a host. Spamhaus requires that name to exist and to resolve, through an ordinary A or AAAA record, back to the same IP. This round trip is called forward-confirmed reverse DNS. The standard algorithm is short (RFC 8601 §3): look up the names the address maps to, look up the addresses each of those names maps to, and the check passes if the original address is among them.

203.0.113.25        PTR  →  mail.example.com
mail.example.com    A    →  203.0.113.25        passes: the round trip closes

It fails two ways: there's no PTR at all, or the PTR names a host that resolves somewhere else, or nowhere.

2. The HELO name has to resolve to the IP. When a mail server connects, the first thing it does is announce a name for itself with the HELO or EHLO command (RFC 5321 §4.1.1.1). Spamhaus requires that name to resolve to the IP the server is connecting from, and to stay the same across connections from that IP. Placeholders like localhost are out.

Spamhaus recommends, but doesn't require, that the HELO name match the reverse DNS name. In practice, making them the same name is the simplest way to satisfy both checks at once.

This isn't new, it's newly enforced

Neither check is part of the mail protocol itself, and the standards have been lukewarm about them for years. The SMTP standard lets a receiving server check whether the HELO name matches the connecting IP, but says that if the check fails, the server "MUST NOT refuse to accept a message on that basis" (RFC 5321 §4.1.4). The specification that defines the reverse-DNS check notes "some contention regarding the wisdom and reliability of this test", and also that many receivers simply reject connections that fail it (RFC 8601 §3).

So this is a reputation rule, not a protocol one. Spamhaus isn't refusing your mail; it's deciding what goes on its lists, and the receivers that use those lists decide what to do with a listed address. The guidelines say failure "can result in" a listing, and Spamhaus describes the rollout as gradual, so don't expect every failing IP to be listed on the first day. But a listing is what the guidelines describe, and it's the outcome to plan around.

Who it catches

Google Workspace, Microsoft 365 and the large email sending services run their own sending servers, and they control those servers' reverse DNS and HELO names, not you. If all your mail goes out through one of them, this rule is mostly their job. If a bounce from one of their servers names Spamhaus, that's a question for their support.

Our own data fits that picture. In the DMARC reports for the domains we monitor, every message that passed DMARC came from an IP with reverse DNS, and every message from an IP with no reverse DNS at all failed DMARC. The servers missing reverse DNS weren't the ones delivering mail that passed.

The servers that fail are the ones running outside those big providers:

• An office internet line. A static IP from a business internet provider often comes with a generic reverse DNS name, or none. If a server, an on-site mail system, or a device like a scanner sends mail straight out from that line, it's the line's IP the receiver checks.
• A self-hosted mail server. A server on a rented virtual machine or in a rack sends from whatever reverse DNS its provider set up, which is often a generic name based on the IP, and its HELO is whatever the server's hostname happens to be.
• A web host sending your website's mail. Contact forms, order confirmations and password resets from a website are often sent by the web server itself. That server's IP is the one being checked, and on shared hosting you don't control its reverse DNS.
• A vendor's server you listed by hand. If a software vendor once told you to add one of their IP addresses to your SPF record, find out whether that server still sends your mail. If it does, the rule applies to it.

That last group points at the easiest place to start looking: your own SPF record.

Your SPF record is a list of suspects

Your SPF record lists the servers allowed to send mail as your domain. Most entries are include: terms that hand the question to a provider, and a provider's own addresses are the provider's to fix. But an ip4: or ip6: term naming a single address is a server someone wrote down by hand, usually one of the four kinds above.

On the domains we've scanned that list single addresses directly in their own SPF record, roughly two in five list at least one that fails the reverse-DNS round trip.

A listed address isn't proof that it still sends. Either way there's something to do:

• If it still sends your mail, it now needs reverse DNS that points back to it.
• If it doesn't, it shouldn't be in your SPF record at all. An entry for a server you've stopped using still authorizes whoever holds that address next. Spamhaus's own DNS-hygiene guidance asks you to remove records for hosts and IP space you no longer use, and to keep SPF limited to the infrastructure actually in use.

How to check

Your SPF record. Run your domain through dmarc.quest's free check. If your SPF record lists single IP addresses directly, we look up the reverse DNS of each (up to twenty) and flag any that has no PTR, or whose PTR names a host that doesn't resolve back to it. The check stays quiet about any address whose lookups didn't get an answer, so a flag means the DNS actually said no.

A real message. Send a test email from the server you're worried about, whether that's your website's contact form, your office mail system or your own server. We read the message as it arrived and check the two things Spamhaus checks: whether the connecting IP's reverse DNS points back to it, and whether the HELO name the server announced resolves to that IP. Your DNS can't tell anyone which HELO name a server announces, and DMARC reports don't reliably carry it, so a message as it arrived is the place to look. One message can't show whether a server announces the same name every time, so if several machines share an address, test each.

By hand. With dig, the reverse lookup is -x:

$ dig +short -x 203.0.113.25
mail.example.com.
$ dig +short A mail.example.com
203.0.113.25

A second answer that doesn't include the original address means the round trip doesn't close. An empty answer usually means there's no record, but a failed lookup also prints nothing with +short. If you get nothing, run the command again without +short and read the status: line: NXDOMAIN, or NOERROR with no answer, means the record really isn't there; SERVFAIL, REFUSED or a timeout means the lookup failed, and you should try again later.

The HELO name is harder to find by hand. In a message the server sent, as it arrived at the recipient, find the Received: header the recipient's server added for the connection from the sending IP. Header formats vary. The name right after from is often the HELO name, but some servers put the name they got from reverse DNS there instead (or unknown) and record the HELO separately in the parentheses, as helo=mail.example.com or (HELO mail.example.com). So look for a labeled HELO first, in that header or as helo= in a Received-SPF: header the recipient added. Without one, the name after from is probably the HELO name, and a test message to us takes the guesswork out. Then look up that name's A or AAAA record the same way.

Fixing it

If the server still sends: ask the owner of the IP for a PTR record. Reverse DNS isn't in your domain's DNS. The reverse tree is organized by address, so that a zone can be delegated for a block of addresses (RFC 1035 §3.5), and the zone for your IP belongs to whoever holds the block: your internet provider, your hosting company, or the vendor. Some hosting control panels let you set it yourself; for an office line, it's usually a request to the provider's business support.

The usual setup:

1. Pick a name on your own domain for the server, such as mail.example.com, and publish an A (or AAAA) record pointing it at the IP.
2. Ask the IP's owner to set the PTR for that IP to mail.example.com.
3. Configure the server to announce mail.example.com as its HELO name.

Now the PTR, the forward record and the HELO name all agree. Spamhaus recommends a reverse DNS name on your own domain over a provider's generic one, and advises against generic, auto-generated names for dedicated IPs, so step 1 is worth the trouble even where the provider's default name would technically pass.

If the server sends over IPv6, there's one more requirement: Spamhaus says the address must come from an allocation of /64 or larger, with valid reverse DNS. That one is between you and your provider.

On shared web hosting, you can't change the server's reverse DNS or HELO name, but your host can. Ask them to fix it for their sending server. If they can't or won't, send the website's mail through your email provider or a sending service instead of from the web server directly. Once you've confirmed nothing still sends from the web server, remove its IP from your SPF record.

If the server doesn't send any more: remove it from SPF. Delete the term that lists it, such as ip4:203.0.113.25 (or +ip4:203.0.113.25). Leave alone any term starting with -, ~ or ?: those don't allow the address, and because SPF stops at the first term that matches, deleting one could let a later term allow it. Then check that nothing else in the record still covers the address, such as an a or mx term or a wider range. Once your SPF record stops vouching for an address you don't use, its reverse DNS can't affect your mail.

What this doesn't tell you

A passing round trip and a good HELO name are two items on Spamhaus's list of minimum requirements, not the whole list. Its guidelines also cover consent, bounce rates, authentication and more, and an IP can be listed for reasons that have nothing to do with DNS. We don't check Spamhaus's lists, and nothing on dmarc.quest says whether an address is listed; Spamhaus's own website has a lookup for that.

Our SPF check also sees only what's written in your record: single addresses listed directly. It doesn't check address ranges, or the servers behind an include:, which belong to the provider.

See your own setup

Check your domain to see whether your SPF record lists an address that fails the round trip, and send a test email from any server you're unsure about to see the reverse DNS and HELO name a receiver sees. Both are free and need no sign-up.