---
title: "Spamhaus Sender Guidelines: HELO, PTR & DMARC Checklist"
description: "Spamhaus starts enforcing HELO, PTR and FCrDNS on every sending IP in November 2026. Here’s the checklist and the dig commands to verify your setup."
url: "https://digitaldomination.xyz/en/blog/spamhaus-sender-guidelines-helo-ptr-dns-checklist-november-2026"
language: en-US
alternates:
  en-US: "https://digitaldomination.xyz/en/blog/spamhaus-sender-guidelines-helo-ptr-dns-checklist-november-2026"
  de-DE: "https://digitaldomination.xyz/blog/spamhaus-sender-richtlinien-checkliste-helo-ptr-fcrdns"
  x-default: "https://digitaldomination.xyz/blog/spamhaus-sender-richtlinien-checkliste-helo-ptr-fcrdns"
image: "https://digitaldomination.xyz/assets/images/og-image.en.png"
organization:
  name: Digital Domination
  telephone: "+49 1577 5527800"
  email: "hey@digitaldomination.xyz"
  address: "523 Jackson Street, Unit #210, Saint Paul, Minnesota 55101, US"
---

Spamhaus email deliverability DNS DMARC sender guidelines

# Spamhaus starts enforcing sender DNS rules in November 2026: The HELO, PTR and DMARC hygiene checklist

The HELO, PTR and FCrDNS requirements, the dig commands that verify them, and the checklist to finish before the first enforcement bot arrives.

