Spamhaus Sender Guidelines: What Every Sending IP Needs From November 2026

Starting in November 2026, Spamhaus will gradually begin enforcing three basic DNS requirements for every sending IP: a valid HELO hostname, a reverse DNS PTR record, and a matching A record. The requirements themselves are not new. The enforcement date is new, and the rollout will continue over several months.

If you run a mail server, manage sending infrastructure, or send through an ESP, audit every IPv4 and IPv6 sending path now. Your DNS audit and your DMARC audit answer different questions, so run both. DMARCFlow fits the second half by exposing authentication and alignment failures across your domains, but it cannot inspect HELO, PTR, or IP reputation.

The November 2026 date is new. The DNS rules behind it are not.

What changes in November 2026?

Spamhaus has consolidated its sender guidance into one reference and announced a gradual rollout of enforcement for three DNS basics:

1. A valid HELO hostname
2. A reverse DNS PTR record
3. A matching A record

Spamhaus says this enforcement will begin in November 2026 and roll out over several months. It has not published a fixed day for every IP.

The distinction matters. Spamhaus says the underlying requirements already existed in RFCs, mailbox-provider guidance, and responsible sender practice. What changed is that the project is starting to enforce the basics across every sending IP, and has put the complete guidance in one place.

This is not a blanket announcement that every part of the guidelines becomes mandatory in November. The project still expects senders to follow six broader areas: infrastructure and DNS, permission and list hygiene, authentication, sending practices, IP and domain reputation, and guidance for ESPs and large senders.

What is new and what still applies

Requirement	New enforcement rollout in November 2026	What to verify
Valid HELO hostname	Yes	The announced FQDN resolves to the connecting IP and stays stable
Reverse DNS PTR	Yes	The PTR target resolves back to the same IP
Matching A record	Yes	The HELO hostname resolves to the sending IPv4 address
Confirmed opt-in	No new date in this notice	Every subscriber confirmed the address
IPv6 allocation and reverse DNS	No new date in this notice	The address is in a `/64` or larger block and has valid reverse DNS
SPF, DKIM, and DMARC	No new date in this notice	Every sending domain is covered, every message is signed, and DKIM aligns

The November rollout applies to the first three rows. The remaining rows are already part of Spamhaus's minimum requirements and should be included in the same audit.

The three DNS requirements being enforced

1. The HELO or EHLO hostname must identify the sending IP correctly

When an SMTP client connects, it normally announces its identity with EHLO. The domain in that command must be a resolvable fully qualified domain name, and it must point to the IP making the connection. It also needs to stay consistent across connections from that IP.

A provider default such as mail.provider.invalid, a local alias, or a hostname that changes between servers is not a sound long-term identity. RFC 5321 requires a primary host name that resolves to an address record, or an address literal when the host has no name.

In practice, the operator needs to answer one question for each sending IP: does the hostname announced in the SMTP session resolve back to that exact IP?

2. Every sending IP needs a PTR record

A PTR record maps an IP address back to a hostname. Spamhaus requires forward-confirmed reverse DNS, often shortened to FCrDNS:

The IP has a PTR record pointing to a fully qualified domain name.
That hostname resolves forward to the same IP.

A PTR record by itself is not enough. If the PTR hostname points to mail.example.net, but mail.example.net resolves to another address, the configuration is not forward-confirmed.

3. The hostname must have a matching forward record

For IPv4, the HELO hostname needs an A record that resolves to the sending IP. If the host sends over IPv6, check its AAAA record as well. An AAAA record identifies an IPv6 address, so it cannot stand in for the IPv4 A record, and an IPv4 A record cannot stand in for the IPv6 check.

This closes the other half of the loop:

Direction	DNS question	Expected result
IP to name	What does the PTR record say?	A stable FQDN
Name to IP	What does the hostname resolve to?	The same sending IP

When both directions agree, the sending address has forward-confirmed reverse DNS. When they do not, a receiver can reasonably treat the infrastructure as misconfigured.

The full Spamhaus minimum requirements

