Quick answer
An Outlook 5.7.800 bounce means Microsoft blocked the message because the sending domain was banned for detected spam activity. The full text is Access denied, banned sender, and per Microsoft it specifically means the EHLO, P1, or P2 sender domain of the message was banned. This is a reputation and abuse block on the domain, not an authentication or content problem, so SPF, DKIM, and DMARC can all pass while the domain is still refused. Unlike the IP-scoped 5.7.511, a domain ban has no self-service delist portal: you fix the abuse cause first, then contact Microsoft Support to restore the domain's ability to send mail.
What the code means
Microsoft's NDR table defines 550 5.7.800 Access denied, banned sender as "The EHLO, P1, or P2 sender domain of this message was banned because of detected spam activity." The ban is applied to a sending domain — one of three domain identities Microsoft reads off the message:
- EHLO — the HELO/EHLO hostname your mail server announces when it opens the SMTP connection.
- P1 — the envelope sender, the
MAIL FROMdomain used during the SMTP transaction. - P2 — the header
Fromdomain that the recipient sees.
If any of those domain identities is on Microsoft's banned list, the message is refused. It helps to place 5.7.800 inside Microsoft's small family of "banned sender" codes, because they have different scopes and different fixes:
- 5.7.800 — the EHLO, P1, or P2 sender domain was banned for detected spam activity. Fix the abuse and contact Microsoft Support to restore the domain.
- 5.7.511 — the sending IP was banned. Fix the IP's reputation and use the delist portal.
- 5.7.501 / 5.7.502 / 5.7.503 — the sending account was banned for detected spam activity. Reset the account credentials and contact Microsoft Support.
A 5.7.800 is the domain-scoped member of that group. Knowing the scope tells you where to look: a domain ban points at how your domain has been used to send mail — a compromised mailbox, an abusive campaign, or an abuse association — not at a single connecting IP or one mailbox in isolation.
Why Outlook returns it
Microsoft bans a sending domain when its filters associate that domain with spam or abuse activity. The decision is reputation-driven and made on Microsoft's side. The common causes are:
- A compromised account or app sending spam as your domain. A breached mailbox, a stolen SMTP credential, or a misused application can blast spam under your domain identity, and the domain inherits the ban even after you regain control.
- A cold-outreach or unsolicited-bulk campaign that drew complaints. Mail that recipients did not ask for generates spam complaints and abuse signals; enough of them push the domain below Microsoft's threshold.
- The domain newly associated with abuse. A recently registered or recently repurposed domain that gets linked to abusive sending — sometimes through a shared platform or a prior owner — can be banned before it builds any legitimate history.
Because the block is on the domain's reputation, sender-side configuration changes alone rarely clear it. This is an abuse ban, not an authentication or content failure: passing SPF, DKIM, and DMARC does not lift it. You have to remove the abuse cause and then ask Microsoft to re-evaluate and restore the domain.
How to diagnose
Start by identifying which domain identity Microsoft banned. The ban can attach to the EHLO hostname, the P1 envelope MAIL FROM domain, or the P2 header From domain, and these are not always the same string. Read the full message source: the Received: headers, the SMTP MAIL FROM, and the visible From header tell you which domains were presented. When you send through a platform, the EHLO and P1 domains are often the platform's, while the P2 is yours — confirm which one is banned before you remediate.
Next, find the abuse the ban is responding to. Check for a compromised mailbox or credential, an application or script sending unexpectedly, and any recent campaign that may have generated complaints. The root cause has to be fixed before a restoration request will hold, because Microsoft re-evaluates the domain and finds the same signals if the abuse is still live.
Then confirm the rest of your authentication and public reputation is clean. A 5.7.800 is not an authentication failure, but Microsoft weighs authentication and reputation when it decides whether to restore a domain, so a clean SPF, DKIM, and DMARC posture and clear public blocklists strengthen the request. The Relaymetry blacklist checker queries the major DNSBLs for a domain or IP so you can see whether the listing is widespread or specific to Microsoft.
One thing a public check cannot tell you is Microsoft's internal reputation score for the domain. That model is private. The public blocklist status and your authentication posture are the groundwork for a restoration request; they are not the ban itself.
How to fix
The fix is remove-the-cause first, then request restoration. Submitting a restoration request before the underlying abuse is fixed tends to fail, because Microsoft re-evaluates the domain and finds the same signals.
- Identify the banned domain identity — the EHLO hostname, the P1 envelope
MAIL FROMdomain, or the P2 headerFromdomain — from the message source andReceived:headers. - Find and stop the abuse cause. Lock down a compromised mailbox or rotate a leaked credential, disable any application or script sending spam, and stop any unsolicited-bulk or cold-outreach campaign that drew complaints.
- Align SPF, DKIM, and DMARC for the affected domain so the sender presents as fully authenticated when Microsoft re-evaluates.
- Check the domain against public blocklists and clear any separate DNSBL listings through each blocklist's own process; a clean public reputation supports the Microsoft request.
- Contact Microsoft Support to restore the domain. Per Microsoft, to restore this domain's ability to send mail you must contact Microsoft support — there is no self-service delist portal for a domain ban. Provide the full NDR code (
550 5.7.800), the banned domain, and a brief description of the remediation. - Do not retry the blocked campaign against the ban while you wait. Retries do not clear a reputation block and add noise; send a small test only after the domain is restored.
- For a known partner recipient, ask their administrators to add a tenant allow entry for your sending domain as a faster interim path while the restoration is processed.
What this does not prove
A public DNS and blacklist check confirms whether your domain or IP is listed on public blocklists and whether your SPF, DKIM, and DMARC records are in order. It cannot read Microsoft's internal reputation model, confirm that a specific past message was blocked for this exact reason, or guarantee that a restoration request will be accepted. Microsoft's restoration decision is made on its side after it re-evaluates the domain.
Relaymetry checks the public signals that a restoration request rests on. It does not have access to Microsoft's internal threat classification, your sending platform's configuration, or the exact filtering decision applied to a given message.