![Alexander Kirsch-Clayton](https://digitaldomination.xyz/assets/images/alexander.webp) By [Alexander Kirsch-Clayton](https://www.linkedin.com/in/alexanderkc/), Founder November 2, 2026 ·9 min read [Digital Domination on LinkedIn](https://www.linkedin.com/company/digidomination/) [Digital Domination on GitHub](https://github.com/digidomination)

Starting in November 2026, Spamhaus begins enforcing basic DNS requirements on every sending IP—a valid HELO/EHLO hostname, a PTR record, and matching forward-confirmed reverse DNS. The announcement went up on October 21, 2026, and the rollout runs over several months. This post is the checklist, the dig commands, and the five-minute check.

The one-sentence answer: starting in November 2026, Spamhaus enforces basic DNS requirements on every sending IP—a valid HELO/EHLO hostname, a PTR record, and matching forward-confirmed reverse DNS; a single missing or mismatched record is enough to get a server listed on the CSS or XBL blocklist, and the mail then disappears into recipients’ spam folders or is silently rejected.

## What did Spamhaus change, and when does enforcement start?

Spamhaus announced on October 21, 2026 that it will gradually enforce a set of basic DNS requirements on every sending IP over the following months, with failures landing IPs on its CSS or XBL blocklists.

The announcement, published on the Spamhaus Resource Hub, is short and blunt: “Spamhaus will require a valid HELO, a reverse DNS (PTR) record, and a matching A record for every sending IP.” There is no volume threshold and no bulk-sender cutoff like Gmail’s 5,000 messages per day—an IP that sends 20 invoices a month is held to the same DNS standard as a platform sending 2 million.

What the guidelines page makes clear is how boring most of the failure modes are: “Most listings are caused by the same recurring, but avoidable, mistakes.” And on permission: “Lack of permission is one of the two most common reasons we make a listing.” The DNS half of that pair is what this post fixes; the permission half is what the double opt-in section covers.

## What are the three DNS requirements?

The requirements are a resolvable HELO/EHLO hostname, a PTR record for the sending IP, and forward-confirmed reverse DNS—the PTR’s hostname resolving back to the same IP.

### A HELO/EHLO hostname that resolves

HELO/EHLO is the first line your server says in every SMTP conversation, before a single message is sent. Spamhaus: “Ensure the hostname used in the HELO/EHLO command resolves to the sending IP address.” It also has to stay put: “Maintain a consistent HELO value that resolves to the sending IP address.” A hostname that resolves today and points elsewhere tomorrow fails the consistency check.

And it cannot be a placeholder. The guidelines are explicit: “Do not use placeholder values such as `localhost` or generic hostnames that point to the hosting company/ISP.” That last clause is the one that catches rented servers, and we’ll come back to it.

### A PTR record on every sending IP

Reverse DNS is the lookup that starts from the IP instead of the name. Spamhaus: “Ensure the sending IP address has a valid reverse DNS (rDNS) entry resolving to a fully qualified domain name.” On a VPS, you don’t edit this in your own DNS zone—the record lives with whoever owns the IP address, so the fix happens in your provider’s console.

### Forward-confirmed reverse DNS (FCrDNS)

The PTR alone isn’t enough; the chain has to close. Spamhaus: “Ensure the rDNS hostname resolves to the connecting IP address via a corresponding forward DNS (A/AAAA) record.” Their name for the closed loop: “This is known as forward-confirmed reverse DNS (FCrDNS).”

Receiving mail servers run this check in the first seconds of a connection. An IP with no PTR, or a PTR that doesn’t confirm forward, reads as either a misconfigured server or a spoofing attempt—and the response to both is usually a 450 deferral or silence, not a helpful bounce message. That’s why mail “stops arriving” without anyone at the receiving end ever seeing an error from you.

## How do you check your own server in five minutes?

You can verify all three requirements from a terminal with a handful of read-only dig commands, one openssl probe, and a test mail to Spamhaus’s own HELO checker.

Every step below is read-only—nothing here changes a record. The edits happen later, at your DNS provider or your hoster’s console, and before any of them you copy the current value so you can restore it if something goes sideways.

1. Your sending IP: `dig +short mail.example.com`, or read it off your hoster’s console. The examples use `203.0.113.10`, a reserved documentation address; put your own IP in its place.
2. PTR: `dig +short -x 203.0.113.10`—must return a fully qualified domain name, not nothing and not a bare provider pattern.
3. Forward confirmation: `dig +short mail.example.com A`—must return the same IP. Replace `mail.example.com` with whatever hostname your PTR actually points at.
4. HELO banner: `openssl s_client -starttls smtp -connect mail.example.com:587`—read the server’s greeting line in the 250 response, then send `QUIT`. The name it announces is your HELO value.
5. Cross-check the banner: send any message to `helocheck@abuseat.org`—the automated reply shows the exact HELO string your server used on that connection.
6. Blocklist status: run your IP and domain through the Spamhaus checker the guidelines page links to, which also tells you whether you’re already on CSS or XBL.
7. On Windows, the same lookups work with `nslookup -type=TXT _dmarc.example.com` and friends.

```
# 1. The IP your server actually sends from
dig +short mail.example.com
# → 203.0.113.10   (a reserved documentation address; use your own IP below)

# 2. PTR record of that IP (reverse DNS)
dig +short -x 203.0.113.10
# → mail.example.com

# 3. The way back: A record of the name from step 2 (AAAA for IPv6)
dig +short mail.example.com
# → 203.0.113.10   (must match the IP from step 1)

# 4. SPF, DMARC and DKIM, previewing the next section
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT default._domainkey.example.com

# 5. HELO banner
openssl s_client -starttls smtp -connect mail.example.com:587
# read the 250 greeting, then type: QUIT
```

The SPF, DMARC and DKIM lookups in that block preview the next section. When you do edit a record: one record at a time, keep the old value, and expect caches to serve the old answer until the TTL runs out. Nothing here is instant, and none of it is risk-free if you skip the copy-first step.

## What else do the Sender Guidelines require?

Beyond the three DNS records, Spamhaus wants SPF within the 10-lookup limit, DKIM on every message with at least 1024-bit keys, a DMARC policy on every sending domain, a bounce rate below 5%, and RFC 8058 one-click unsubscribe for bulk senders.

- DKIM: “Ensure every outbound message carries a valid DKIM signature, using a minimum 1024-bit key length while 2048-bit is recommended.” Paste the key your mail provider generates—never roll your own. Some sending services only issue 1024-bit keys; that’s a vendor limit, not a misconfiguration on your side. Rotation, if you ever need it, means adding the new selector, switching signing, then removing the old key later—never all in one step.
- DMARC: “Publish a DMARC record with a policy defined for the sending domain.” Spamhaus doesn’t prescribe which policy. If you’re starting from zero, treat it as a ramp: `p=none` with a report address someone actually reads, then fix every legitimate sender the reports surface, then quarantine, then reject. `p=none` asks receivers for no specific action on failing mail—it buys you data, not protection.
- Bounce rate: “Keep the overall bounce rate below 5%.” That’s bounces, a different metric from Gmail’s 0.30% spam-rate ceiling in Postmaster Tools—don’t confuse the two when you benchmark.
- Unsubscribe: bulk commercial senders implement `List-Unsubscribe-Post: List-Unsubscribe=One-Click`, the RFC 8058 header that lets people unsubscribe straight from the inbox instead of a trip through your web form.

## Why does double opt-in matter more here than at Gmail or Yahoo?

Spamhaus requires confirmed opt-in for every subscriber—a stricter line than Gmail or Yahoo, neither of which mandates it.

The guidelines don’t hedge: “Use confirmed opt-in (COI) for all subscribers.” Each recipient confirms their address by clicking a link in a confirmation email, and “Do not send emails to purchased, rented, or harvested lists” is a flat ban.

Compare the mailbox providers. Gmail, since February 1, 2024, applies its bulk-sender rules to anyone sending more than 5,000 messages per day to Gmail accounts; it asks senders to “confirm each recipient’s email address before subscribing them” and to keep spam rates in Postmaster Tools below 0.30%—but a full double opt-in isn’t mandated. Yahoo, enforcing since February 2024, wants SPF and DKIM, “a valid DMARC policy with at least p=none”, a one-click unsubscribe header, unsubscribes honored within two days, and spam below 0.3%. Also no confirmed-opt-in mandate.

If you send from Germany, this section costs you nothing: double opt-in has been the default signup flow there for years, so the infrastructure you already run clears Spamhaus’s strictest requirement by default. I keep seeing US newsletters treat the confirmation mail as conversion-killing friction. Against “Lack of permission is one of the two most common reasons we make a listing,” it’s the cheapest deliverability insurance you can buy.

## What are Zero Reputation Domains?

A domain registered less than 24 hours ago lands on Spamhaus’s ZRD watchlist automatically and is removed 24 hours later.

The reasoning, in Spamhaus’s words: “Domains that have just been registered are rarely used by legitimate organizations immediately.” A ZRD listing isn’t a punishment—it expires on its own, and “the domain will be automatically removed from the blocklist after 24 hours,” no removal request needed.

What it means for you: a new project or a rebrand that starts sending mail in its first day will hit filters harder than the same mail would a day later. Sequence accordingly—register, finish the DNS setup, let the 24 hours pass before the first campaign goes out. Transactional confirmations, like your double opt-in mail, usually still get through; it’s the volume that suffers.

## What does a listing actually do to your delivery?

It depends on the receiving provider: Spamhaus’s own usage guidance recommends rejecting at SMTP time when the connecting IP is in SBL, XBL or PBL, but only negative scoring when a listed IP appears deeper in the Received headers (SBL, CSS or XBL).

That split is why the symptoms arrive as a mix: some destinations bounce instantly, some queue forever behind 450 deferrals, some deliver into the spam folder, and some never arrive anywhere you can observe. No single dashboard shows you all four at once.

CSS listings are automated and short-lived. CSS is “an automatically produced dataset of IP addresses sending low-reputation email,” and listings “generally expire three (3) days after the last detection.” Spamhaus allows “fast, no-questions-asked removals – within limits,” and the limit matters: “Whatever caused the problem MUST be identified and corrected before removing an IP from CSS.” Delisting a still-broken server just gets it re-listed.

XBL is worse news by definition. It is “a realtime database of IP addresses used by hijacked devices compromised by 3rd party exploits.” If your IP shows up there, assume something on or near your network is sending mail you didn’t originate. Spamhaus’s remediation advice is to close port 25 at the router or firewall and restrict it to known mail servers.

How do you notice before a customer tells you? Watch your own bounces: a sudden cluster of 550 rejections naming Spamhaus, or a spike in 450 deferrals, is usually the first honest signal. Customers mention the missing password-reset mail later—much later.

## Why do self-managed servers fail the HELO check first?

On servers you administer yourself—Hetzner, OVH, Vultr and friends—the HELO banner is the most commonly broken item, because it ships as something generic that never matched your DNS in the first place.

Take Hetzner. PTR records for Hetzner IPs are managed by Hetzner, and the default is a generic pattern along the lines of `static.1.113.0.203.clients.your-server.de`—precisely the “generic hostnames that point to the hosting company/ISP” Spamhaus tells you not to use. The fix is in Hetzner Console, under the Networking tab: set the rDNS entry to the fully qualified domain name your mail server should announce. Keep the old value in case you need to roll back, and expect caches to serve it until the TTL expires.

The announcement itself, in Postfix, comes from `myhostname` in `main.cf`, and the banner should show the same FQDN as the PTR. Edit the setting, restart the service, then re-run the HELO probe from the five-minute check above. In the audits I run on self-managed servers, this is the item most often wrong—usually a leftover from the initial install that nobody has touched since.

## What goes on the pre-enforcement checklist?

Spamhaus’s own ESP guidance compresses the whole DNS section into two sentences: “Make sure the HELO, PTR and A record all use the same hostname.” and “Brand the reverse DNS and HELO with the customer’s domain where possible, instead of using the default ESP hostname.” Everything below is that idea, expanded into something you can print.

```
Sender DNS hygiene—run this before November 2026 enforcement reaches you
[ ] HELO/EHLO: hostname resolves to the sending IP, stays consistent, no placeholder
[ ] PTR: reverse record of every sending IP points to a fully qualified domain name
[ ] FCrDNS: the A record of the PTR hostname (AAAA for IPv6) resolves back to the same IP
[ ] HELO, PTR and A record use the same hostname
[ ] SPF: exactly one v=spf1 record per domain, within the 10 DNS lookup limit
[ ] DKIM: valid signature on every message, 1024-bit key minimum, 2048 recommended
[ ] DMARC: record with a policy published for the sending domain, reports actually read
[ ] Bounce rate below 5% overall
[ ] List-Unsubscribe-Post with List-Unsubscribe=One-Click (RFC 8058) on commercial bulk mail
[ ] Confirmed opt-in for every subscriber; no bought, rented or scraped lists
[ ] New domains: the first 24 hours on the ZRD list planned for
[ ] Spamhaus lookup for every sending IP and domain (CSS, XBL), repeated now and then
```

## What if your DNS is perfect and the mail still fails?

Check your provider’s status dashboard before you blame your records—provider-side incidents imitate blocklist problems convincingly.

Concrete example: Exchange Online logged a Warning-severity incident beginning October 27, 2026 at 4:13 PM UTC, lasting 8 hours 45 minutes, with “intermittent errors or failures when accessing Exchange Online through REST APIs.” Root cause was a directory-service configuration change—“intended to further optimize the service”—which Microsoft rolled back. Nothing any sender could have fixed in DNS.

Telling the two apart: a provider incident means failures across all your sending domains at once, matching the dashboard’s timeline. Your problem means one IP or one domain failing while everything else flows. And keep the rule from our own audits in mind: a 200 response, or a friendly 250 greeting, only proves the server answered—it is not proof that the pipeline is healthy.

## FAQ: what senders ask us most

### Do the Spamhaus rules apply to tiny senders?

Yes—unlike Gmail’s 5,000-per-day threshold, Spamhaus’s requirements attach to the sending IP and the sending domain regardless of volume. A VPS sending 20 invoices a month needs the same three DNS records as a marketing platform.

### Does a blocklist listing affect transactional mail?

Yes—password resets and order confirmations leave from the same IP and domain the listing covers, and they’re usually the first thing you notice, because customers ask about the reset mail before anyone opens the newsletter.

### How do I get off a Spamhaus list?

Through Spamhaus’s lookup and removal flow, as the registered owner of the IP or domain. Requests “cannot be submitted via email,” they “must not be made using a VPN or proxy,” and “submitting a removal request does not guarantee removal will be granted.” Fix the root cause first—a CSS listing expires roughly three days after the last detection anyway, but an unfixed server just gets re-listed.

### Does every sender need DMARC?

Spamhaus requires a DMARC policy for sending domains; Gmail and Yahoo require DMARC only of their bulk senders (Gmail’s threshold: more than 5,000 messages per day to Gmail accounts). If a domain sends mail, publish DMARC for it—and if you’re starting fresh, begin at `p=none` with a report address someone reads, then ramp.

### Is there a specific switch-over day in November 2026?

No—Spamhaus has published no single enforcement date. The rollout is gradual, stretching over several months, so treat November 2026 as the month your baseline has to exist, not a deadline you can race at the end.

## What should you do next?

Honest scope, if you run a single server on Hetzner or similar: the PTR and HELO fix is a 15-minute job once you’ve picked the FQDN you want to announce. The full sender cleanup—inventorying every tool that sends mail on your domain, tightening SPF, publishing DKIM selectors, and riding DMARC from `p=none` to a real policy on the reports—is an afternoon, sometimes a week of waiting on reports.

We do this work for clients: a deliverability check with SPF, DKIM and DMARC setup, plus the HELO and PTR pass, so the November 2026 requirements are behind your server before the first enforcement probe arrives. See the [AI Visibility Audit](https://digitaldomination.xyz/en/services/ai-visibility-audit) if your question is less “is my mail arriving” and more “how do AI answers describe my brand”—or [write to us](https://digitaldomination.xyz/en/contact) and we’ll start with your DNS.

## Sources

1. [Spamhaus Resource Hub — Spamhaus Sender Guidelines (announcement)](https://www.spamhaus.org/resource-hub/deliverability/spamhaus-sender-guidelines/) (accessed 2026-11-02)
2. [Spamhaus Sender Guidelines (official requirements page)](https://www.spamhaus.org/sender-guidelines/) (accessed 2026-11-02)
3. [Spamhaus ESP & Large Sender Guidelines](https://www.spamhaus.org/sender-guidelines/esp-large-senders/) (accessed 2026-11-02)
4. [Spamhaus FAQ — Zero Reputation Domain (ZRD)](https://www.spamhaus.org/faqs/zero-reputation-domain-zrd/) (accessed 2026-11-02)
5. [Spamhaus FAQ — Combined Spam Sources (CSS)](https://www.spamhaus.org/faqs/combined-spam-sources-css/) (accessed 2026-11-02)
6. [Spamhaus FAQ — Exploits Blocklist (XBL)](https://www.spamhaus.org/faqs/exploits-blocklist-xbl/) (accessed 2026-11-02)
7. [Spamhaus FAQ — General Questions (removals)](https://www.spamhaus.org/faqs/general-questions/) (accessed 2026-11-02)
8. [Spamhaus Docs — SMTP Checks (real-world usage)](https://docs.spamhaus.com/datasets/docs/source/40-real-world-usage/smtp/020-SMTP-Checks.html) (accessed 2026-11-02)
9. [Hetzner Docs — PTR Record](https://docs.hetzner.com/networking/dns/record-types/ptr-record/) (accessed 2026-11-02)
10. [Google — Email sender guidelines (Gmail)](https://support.google.com/mail/answer/81126?hl=en) (accessed 2026-11-02)
11. [Yahoo Sender Hub — Best Practices](https://senders.yahooinc.com/best-practices/) (accessed 2026-11-02)
12. [StatusGator — Exchange Online status history](https://statusgator.com/services/exchange-online) (accessed 2026-11-02)
13. [365Fanatic — Exchange Online incident EX1527500](https://www.365fanatic.com/m365-status/EX1527500/) (accessed 2026-11-02)