The three DNS basics are the part with a new enforcement rollout. Spamhaus also lists five minimum requirements for senders. Operators should treat the full checklist as the target state.

Confirmed opt-in

Each subscriber should confirm the address through a confirmation email. Do not send to an address that never confirmed. Purchased, rented, and harvested lists are a common route to spam-trap hits.

This requirement cannot be fixed in DNS. Keep the confirmation record, the date, and the source of consent for each sending list.

Forward-confirmed reverse DNS

Every sending IP needs a PTR record whose hostname resolves back to that IP. This is the DNS check described above.

A stable HELO or EHLO hostname

The announced hostname must resolve to the connecting IP and remain consistent across connections. This is another DNS and mail-server check, not an authentication record.

The IPv6 allocation and reverse-DNS minimum

If an address sends over IPv6, it must sit within an allocated block of /64 or larger. Spamhaus recommends /64 as the standard block size and requires valid reverse DNS for the allocated IPv6 space.

SPF, DKIM, and DMARC

Publish SPF and DMARC for every sending domain. Sign every outbound message with DKIM. Align the DKIM sending domain with the domain in the RFC 5322 From address.

Authentication is one reputation signal. Passing it does not cancel a DNS failure, prove that a list has permission, or protect a sender from every listing.

SPF, DKIM, and DMARC answer who may send. HELO and PTR describe whether the sending infrastructure is configured consistently.

Build an inventory of every sending IP first

Most audits fail because the inventory is incomplete. A clean primary server says nothing about a secondary relay, a forgotten IPv6 pool, or a delegated sending service.

Build a table with one row per sending path. Include:

Primary and backup SMTP servers
Dedicated and shared IP pools
IPv4 and IPv6 addresses
Regional or failover relays
Cloud mail and marketing services
Subdomains that send on behalf of the organization
DKIM delegated senders and other third-party services

For each row, record the source IP, HELO hostname, PTR target, A or AAAA result, owner, sending purpose, and whether the operator controls DNS. Use this template, replacing the documentation values with the results from your own tests:

Sending IP or range	HELO hostname	PTR target	A or AAAA match	FCrDNS	IPv6 `/64` or larger	SPF, DKIM, DMARC	Control owner
`203.0.113.10`	`mail.example.net`	`mail.example.net`	Pass	Pass	Not applicable	Pass	Internal

Keep the result, test date, and owner in the same row. A later change to the host, DNS provider, or sending service then has a clear record to compare against.

Do not skip shared ESP infrastructure. The ESP controls the IP, HELO, and PTR. The customer still controls list permission, the sending domain, SPF, DKIM, DMARC, and alignment. Split the audit into provider-owned and customer-owned checks so neither side assumes the other has covered everything.

Audit HELO, PTR, and forward DNS for each IP

The examples below use the reserved documentation address 203.0.113.10 and the example hostname mail.example.net.

Step 1: Check the PTR record

dig -x 203.0.113.10 +short

A healthy result is a stable FQDN:

mail.example.net.

No output means there is no PTR record. A provider hostname that does not belong to the sender is a configuration problem even when the record exists.

Step 2: Check forward resolution

dig mail.example.net A +short

The result should be 203.0.113.10. Repeat the check from more than one DNS resolver. A stale answer can hide a recent change.

If the host also sends over IPv6:

dig mail.example.net AAAA +short

The AAAA result should match an IPv6 address from the inventory that actually sends mail. A valid DNS answer for an address that never connects is not a substitute for the real sending address.

Step 3: Prove both directions agree

The PTR target and HELO hostname must both resolve to the correct sending IP. In a clean setup, using the same FQDN for PTR and HELO is the simplest way to make that true.

They do not have to be identical strings in every architecture. The operational requirement is that both names resolve correctly, remain stable, and describe the sending IP rather than a shared or unrelated host.

Step 4: Inspect the SMTP greeting

Open a session to the sending host and compare the hostname in the response with the configured HELO value. A typical exchange looks like this:

220 mx.example.org ESMTP ready
EHLO mail.example.net
250-mx.example.org
250 SIZE 35882577

