Published 23 October 2026 · By Bram Van Daele, Teneo
On 21 October 2026 Spamhaus published its Sender Guidelines and, in a box at the top, a date: from November 2026 every IP that sends mail must present a valid HELO, a PTR record and a matching A record, or risk a listing. This guide quotes what Spamhaus wrote, shows the three names in a Received line that have to agree, lists the server defaults that break the rule, and ends with the five-minute check we ran on our own relay.
Spamhaus has answered "what do I need to do to stay off your lists" in FAQs, blog posts and support tickets for twenty years. On 21 October 2026 it put the answer on two pages, called them the Sender Guidelines, and added a sentence that turns a long-standing recommendation into a requirement with a date:
"Starting in November 2026, we are gradually rolling out a requirement for every sending IP to have a valid HELO, a reverse DNS (PTR) record, and a matching A record. Use the HELO checker below to see whether the DNS meets our best practices, and follow the guidelines to avoid being listed."
The announcement post that went with it is plainer still about why: "DNS is kind of our thing. It's also the other most common reason for listings, usually because of an invalid HELO, no reverse DNS (PTR) record, or no matching A record." The other reason is lack of permission. This guide is about the DNS one, because that is the one a mail admin can fix in an afternoon.
What Spamhaus now requires
The requirement has three parts, and the guidelines page states each of them as a minimum requirement rather than a recommendation.
- A PTR record that confirms forward. "Every sending IP must have a reverse DNS entry pointing to a fully qualified domain name (FQDN). That hostname must, in turn, resolve back to the same sending IP address." Spamhaus calls this forward-confirmed reverse DNS, and adds that an IP "with missing or mismatched reverse DNS is treated as suspicious and is one of the most common reasons for an IP to be considered for listing."
- A HELO that resolves to the connecting IP. "The hostname the server announces in the HELO/EHLO command must resolve to the IP it is connecting from, and must stay consistent across connections from that IP." The page names what fails: "Placeholder values, hosting-provider defaults, and hostnames that vary between connections are treated as signals of misconfiguration or compromise and can result in a listing."
- An A record on that hostname pointing at the IP. This is the forward half of both checks above. Without it the PTR is not confirmed and the HELO does not resolve.
The consequence is spelled out in the introduction to the infrastructure section: "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 list most receivers query, so a CSS listing on a sending IP means deferrals or rejections at every receiver that uses it. CSS listings "expire quickly: normally, three days after last spam detection", and the troubleshooting rules for the reputation checker say that while any of the HELO or PTR checks shows a red cross, "any request for removal is likely to be unsuccessful."
What Spamhaus has not published: a start day in November, an end date, or which of the three checks comes first. The only phasing language is "gradually rolling out enforcement of basic DNS requirements over several months." We read that as: do not plan around a grace period, because none is written down.
Three names, one Received line
Everything Spamhaus asks for is visible in the first Received header of any message your server delivers. Here is one from our own logs, written by our mail server when one of our relay IPs delivered to it:
Received: from mta094.teneo.be (mta094.teneo.be [195.137.243.113])
by mail.teneo.be ...Three things stand in that line. The first name, mta094.teneo.be, is what our server said in its EHLO command. The name in parentheses is what the receiving server found when it looked up the PTR record of the connecting IP. The address in square brackets is the connecting IP itself. Spamhaus's rule, reduced to one sentence: the first two names must be the same, and that name must have an A record pointing at the address in brackets.
The guidelines page lists the HELO and PTR match itself under "Recommended" rather than "Required", with the words "Where possible, ensure the HELO/EHLO hostname is consistent with the rDNS hostname." The practical bar is stricter. The resolution steps Spamhaus published for its reputation checker in December 2025 say "The reverse DNS record must match the HELO domain", and its ESP guidelines say "Make sure the HELO, PTR and A record all use the same hostname." Since the checker is what decides whether a delisting request goes through, we treat the match as required.
Two more lines from the guidelines matter for anyone who runs more than one sending host. First, SPF: "Make sure both the HELO domain and the envelope From domain have a valid SPF record." The HELO hostname needs its own SPF record, separate from the one on your sending domain. Second, history: "HELO domains which DO NOT have a sending history will be subjected to additional filtering", and the recommendation is to "Treat any change in IP or HELO hostname as a new asset". Renaming a mail host is not free.
The defaults that break it
Almost nobody sets a HELO to "localhost" on purpose. The problem is what servers announce when nobody sets it at all. The cases below are documented in public threads and vendor pages, with dates, because each of them is a default that keeps recurring.
- Cloud VMs with the provider's name. Hetzner's documentation gives its default reverse name as
static.1.113.0.203.clients.your-server.de, and Spamhaus's own example of a bad PTR,static-203-0-113-25.hosting.example.net, is the same pattern. In May 2023 the Redmine project traced its own refused notifications to a server announcing HELOUbuntu-2004-focal-64-minimalunder exactly such a PTR. OVH customers report rejections for HELO values ending in.HOMEand for PTRs left underovh.net. On Azure the situation is simpler and worse: Microsoft's documentation states "Reverse DNS is an opt-in feature", so a VM that nobody configured has no PTR at all and fails the second requirement outright. - Docker containers. A container's hostname is its container id. A 2020 Ubuntu bug report describes Postfix installed in one: "The hostname is just 'cc1a572af0dc' without domain. It is set by docker." Postfix derives its HELO from that hostname unless told otherwise.
- Exchange and other servers with internal names. A send connector that still carries the server's Active Directory name announces
something.localto the internet, a name that cannot resolve anywhere. The fix is the connector's FQDN, set to the public name that the PTR also carries. - The classic three. Spamhaus's FAQ lists the misconfigurations it sees most: "'localhost.localdomain', 'WIN-XYZPDQ01' or 'mail'." In May 2023 an MDaemon operator found their IP on CSS for a HELO of
localhost.localdomain; the device sending it turned out to be another machine on the same LAN, not the mail server at all. A single NAT address carries the HELO of every device behind it. - Shared hosting panels. A February 2024 Plesk thread shows the Spamhaus checker reporting "The observed HELO value(s) were: srv2921.sd-france.net", the hosting provider's name for a customer's server. The fix was a panel setting, sending from the domain's own IP with its own name, and Spamhaus removed the IP from CSS once it took effect.
The common thread is that the HELO is never wrong in the sender's own mail logs, because the sender's own logs do not show it. It shows up at the receiver, in the Received line, or in a listing.
The five-minute check
For every IP your mail leaves from, three lookups and one header:
# 1. the PTR of the sending IP
dig -x 203.0.113.25 +short
# expect: mta1.example.com.
# 2. the A record of the name that came back (forward confirmation)
dig A mta1.example.com +short
# expect: 203.0.113.25
# 3. the SPF record on that hostname (Spamhaus lists this as Required)
dig TXT mta1.example.com +short
# expect: "v=spf1 ... -all"The fourth check is the HELO itself, and it cannot be done from the outside with a DNS lookup. The port 25 banner is not it either; Spamhaus's XBL FAQ says so in as many words: "Telnet to port 25 on the mail server shows the 'banner', not the HELO." Three ways that work:
- Send a message from the server to a mailbox you control and read the first Received line, as in the example above. Gmail's "Show original" displays it.
- Send a message to
helocheck@abuseat.org. The guidelines page offers this address; the bounce that comes back contains the HELO the server used. Spamhaus notes it "does not work with IPv6 at this time." - Enter the IP in the HELO/DNS checker at the top of the Spamhaus guidelines page, with the caveat Spamhaus attaches: "results are not available for all IPs and may not reflect recent changes."
Where the HELO is set depends on the MTA. In Postfix the parameter is smtp_helo_name, which defaults to $myhostname; for a server with several sending IPs the documentation shows one transport per IP in master.cf with -o smtp_bind_address and -o smtp_helo_name set together. In GreenArrow Engine each IP is declared as smtp_source ip hostname, described in its configuration reference as "The IP address and hostname to use for outgoing SMTP connections on this IP address", and the page on adding an IP says the hostname "must match the reverse DNS record that you created above." PowerMTA's user guide pairs the two in the same way, with smtp-source-host IP HOST-NAME inside a VirtualMTA block. In all three the principle is the same: the IP and the name it announces are configured as one pair, and the PTR for that IP carries the same name.
If you send through a relay
If your application or office server hands mail to a relay on port 587 and the relay delivers it, the IP that Spamhaus sees is the relay's, and so is the HELO. Your own server's EHLO on the submission connection is between you and the relay, and it does not have to be a public name. We see this in our own logs every day: a customer's office connection announces a bare machine name when it submits, and that is fine, because the connection that reaches the mailbox provider starts at our server, with our name.
What that means in practice is that the three checks above are your relay provider's to pass, and you are entitled to ask. The questions are short: does every sending IP have its own hostname; does the PTR of each IP confirm forward; does the HELO equal the PTR; does the hostname carry an SPF record; and is the name in a domain the provider controls, on address space the provider controls. A provider that cannot answer in a minute has not looked.
What we found on our own relay
We ran the check on every IP our relay sends from this week, with a public resolver rather than our own, so that we would see what a receiver sees.
- Every sending IP has a PTR of the form
mtaNNN.teneo.be, one name per IP, and every one of those names has an A record pointing back at its IP. - In every Received line we sampled from mail our relay delivered, the HELO name and the PTR name are the same.
- Every
mtaNNN.teneo.behostname publishes its own SPF record with a hard fail, separate from the record on teneo.be. - The names are in our own domain, on address space we have held since 2009, so there is no hosting provider's default anywhere in the chain to drift back.
We did not find anything to fix, which is the result we expected and the reason we are comfortable writing about it. The setup is not clever. It is the configuration our MTA vendor's documentation describes for every IP, applied every time an IP was added, and left alone since.
Where this sits against the RFC and the mailbox providers
The SMTP standard is more lenient than Spamhaus. RFC 5321 allows a server to verify that the EHLO name "actually corresponds to the IP address of the client", and then says: "if the verification fails, the server MUST NOT refuse to accept a message on that basis." Spamhaus is not an SMTP server and a listing is not a refusal on that basis, but for a sender whose IP lands on ZEN the distinction is academic. The RFC describes what a receiver may do with one message; Spamhaus describes what it does with an IP's reputation.
The large mailbox providers already require most of this. Google's sender guidelines, in force since February 2024, require that "The sending IP address must match the IP address of the hostname specified in the Pointer (PTR) record." Yahoo asks senders to "Have a valid forward and reverse DNS record for your sending IPs." Microsoft's Outlook.com policies, effective 5 May 2025, say "Email servers must have valid reverse DNS records." None of the three mentions HELO. M3AAWG's Sender Best Common Practices, updated in August 2026, do: "In dedicated (unshared) IP environments, the HELO must exactly match the primary forward DNS name." Spamhaus is the first of the big names to put a date on the HELO check and a listing behind it.
One sentence from Microsoft's own documentation is worth keeping in mind as enforcement starts. Explaining why Microsoft 365 mail is sometimes refused by receivers that check HELO against PTR, Microsoft writes that its servers' HELO strings "have A records that contain some outgoing IP addresses that correspond to the sending mail servers. However, the A records don't contain all these outgoing IP addresses." How Spamhaus applies a per-IP rule to senders built that way is a question we expect to hear at the M3AAWG meeting in the last week of October, where Spamhaus has said it wants feedback.
For everyone else, the rule is three DNS records and one configuration line per IP, and a Received header to prove it. If yours already agree, nothing changes in November. If they do not, you have the rest of October, and the fix costs nothing but a careful look at a header you have probably never read.
Sending through Teneo? The HELO, PTR, A and SPF checks above are ours to pass, on every IP, and we have. Your application can keep announcing whatever it likes on port 587.
Frequently asked questions
Does Spamhaus require the HELO to be identical to the PTR?
The guidelines page lists the match as recommended, "where possible". The resolution steps for the Spamhaus reputation checker, published December 2025, require it: "The reverse DNS record must match the HELO domain", and while a check fails "any request for removal is likely to be unsuccessful." Treat the match as required.
Which list does a bad HELO put me on, and for how long?
Spamhaus names CSS and XBL. CSS listings "expire quickly: normally, three days after last spam detection", longer in cases of chronic abuse. Both zones are part of ZEN, so a listing is seen by every receiver that queries ZEN.
I send through a relay. Does my own server's HELO matter?
Not to Spamhaus. The connection that reaches the mailbox provider starts at the relay, so the relay's IP, HELO, PTR and A record are judged. Your server's EHLO on port 587 is seen only by the relay.
Can the HELO be an IP address instead of a hostname?
RFC 5321 allows an address literal when no meaningful domain name is available, but Spamhaus's receiver documentation states that "no valid HELO string can be in the form of an IP address", and the guidelines ask for a fully qualified domain name that resolves to the connecting IP. Use the hostname.
How do I see which HELO my server sends?
Not from the port 25 banner, which is a different string. Send a message to a mailbox you control and read the first Received line, mail helocheck@abuseat.org and read the bounce, or enter the IP in the HELO/DNS checker on the Spamhaus guidelines page.
Sources: Spamhaus Sender Guidelines and ESP & Large Sender Guidelines (October 2026), the Spamhaus announcement post of 21 October 2026, the Spamhaus CSS and XBL pages, the Spamhaus marketing-email FAQ, the reputation checker troubleshooting article (17 December 2025) and the Spamhaus Technology SMTP checks documentation; RFC 5321; Google's email sender guidelines; Yahoo Sender Hub best practices; Microsoft Outlook.com postmaster policies (5 May 2025) and Microsoft KB 3019655; M3AAWG Sender Best Common Practices v4.0 (August 2026); Postfix postconf(5); GreenArrow Engine configuration documentation; the PowerMTA 5.0 user's guide; Hetzner, OVHcloud, AWS and Azure DNS documentation; public threads on the Redmine tracker (2023), OVHcloud community (2023-2024), Launchpad (2020), the MDaemon forum (2023) and the Plesk forum (2024). Teneo observations are from our own DNS checks and delivery headers, October 2026. No private communications were used.