When did Spamhaus launch its sender guidelines?
Published 29 Oct 2026
Updated 29 Oct 2026
7 min read
Summarize with
Spamhaus launched its consolidated Sender Guidelines on October 21, 2026. The date appears on its official announcement. A separate, gradual rollout of DNS enforcement starts in November 2026 and is scheduled to run over several months.
I treat these as separate milestones: publication gives senders a consolidated reference, while enforcement changes make infrastructure checks more urgent. The launch brought existing guidance into one place. It does not mean permission, authentication, or responsible sending first became relevant in October 2026.
What launched, and when enforcement starts
The new resource brought together guidance previously spread across Spamhaus FAQs, best practice posts, and support material. It is intended for mail server operators, including small businesses managing their own servers and email service providers (ESPs).
For planning purposes, keep the publication date and enforcement window in separate fields. The announcement describes a phased rollout, so November should not be recorded as a universal deadline when every sending IP suddenly receives identical treatment.
|
|
|
|---|---|---|
Publication | October 21, 2026 | Consolidated guidance |
DNS enforcement | November 2026 | Gradual rollout |
Rollout duration | Several months | Phased enforcement |
The operational change to prioritize is the stated requirement for a valid HELO identity, reverse DNS (PTR), and a matching forward A record for each sending IP. That is the implementation work highlighted in the launch announcement.
What the sender guidelines cover
The Spamhaus Sender Guidelines cover the following areas. I use these headings to assign work to the people who control each part of the sending process.
- Infrastructure and DNS. Check reverse DNS, HELO/EHLO identity, and sending host configuration.
- Authentication. Review SPF, DKIM, and DMARC for each active sending domain.
- Permission and list hygiene. Verify subscription evidence and how addresses enter the database.
- Sending practices. Review volume changes, bounce handling, and unsubscribe processing.
- IP and domain reputation. Investigate listing signals alongside actual delivery failures.
- ESPs and large senders. Review responsibilities for customers using shared infrastructure.
The page distinguishes requirements from recommendations and practices to avoid. Keep those distinctions in an audit rather than giving every sentence the same priority. Confirmed opt-in is expressly included in the minimum requirements, and the page recommends progressing beyond a permanent monitoring-only DMARC policy.
An authentication pass also does not establish that someone requested a message. A sending domain can authenticate unwanted mail successfully. I keep recipient permission evidence separate from the technical checks so a clean authentication report does not close an unresolved list acquisition issue.
Check the sending IP and DNS identity
Start with the public IP that actually connects to recipient mail servers. A website's IP address is often unrelated. For hosted sending, obtain the outbound IP information from the provider or delivery logs, including any separate pools used for different message streams.
For an illustrative IPv4 setup, the public sending IP is 192.0.2.25, its PTR points to mail.example.com, and that hostname resolves back to 192.0.2.25. The server also announces mail.example.com during SMTP. These reserved example values must be replaced with your real infrastructure.
Illustrative DNS checksbash
dig +short -x 192.0.2.25 # Expected example result: mail.example.com. dig +short A mail.example.com # Expected example result: 192.0.2.25
The reverse lookup and forward lookup should agree. Querying DNS does not reveal what the server actually announces in HELO/EHLO, so inspect the mail server configuration or an SMTP session log as well. Check the identity used after any outbound gateway or address translation.
PTR changes normally belong to whoever controls the IP allocation. Creating an A record in your domain's DNS panel does not create reverse DNS. For shared sending infrastructure, ask the provider to investigate a mismatch. Repeat the checks for every active outbound IP, including IPv6 where used.
Test authentication on real messages
A DNS audit establishes which records exist. A delivered message establishes which identities a particular sending path actually uses. I test each application separately because a billing system and a marketing system can use different signing domains despite showing the same visible From address.
SPF checks the connecting IP against the envelope sender domain, or the HELO identity when the envelope sender is empty. DKIM verifies a message signature. DMARC passes when at least one successful SPF or DKIM result also meets the domain matching rules for the visible From address.
DNS evidence
Inspect published records, DKIM selectors, and which servers SPF authorizes. This finds missing records and configuration errors.
Message evidence
Inspect trusted recipient authentication results for a real send. This confirms the signing domain and envelope sender actually used.
A useful test therefore records the visible From domain, envelope sender, DKIM signing domain, and recipient's authentication verdict. A DKIM pass using an unrelated provider domain alone does not satisfy DMARC for your brand domain.
Suped's domain health checker helps review published authentication records. Check its results alongside a real message and DMARC aggregate reports before changing an enforcement policy. A valid record by itself does not prove that every legitimate sending application passes.
Turn the launch into an ongoing audit
I start with an inventory that names each sending system, its owner, the domains it uses, and its outbound IPs. For shared infrastructure, record which changes require the provider. This prevents a DNS task being assigned to someone who cannot make the change.
Send a representative message through each important sending path and inspect the result. Suped's email tester supports this step by checking an actual email for authentication and other delivery issues.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Suped is our DMARC and email authentication platform. Its aggregate reporting and source detail views help identify legitimate senders with authentication failures. Automated issue detection provides steps to fix, while configured failure alerts help flag changes after the initial audit.
For reputation checks, Suped's blocklist monitoring keeps domain and IP listing results in the same operational workflow. A focused blocklist check establishes the current result for a specific asset. Neither a clean blacklist result nor a DMARC pass guarantees inbox placement.
After a provider migration, I repeat the audit even when DNS was copied unchanged. The outbound pool and signing configuration can change independently of published records, leaving a previously working sending path with new authentication failures.
Handle an existing Spamhaus listing separately
If delivery is already failing, preserve the complete rejection response and identify the listed asset. An IP listing and a domain listing require different investigations. Check the exact outbound IP or domain mentioned, rather than assuming that the website or visible From domain is responsible.
Fix the documented cause before requesting removal. Infrastructure errors need infrastructure changes; permission problems need changes to address collection and sending. The steps for resolving Spamhaus listings help structure that investigation.
Changing DMARC does not remove a Spamhaus listing. Correct the cause identified for the listed IP or domain, then follow the removal instructions associated with that listing.
Keep an owner and verification evidence for each fix. For example, save the corrected DNS lookup and the next successful delivery attempt. A delisting request without evidence that the sending behavior changed leaves the underlying problem unresolved.
Review blacklist status again after remediation, but also watch recipient rejection logs. Those logs show whether delivery recovered and whether a different problem remains.
Views from the trenches
Best practices
Audit every active outbound IP and assign DNS corrections to the team that controls it.
Keep permission evidence separate from authentication results when reviewing a sender.
Common pitfalls
Treating the publication date as a universal enforcement deadline creates planning errors.
Checking only domain DNS misses the HELO identity announced by the outbound mail server.
Expert tips
Save DNS lookup results and a real message sample so each remediation has clear evidence.
Compare the guidelines with your own infrastructure before treating an initial review as final.
Marketer view
Marketer from Email Geeks says the guidelines had just launched and invited senders to test them and provide feedback.
2026-10-22 - Email Geeks
Marketer view
Marketer from Email Geeks says the overview looked comprehensive on an initial read and planned to compare it with their own infrastructure.
2026-10-22 - Email Geeks
Assign the next infrastructure check
For an immediate action, assign someone to verify the public sending IP, its PTR, its forward DNS, and the actual HELO/EHLO identity. Record the evidence and the person responsible for correcting each mismatch.
I keep that infrastructure task open until it is verified independently of the authentication task. Then check one real message through each sending application and retain permission evidence for the recipients receiving it.
Frequently asked questions
Spamhaus published its consolidated Sender Guidelines on October 21, 2026. The official launch announcement carries that date.
The announcement schedules gradual DNS enforcement starting in November 2026, over several months. It does not give a single completion date for every sender.
Spamhaus describes the publication as a consolidation of established guidance. The announcement separately specifies a phased rollout for enforcing basic DNS requirements.
No. DMARC authenticates the use of the visible From domain. It does not establish recipient permission or eliminate infrastructure and reputation problems.
Usually the hosting company, network operator, or provider controlling the IP allocation. Contact that owner when reverse DNS needs changing.