The key value is mail.example.net after EHLO. Repeat the connection several times and across failover nodes. A hostname that changes between sessions violates the consistency requirement even if each name resolves correctly on its own.

Check IPv6 allocations and reverse DNS

IPv4-only audits miss a growing class of sending infrastructure. For each active IPv6 source, confirm:

1. The address belongs to an allocated /64 or larger block.
2. The address has valid reverse DNS.
3. The reverse name resolves forward to the same IPv6 address.
4. The IPv6 address appears in the real mail logs and sending inventory.

Ask the provider for the exact allocation, delegation, and PTR design if the organization does not own the address space. Do not infer IPv6 compliance from an IPv4 test.

Verify SPF, DKIM, and DMARC across every sending path

Authentication is a separate audit layer. A domain can have excellent DNS and still miss a legitimate sending source in SPF. It can sign with DKIM but use a signing domain that does not align with the visible From domain.

Check the basics:

SPF includes every active service that sends for the domain.
DKIM signs every outbound stream that needs to authenticate.
The DKIM domain aligns with the RFC 5322 From domain under the DMARC policy.
DMARC is published for every sending domain, including delegated subdomains.
Aggregate reports identify unexpected or failing sources.

DMARC aggregate reports are the best estate-wide source for finding authentication and alignment failures. DMARCFlow can surface failing sources and help operators find the service or subdomain that needs attention. That saves time, but it does not prove that HELO, PTR, or forward DNS is correct. Run the DNS and SMTP checks separately.

Common failures and how to fix them

Check	Expected result	Command or evidence	Common failure	Fix
PTR record	A stable FQDN points back to the sending IP	`dig -x +short`	No PTR, or a provider hostname unrelated to the sender	Ask the network owner to publish correct reverse DNS
Forward DNS	The HELO hostname resolves to the sending IP	`dig A +short`	The A record points elsewhere or is stale	Correct the A record, or publish a dedicated hostname
HELO stability	The same valid FQDN is announced across connections	The `EHLO` value in repeated SMTP sessions	A provider default is used, or the name changes by node	Set one sender-owned hostname across the failover pool
IPv6 allocation	The address is in a `/64` or larger block with valid reverse DNS	Provider allocation records plus `dig -x +short`	The allocation is too small or reverse DNS is missing	Obtain the correct allocation and configure PTR records
SPF	Every active sending service is authorized	`dig TXT`	A known service is omitted from the record	Add the active service and remove obsolete sources
DKIM and alignment	Every outbound message is signed and the signing domain aligns	`dig TXT ._domainkey.` plus DMARC reports	DKIM passes but does not align with the visible `From` domain	Use a signing domain that aligns with the `From` domain
DMARC	Every sending domain has a policy record	`dig TXT _dmarc.`	A delegated or regional subdomain has no policy	Publish and verify DMARC for every sending domain

Do not fix a DNS record and assume the reputation problem is over. Spamhaus uses multiple signals, and a correction may take time to propagate through DNS caches and the receiving system's observations.

A separate checklist for ESPs and large senders

An ESP is responsible for the mail sent through its shared infrastructure. A customer who sends badly can damage the platform's IP and domain reputation. Spamhaus therefore applies the same core guidelines to the platform while adding guidance for operating at scale.

For an ESP or large sender, the operating model should include:

A current inventory of sending IPs and IPv6 space
Documented HELO, PTR, and forward-DNS ownership for each pool
Onboarding checks before a new customer sends
Monitoring for complaints, spam traps, compromised accounts, and abuse
A process for disabling or isolating a tenant that damages shared reputation
Regular testing after failover, migration, or provider changes

For an organization using an ESP, ask the provider for:

1. Every sending IP and IPv6 range
2. The HELO hostname used by each pool
3. The PTR and forward-DNS configuration for those addresses
4. Whether each pool is dedicated or shared
5. How the provider monitors tenant behavior
6. How customers are notified when sending infrastructure changes

