Spamhaus Requirements from November 2026 and the New DMARC (RFC 9989): An Email Checklist for Egyptian Companies
Short answer: On 21 October 2026 Spamhaus announced that, starting in November 2026, it is gradually requiring every sending IP to have a valid HELO, a reverse DNS (PTR) record and a matching A record, alongside SPF, DKIM and DMARC for every sending domain. At the same time the new DMARC standard, RFC 9989, made the pct tag historic. Our own scan of 332 Egyptian domains found 146 (44%) without a valid DMARC record. Check your mail server and every system that sends automated email before blocklist listings appear.
If your company sends invoices from an accounting system, appointment reminders from a clinic system or payslips from an HR system, the new Spamhaus requirements apply to you even if you never send a single marketing campaign. Spamhaus lists are queried by a large number of mail servers worldwide, and a listing means delayed or rejected mail wherever they are used. This guide explains exactly what changed, what the new DMARC standard adds, the results of our own measurement of Egyptian domains, and a practical checklist.
What did Spamhaus announce on 21 October 2026?
On 21 October 2026 Spamhaus published a single set of Sender Guidelines that gathers advice previously spread across FAQs, blogs and support tickets. It added a sentence that turns a long-standing recommendation into a dated requirement: starting in November 2026 it is gradually rolling out a requirement for every sending IP to have a valid HELO, a reverse DNS (PTR) record and a matching A record. Its companion article says enforcement will roll out over several months; no exact day or detailed phasing was given.
The key points of the guidelines:
- Forward-confirmed reverse DNS (FCrDNS): the PTR of the sending IP must point to a fully qualified domain name that resolves back to the same IP with an A record.
- A correct HELO/EHLO: the announced hostname must resolve to the connecting IP and stay consistent. Placeholders such as localhost and hosting-provider defaults are treated as signs of misconfiguration or compromise and can lead to a listing.
- IPv6: allocations must be at least /64 and have valid reverse DNS.
- Authentication: SPF and DMARC for every sending domain, and a DKIM signature on every outbound message with at least a 1024-bit key (2048-bit recommended), with the d= domain matching the From domain and keys rotated at least annually.
- DMARC: starting at p=none is acceptable, but Spamhaus advises not to remain there permanently and to set up an aggregate report address (rua) from day one.
- Permission: bulk mail only to recipients who confirmed their address (confirmed opt-in).
The guidelines state that failing the infrastructure and DNS setup can result in IPs being listed in the CSS (spam IPs) or XBL (compromised IPs) zones, both part of the combined ZEN list. According to a guide published by Teneo on 23 October 2026, quoting Spamhaus, CSS listings normally expire three days after the last detection, but a recurring problem means recurring listings.
What changed in DMARC with RFC 9989?
In May 2026 RFC 9989 was published on the Standards Track. It obsoletes RFC 7489, which had defined DMARC since 2015, and moves reporting into two separate documents: RFC 9990 for aggregate reports and RFC 9991 for failure reports. The practical changes:
- The pct, rf and ri tags are now historic, so you should not rely on them for a gradual rollout.
- New tags appear: t for test mode, np for non-existent subdomains, and psd.
- The DNS Tree Walk replaces the Public Suffix List for finding the organizational domain.
- A domain publishing p=reject must not rely solely on SPF for a DMARC pass, so DKIM signing is effectively required.
- Before moving to reject, the standard recommends publishing p=none for at least a month, then quarantine for an equally long period, and comparing the results.
Caveat: not every major receiver has announced full adoption of the new semantics yet, so a record such as p=reject with pct=25 may be interpreted differently by different receivers. The safest path is a clear policy that does not depend on pct.
Our measurement: email setup across 332 Egyptian domains
On 27 October 2026 (09:34 Cairo time) Smart One Group checked the DNS of every Egyptian (.eg) domain in the Tranco top-1M list (ID 262N9), 332 domains in total. We queried MX, SPF and DMARC, then tested forward-confirmed reverse DNS for the IPv4 addresses of the first two MX hosts.
| Indicator | Result |
|---|---|
| Domains with an MX record | 283 of 332 |
| Domains with SPF | 272 (9 of them publish more than one SPF record, an error that breaks validation) |
| Domains with a single DMARC record | 186 (56%), plus one with two conflicting records |
| Domains without a valid DMARC record | 146 (44%), including 107 that receive mail via MX |
| Policy (p=) distribution | none: 70, quarantine: 73, reject: 42, one record without p |
| Records using pct, ri or rf | 72 of 186 (39%) |
| Records with a rua report address | 125 of 186 (67%) |
| Records using the new np or t tags | 0 |
| MX host IPv4 addresses tested | 213: 191 pass FCrDNS, 10 have no PTR, 12 have a PTR that does not resolve back |
By suffix: of 87 government domains (gov.eg), 47 publish DMARC and only 34 enforce it; of 92 education domains (edu.eg), 42 publish and 18 enforce; of 90 commercial domains (com.eg), 69 publish and 42 enforce.
Limits: MX hosts receive mail and may differ from the IPs a company actually sends from, so the FCrDNS figure is a proxy, not a verdict on sending. The list covers the most popular Egyptian domains rather than all companies, and results are a point-in-time snapshot.
Who in Egypt is most exposed?
Companies that use Microsoft 365 or Google Workspace for daily mail are usually covered on HELO and PTR because the provider runs the servers. The problem shows up in side channels nobody watches:
- Clinic systems that send appointment reminders straight from the web server.
- ERP and accounting systems that send invoices and statements.
- HR and payroll systems that send payslips.
- Website contact forms that send through PHP mail on shared hosting.
- VPS servers still carrying the hosting provider's default hostname, so the HELO shows a name that is not yours.
- Printers, scanners and cameras sending alerts from behind the same NAT address as the mail server.
Spamhaus requirements checklist, step by step
1. Inventory everything that sends as your domain
List every system that sends mail as your domain: mail provider, billing system, newsletter platform, website, backups. DMARC aggregate (rua) reports are the best way to discover sources you did not know about.
2. Align HELO, PTR and A for each sending IP
Pick a name such as mail.example.com.eg, point its A record to the server, ask the server or hosting provider to set the PTR to the same name, and configure the mail server to announce it in HELO. Use the HELO checker on the Spamhaus page or the check address it lists.
3. One correct SPF record
Publish exactly one SPF record per domain with no more than ten lookups. We found 9 prominent Egyptian domains with more than one record, which alone makes validation fail.
4. Aligned DKIM signing
Enable DKIM for every source with a 2048-bit key, make sure the signing domain matches the From domain, and schedule annual key rotation.
5. DMARC without deprecated tags
Start at p=none with rua, then move to quarantine and reject after reviewing reports. Remove ri and rf, which RFC 9989 made historic. If pct is below 100 with quarantine or reject, deleting it means full enforcement at receivers that follow the new standard, so prepare your sources first or use t=y in the meantime.
6. Permission and list hygiene
Send newsletters only to confirmed subscribers, remove bouncing and inactive addresses, and never buy lists.
A practical 30-day plan
- Week 1: inventory, check HELO, PTR and A, and fix duplicate SPF records.
- Week 2: enable DKIM for all sources and publish DMARC at p=none with rua if missing.
- Week 3: read the reports and fix sources that fail alignment.
- Week 4: remove deprecated tags and schedule the move to quarantine after a month of monitoring, as the standard recommends.
If you run internal DNS resolvers, also see our guide to the 2026 root KSK rollover and our guide to accepting Arabic email addresses. Google has also required since February 2024 that sending IPs have valid forward and reverse DNS, as stated in the Gmail sender guidelines.
How Smart One Group can help
We configure DNS, PTR and mail servers as part of our hosting and servers and domains services, and we adapt the clinic, accounting and HR systems we build to send through an authenticated path. If you want your domain checked before enforcement starts, get in touch.
Frequently asked questions
Do the Spamhaus requirements apply to small companies?
Yes. The requirement covers every IP that sends email, regardless of company size or volume.
When exactly does enforcement start?
Spamhaus says it starts gradually in November 2026 and runs over several months, without a specific day, so it is best to finish the setup now.
I use Microsoft 365 or Google Workspace. Am I safe?
Usually on the provider's servers, but you still need SPF, DKIM and DMARC for your domain, and you must check any other system sending as you from its own server.
Should I remove pct from my DMARC record?
The tag is historic in RFC 9989, but do not delete a value below 100 until you are ready for full enforcement. Move between none, quarantine and reject directly while monitoring reports.
What if my server's IP gets listed?
Fix the cause first (HELO, PTR or a compromised device), then look up the IP in the Spamhaus reputation checker and follow its instructions.
Who sets the PTR record?
The owner of the IP space, meaning your server or internet provider, not your domain registrar. Request it in the control panel or from support.