Why does Outlook say my domain is listed in Spamhaus when it is not?
Updated on 1 Oct 2026: We added last-hop checks for forwarded and relayed mail and sharpened the steps for clean Spamhaus lookups.
Outlook says your domain is listed in Spamhaus when it is not because the rejection can name a different identity than the domain you checked. In a 550 5.7.1 S8001 or S8002 bounce, the wording points to the HELO or Mail From domain. A Client host bounce points to the connecting IP. A clean lookup of your visible From domain does not clear those other identities.
If Spamhaus shows no current listing for the exact identity, there is nothing to remove for that identity. Save the full non-delivery report (NDR), check the identity Microsoft named, and trace the last sending hop. A recent removal, resolver issue, or incorrect receiver-side result can explain a continued rejection.
What the Outlook error means
The wording matters. A bounce that says Helo domain is listed in Spamhaus is different from one that says MailFrom domain is listed in Spamhaus. Both are domain blacklist messages, but they identify different parts of the SMTP conversation.
Sanitized Outlook rejectiontext
Action: failed Status: 5.7.1 Remote-MTA: dns; hotmail-com.olc.protection.outlook.com Diagnostic-Code: smtp; 550 5.7.1 Service unavailable, Helo domain is listed in Spamhaus. To request removal from this list see https://www.spamhaus.org/query/lookup/ (S8001) [DBAEUR03FT004.eop-EUR03.prod.protection.outlook.com]
This rejection comes from Microsoft's receiving infrastructure, not the Outlook app on a computer or phone. The Remote-MTA field and the server name in square brackets identify the gateway that issued the SMTP response.
A Microsoft Q&A thread shows the same pattern with an S8002 rejection for a Mail From domain. The Spamhaus DBL documentation says DBL data can be checked against the HELO string, Mail From domain, rDNS-linked domain, and domains in message content. The visible From domain can therefore look clean while another related domain triggers the rejection.
Microsoft Outlook on the web showing a 550 5.7.1 HELO-domain Spamhaus rejection.
|
|
|
|---|---|---|
HELO | Server greeting name | HELO hostname and its DNS |
Mail From | Envelope sender | Envelope sender domain |
Client host | Connecting server IP | Exact IPv4 or IPv6 address |
S8001 | HELO-domain rejection | Announced HELO name |
S8002 | Mail From rejection | Envelope domain |
Common Outlook rejection terms and what to check first.
Read the literal identity
Start with the object named in the NDR. The code and wording determine which lookup to run.
- For HELO, check the hostname the last sending server announced and its DNS.
- For Mail From, check the envelope sender domain, which can differ from the visible From address.
- For Client host, check the exact connecting IP, including whether it is IPv6.
- Check domains in message links only when the rejection stage or wording points to content.
Why the lookup can be clean
A clean Spamhaus lookup does not prove Microsoft invented the error. It shows that the object you checked is not currently listed in that lookup. The gap is often an identity mismatch, DNS resolver problem, or receiver update lag after a removal.
- You checked the visible From domain, but the bounce names the HELO, Mail From domain, connecting IP, or another domain.
- A recently removed listing can still be cached by a receiving network. Spamhaus says this normally clears in one to two hours, although rare sync problems last longer. See the Spamhaus FAQ.
- The receiving network's DNS resolver can return stale or incorrect blocklist data.
- A rejection can cite Spamhaus even when the exact object is clean. The receiving network must trace its own decision.
- A new HELO name, sending IP, relay, or envelope sender can expose a problem that did not affect earlier mail.
What senders often check
- The website domain used by the brand.
- The root domain without its subdomains.
- The visible From address shown to recipients.
What Microsoft can check
- The HELO hostname announced by the connecting server.
- The Mail From or Return-Path domain.
- The connecting IPv4 or IPv6 address and related domains.
Five message identities: sending IP, HELO, Mail From, visible From, and link domains.
Confirm where the rejection happened
Before changing DNS, confirm which mail server issued the rejection. Outlook is the mailbox brand, but an SMTP response can come from Microsoft's receiving gateway, your own mail gateway, or an intermediate provider. The rejecting server controls the lookup that produced the block.
- Read Remote-MTA and Diagnostic-Code in the full NDR to identify the server that returned the rejection.
- Check the bracketed host. A name ending in prod.protection.outlook.com points to Microsoft's receiving infrastructure.
- If the rejecting host belongs to your gateway or provider, send that operator the full bounce. Its resolver or filtering rule generated the result.
- Identify who controls the outbound IP, PTR, HELO, and Mail From domain. On shared infrastructure, this is often the sending provider.
Fix the identity at its owner
If a provider controls the rejected HELO, PTR, sending IP, or envelope domain, changing your visible From domain or unrelated DNS records will not repair it. Give the provider the full NDR, UTC timestamp, rejecting gateway name, and rejected identity.
Check the last hop into Microsoft
A relay, forwarder, or outbound pool can change the connection Microsoft sees. The IP of your website or original mail server is not necessarily the IP in a Client host rejection. This is especially relevant when a provider rotates outbound IPs or sends over both IPv4 and IPv6.
- Compare the NDR's Client host IP with the IP your provider says connected to Microsoft for that message.
- Ask the provider for the HELO name, envelope sender, and outbound IP used on the failed attempt, not just its default configuration.
- If a forwarder is involved, inspect the forwarding server's IP and HELO. Microsoft evaluates the server that makes the final SMTP connection.
- For intermittent failures, compare successful and failed attempts. A single bad IP or IPv6 path in a pool can explain why only some messages bounce.
Keep the recipient, UTC timestamp, sending IP, rejecting Microsoft hostname, and full diagnostic line together. Those details let the operator trace the specific attempt instead of guessing from a later clean lookup.
The fastest diagnostic path
Start with the NDR, then test the exact identities. A generic blocklist (blacklist) search can miss the object Microsoft checked.
- Save the full NDR, including S8001, S8002, or Client host wording, timestamp, Remote-MTA, and diagnostic code.
- Record the connecting IP, HELO name, Mail From domain, visible From domain, DKIM d= domain, and message link domains.
- Mark which identities belong to you and which are controlled by a mail provider or forwarder.
- Check the named object in Spamhaus first. Then use Suped's domain health checker for related SPF, DKIM, and DMARC setup issues.
- Send a real message and inspect its headers with Suped's email tester to confirm the authentication path. A rejected message may have no delivered headers, so use the NDR and server logs for that attempt.
- If the exact object remains clean and only Microsoft rejects the mail, follow the Outlook blocking guide to prepare a receiver-side case.
Identity checklisttext
Connecting IP: 203.0.113.25 PTR name: mail.example.com HELO name: mail.example.com Mail From: bounce.example.com Visible From: example.com DKIM d=: example.com DMARC domain: example.com Message links: example.com, links.example.com
For a one-off rejection, the checklist is enough. For a domain tied to customer operations, Suped's blocklist monitoring preserves listing history. A clean lookup after the fact does not show what was listed when Microsoft rejected the message.
Blocklist checker
Check your domain or IP against 144 blocklists.
If the exact object has a live listing, investigate that dataset and the activity behind it. If it stays clean while fresh Microsoft bounces continue, preserve the evidence and ask the receiving network to review its result.
What to fix first
The fix depends on whether the exact object is listed. When it is clean, avoid changing unrelated DNS records. Keep the mail path stable, collect a fresh rejection, and correct any separate setup fault you can verify.
Do not chase a nonexistent delisting
If Spamhaus does not list the identity, there is no removal request to make for it. After a recent removal, Spamhaus advises waiting one to two hours. If the exact object remains clean and fresh bounces continue, contact the rejecting network with the NDR and lookup evidence.
- For a clean result, give the rejecting network the NDR, UTC timestamp, connecting IP, HELO, and lookup result.
- For a broken HELO, use a valid hostname with forward and reverse DNS that identifies the sending server.
- For an SPF failure, authorize the actual sending service and check the lookup limit.
- For a DMARC failure, correct SPF or DKIM alignment separately; DMARC does not remove a Spamhaus listing.
If you find a real Spamhaus listing, identify the dataset, stop the activity that caused it, then follow the removal process for the exact object. The Spamhaus blocking guide covers listed domains and IPs.
Where Suped fits
Suped is our DMARC and email authentication platform. Its DMARC reporting, SPF and DKIM visibility, blocklist checks, and alerts help track the sender path and reputation over time. It cannot delist an identity that Spamhaus does not list.
Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
For teams managing several domains, Suped keeps authentication results and blocklist history together. That helps assemble evidence when Microsoft is the only receiver rejecting mail.
- Track current and historical listings for the IPs and domains tied to your senders.
- Find SPF, DKIM, and DMARC alignment gaps that need separate correction.
- Get alerts when a listing or authentication failure appears instead of discovering it through bounces.
- Use the same workflow across client domains when managing several senders.
If you are still mapping the basics, start with blocklists and the exact bounce evidence. Add monitoring once the sender path is clear.
When it is really Spamhaus
Sometimes the Spamhaus listing is real. A blocklist or blacklist result can involve a domain or an IP. The dataset tells you what type of problem to investigate.
|
|
|
|
|---|---|---|---|
DBL | Domain | Domain reputation or abuse | Check the listed domain and its use |
CSS | IP or IPv6 range | Recent low-reputation mail | Inspect outbound mail and server logs |
PBL | IP range | Direct-to-MX mail from policy range | Use an authorized mail relay |
XBL | IP | Compromised host or proxy abuse | Investigate and clean the host |
Dataset clues to separate domain and IP reputation problems.
Signs of a real listing
- The exact domain or connecting IP appears in a current Spamhaus lookup.
- Fresh bounces from different receivers point to the same listed object.
- Sender logs show the activity or configuration behind the listing.
If a bounce refers to Spamhaus SBL or XBL, focus on the connecting IP and host. For those bounce patterns, use the Spamhaus bounce guide and retain the Outlook-specific NDR.
What to do next
Read the literal rejection first. S8001 points to HELO, S8002 points to Mail From, and Client host wording points to the connecting IP. Check that exact object before deciding who should act.
- If it is clean, retain the evidence and ask the rejecting network to review repeated bounces.
- If it is listed, stop the cause and request removal for the exact listed object.
- If the path is unclear, compare a fresh failed attempt with a successful one and ask the sending provider for the last-hop details.
- If the problem recurs, use Suped to track DMARC results, sender sources, and blocklist events over time.
Frequently asked questions
Microsoft's receiving infrastructure can use Spamhaus data in filtering decisions. The Outlook app itself does not issue the SMTP rejection.
HELO is the name a server announces during an SMTP connection. Mail From is the envelope sender domain used for bounces and usually for SPF checks. Either can differ from the visible From domain.
If the exact identity is clean, Spamhaus has nothing to remove for it. Keep the lookup result and investigate the sending path with your mail provider or the rejecting network.
Spamhaus says a recently removed listing normally clears at receivers within one to two hours. If fresh Microsoft rejections continue after the exact object is clean, send the NDR and lookup evidence to the rejecting network.
DMARC does not remove a blocklist or blacklist result. DMARC reports help identify legitimate and unauthorized sending sources, while a Spamhaus rejection needs investigation of the named domain or IP.
