Quick answer
An Outlook 5.7.501 bounce means access was denied because Microsoft classified the sender as banned: Microsoft Defender for Office 365, the advanced threat-protection layer still widely called ATP, blocked the message. The decision is reputation-driven and made on Microsoft's side, so sender-side configuration changes alone rarely clear it. The path forward is to identify why the IP or domain earned the classification, keep authentication clean, check your sending domain's blacklist status, and use Microsoft's sender support and delisting process. Microsoft's internal threat classification 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 indicates that Microsoft Defender for Office 365 blocked the message because it classified the sending infrastructure as a source of spam, phishing, or malware. Defender sits above Exchange Online Protection on tenants with higher licensing and asks a different question than the authentication gate. It does not ask whether the message is authenticated; it asks whether the sending IP or domain is trustworthy. Because that classification lives in Microsoft's reputation model, SPF, DKIM, and DMARC can all pass while Defender 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 5.7.500 high-SCL code. That sets it apart from the authentication codes 5.7.5 and 5.7.135, which a sender fixes directly in DNS, and from the recipient-policy 5.7.1 code.
Why Outlook returns 5.7.501
Defender refuses a message when its continuously updated reputation model has classified the sending IP or domain as a threat source. The underlying cause is usually something the sender can identify even though the classification 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. Defender's models also weigh authentication failures as an extra negative signal, so weak SPF, DKIM, or DMARC make a borderline reputation worse.
Because the decision is reputation-driven, repeated retries of the same mail tend to reinforce the negative classification rather than clear it. The classification is not something a sender can edit in DNS, which is why the remediation is a process of fixing the root cause and then requesting re-evaluation rather than 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 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 a prerequisite for any delisting request and removes one negative signal from Defender's model. 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 Defender's internal threat classification, because that reputation model 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 Defender has cleared the ban, and they do not reveal why Microsoft classified the sender in the first place. Confirming clean public signals is necessary groundwork for a delisting request, but the ban itself lifts only when Microsoft re-evaluates its own reputation data. Relaymetry checks the public baseline; it cannot see Microsoft's reputation or Defender classification, and it does not monitor or report changes to either.
What to change
Fix the root cause, clean the public signals, then use Microsoft's process. Remediate whatever earned the classification: secure a compromised mailbox, move off a degraded shared IP pool, or stop a campaign that looked like unsolicited bulk mail. Align DMARC, SPF, and DKIM with your From domain. Clear any public blocklist listing through that blocklist's own delisting process. Then submit a request through Microsoft's official sender support and delisting portal rather than retrying the blocked mail, because retries reinforce the classification. A receiving organization can also override Defender for a specific sender by adding a tenant allow entry, which is often the fastest resolution when a known partner is blocked because it does not wait on Microsoft re-evaluating a reputation score.