Then audit the customer-controlled part: permission, SPF, DKIM, DMARC, alignment, and report monitoring. A clean provider infrastructure cannot compensate for a broken customer domain, and a good customer configuration cannot repair a provider's missing PTR.

What DMARC monitoring adds to the audit

DMARC monitoring and DNS testing belong in the same work order because they expose different failures.

DMARC aggregate reports show which sources sent for a domain, which SPF or DKIM checks passed, and whether the authorized domain aligned with the visible sender. DMARCFlow can turn those reports into an estate-wide view, which helps teams find an old sending service, a broken DKIM selector, or an unauthorized source that a DNS inventory alone would miss.

DMARC reports cannot show:

The hostname sent in HELO or EHLO
Whether the IP has a PTR record
Whether the PTR hostname resolves back to the IP
The IPv6 allocation size
Whether a subscriber gave permission
Spamhaus IP or domain reputation

Use the Spamhaus HELO and DNS checker for the infrastructure checks, and check.spamhaus.org for current reputation information. Spamhaus warns that checker results may not be available for every IP and may not reflect recent DNS changes. Record your test date and repeat the checks after infrastructure changes.

A 30-minute compliance checklist

For a small or single-host sending estate, this is a practical first pass. Larger estates need more time to build the inventory before testing.

1. List every IPv4 and IPv6 address that sends mail.
2. Record the HELO hostname for each address.
3. Run dig -x for every sending IP and save the PTR result.
4. Resolve each PTR and HELO hostname forward with dig and compare the result with the inventory.
5. Inspect the SMTP greeting from every primary and failover host.
6. Confirm that each active IPv6 address is in a /64 or larger allocation and has reverse DNS.
7. Check SPF, DKIM, and DMARC for every sending domain.
8. In DMARCFlow, review aggregate reports by sending source. Resolve unknown sources, SPF failures, DKIM failures, and alignment failures, then record which service owns each result.
9. Check the IP and domain reputation in the Spamhaus checker and record the date.
10. Ask every ESP or hosting provider for the IP inventory, HELO, PTR, and ownership details that the provider controls.

Retest after a migration, failover change, new IPv6 allocation, ESP change, or DNS provider change.

Frequently asked questions

Are the Spamhaus Sender Guidelines new in November 2026?

The enforcement rollout is new. The underlying DNS and sending requirements are not. Spamhaus says it is gradually starting to enforce the basic DNS requirements from November 2026 over several months.

What exactly is being enforced in November 2026?

A valid HELO hostname, a reverse DNS PTR record, and a matching A record for every sending IP. The broader guidelines also cover permission, authentication, sending practices, reputation, and guidance for large senders.

Must the HELO hostname be identical to the PTR hostname?

Not necessarily as a literal string. Both must resolve consistently to the correct sending IP and remain stable. Using the same FQDN for both is the simplest setup and makes the audit easier.

Does every sending IP need IPv6 reverse DNS?

Every IPv4 sending IP needs a PTR record. If an IPv6 address sends mail, Spamhaus also requires valid reverse DNS for that IPv6 space, and the address must sit within an allocated /64 or larger block. Use an AAAA record for IPv6 forward resolution and a PTR record for reverse resolution.

Do passing SPF, DKIM, and DMARC prevent a Spamhaus listing?

No. Authentication is one reputation signal. The sender still needs stable DNS, correct HELO, permission, sound list hygiene, and consistent sending practices.

Does an ESP need to comply for each customer domain?

The ESP is responsible for its sending infrastructure, including HELO, PTR, and forward DNS. Each customer remains responsible for permission, its own sending domains, SPF, DKIM, DMARC, and alignment.

Can DMARC reports prove that HELO and PTR are correct?

No. DMARC reports contain authentication results, not SMTP greetings or reverse-DNS records. Use SMTP inspection and DNS lookups for those checks, then use DMARC reports for the authentication layer.

What should I ask my ESP during the audit?

Ask for every sending IP and IPv6 range, the HELO name for each pool, the PTR and forward-DNS setup, whether the pool is dedicated or shared, and how the provider monitors customer abuse. Audit your own domains and list permission separately.