Quick answer
An Outlook 5.7.501 bounce is Microsoft's "Access denied, spam abuse detected": the sending account was banned because Microsoft detected spam activity from it. The decision is made on Microsoft's side from internal signals, so sender-side configuration changes alone rarely clear it. Microsoft's remediation is to verify the underlying account issues are resolved, reset the account credentials, and contact Microsoft Support through your regular channel; for the IP-range variant, "550 5.7.501 spam abuse detected from IP range", use the Microsoft delist portal. Keep authentication clean and check your sending domain's blacklist status to prepare that request. Microsoft's internal spam-abuse decision is not visible from public DNS, so a public check cannot read the reputation that produced the ban.
What the 5.7.501 code means
A 5.7.501 code is Microsoft's "Access denied, spam abuse detected": the sending account was banned because Microsoft detected spam activity from it. It is a spam-abuse and account-ban decision, not an authentication check. It does not ask whether the message is authenticated; it records that the account itself was banned for detected spam abuse. Because that ban lives in Microsoft's internal reputation data, SPF, DKIM, and DMARC can all pass while Microsoft still refuses the message.
This is the hardest of the five Outlook 5.7.x codes to clear from the outside. The Outlook pillar puts it in the reputation category with the high-SCL code. That sets it apart from the authentication codes 5.7.23 and 5.7.509, which a sender fixes directly in DNS, and from the recipient-policy 5.7.1 code.
Why Outlook returns 5.7.501
Microsoft returns 5.7.501 when it has detected spam activity from the sending account and banned it. The underlying cause is usually something the sender can identify even though the ban itself is Microsoft's: a compromised mailbox sending spam, a poorly maintained shared IP pool with bad neighbours, a sudden cold-outreach campaign that looks like bulk unsolicited mail, or a malware-infected web property linked from the messages. Authentication failures make a borderline reputation worse, so weak SPF, DKIM, or DMARC add negative weight, but the trigger is the detected spam abuse.
Because the ban is a spam-abuse decision on the account, repeated retries of the same mail tend to reinforce it rather than clear it. The ban is not something a sender can edit in DNS, which is why the remediation is to verify the account issues are resolved, reset the account credentials, and contact Microsoft Support rather than make a single record change.
How to diagnose a 5.7.501
Start by looking for the root cause on your side, because that is what any support or delisting request must address. Check whether a mailbox in your domain has been compromised and is sending spam. If you send from a shared IP pool at a platform, ask whether the pool's reputation has degraded. Review recent sending changes: a new cold-outreach campaign, a list import, or a volume spike that coincides with the first 5.7.501 bounce.
Then check the public signals you can see. Confirm DMARC, SPF, and DKIM align with your From domain, because clean authentication is useful preparation for a support request and removes one negative signal. Check your sending domain's blacklist status against public blocklists, since a public listing both contributes to the poor reputation and gives you a concrete listing to clear. The Relaymetry blacklist lookup checks public blocklist membership for your sending domain or IP.
What this does not prove
A public blacklist and DNS check reads only public signals. It cannot read Microsoft's internal spam-abuse decision or the account ban, because that reputation data is computed inside Microsoft from signals that no public lookup exposes. A clean DMARC result and absence from every public blocklist do not prove that Microsoft has lifted the ban, and they do not reveal why Microsoft banned the account in the first place. Confirming clean public signals is necessary groundwork for a support or delisting request, but the ban itself lifts only when Microsoft re-evaluates its own reputation data after you reset credentials and contact support. Relaymetry checks the public baseline; it cannot see Microsoft's internal reputation or the spam-abuse ban, and it does not monitor or report changes to either.
What to change
Verify the account issues are resolved, reset the account credentials, then contact Microsoft Support. Remediate whatever triggered the spam-abuse detection: secure a compromised mailbox, move off a degraded shared IP pool, or stop a campaign that looked like unsolicited bulk mail. Reset the credentials of the banned sending account, as Microsoft requires before the ban can be lifted. Align DMARC, SPF, and DKIM with your From domain and clear any public blocklist listing through that blocklist's own delisting process so the public baseline is clean. Then contact Microsoft Support through your regular channel to request the ban be lifted rather than retrying the blocked mail, because retries reinforce the ban. For the IP-range variant, "550 5.7.501 spam abuse detected from IP range", use the Microsoft delist portal instead. A receiving organization can also override the block for a specific sender by adding a tenant allow entry, which is often the fastest interim resolution when a known partner is blocked because it does not wait on Microsoft re-evaluating a reputation score.