Quick answer
An Outlook 5.7.500 bounce is an access-denied rejection driven by a high Spam Confidence Level: Exchange Online Protection scored the message or its source as spam with high confidence. This is a reputation and content outcome, not an authentication failure, so authentication can be perfectly valid while this code still appears. The levers you control are indirect: tighten DMARC alignment, check your sending IP and domain against public blocklists, and review recent changes to your sending pattern. Microsoft's internal Spam Confidence Level is not visible from public DNS, so a public check cannot read the score that produced the bounce.
What the 5.7.500 code means
The Spam Confidence Level, or SCL, is the numeric score Exchange Online Protection assigns to inbound mail on a scale from -1 to 9, where higher values mean rising spam confidence. A 5.7.500 code reflects a high SCL: the filter scored the message or its source as spam with high enough confidence to deny access outright rather than route the mail to the Junk folder. It is the bulk-spam counterpart to the threat-protection rejection behind the 5.7.501 code.
This is a reputation code. The Outlook pillar groups the 5.7.x codes by who can fix them, and 5.7.500 is a reputation-driven rejection that a sender influences over time but does not control on a short timescale. That sets it apart from the authentication codes 5.7.5 and 5.7.135, which a sender fixes directly in DNS.
Why Outlook returns 5.7.500
The cause is usually IP or domain reputation rather than a single message defect. Common triggers are a shared IP with a poor neighborhood, a recent volume spike, a rise in spam complaints, or a list-quality problem such as sending to addresses that no longer engage. Content can contribute too: risky links, link-shortener domains, mismatched display names, and attachment types that draw extra scrutiny all push the score up. Authentication can be perfectly valid while any of these factors drives the SCL high enough to produce a 5.7.500.
This is why a 5.7.500 is harder to resolve than an authentication bounce. Editing DNS records does not lower an SCL that is driven by reputation, volume, or content. The score is recalculated by Microsoft from signals that change as your sending behaviour changes, not from a record you can publish.
How to diagnose a 5.7.500
Read the headers of a real message that did reach a Microsoft mailbox, because the SCL is recorded there. The X-Forefront-Antispam-Report header contains an SCL: field with the numeric score, alongside a CAT: field that names the filtering category and an SFV: field that records the spam filtering verdict. Reading these from a delivered message is the most reliable way to learn how Exchange Online Protection actually scored a specific send, as opposed to how a DNS lookup suggests it should have scored.
Then check the public signals you can see. Confirm DMARC, SPF, and DKIM align with the visible From domain, because authentication failures add negative weight even though they are not the primary cause here. Check the sending IP and domain against public blocklists. The Relaymetry blacklist lookup checks public blocklist membership for an IP or domain, and the DMARC checker confirms the published policy and alignment. Look for a recent change that could have shifted reputation: a new IP pool, a platform migration, a volume spike, a cold-outreach campaign, or a list import.
What this does not prove
A public DNS and blocklist check reads only public signals. It cannot read Microsoft's internal Spam Confidence Level, because the SCL is computed inside Exchange Online Protection from reputation, volume, complaint, and content signals that no public lookup exposes. A clean DMARC result and an absence from every public blocklist do not guarantee that the SCL has dropped, and they do not reveal the score Microsoft assigned to the message that bounced. The only place to read an actual SCL is the X-Forefront-Antispam-Report header of a delivered message. Relaymetry checks the public baseline; it cannot see sender reputation or the SCL at any mailbox provider, and it does not monitor or report changes to either over time.
What to change
Tighten what you control and let reputation recover. Align DMARC, SPF, and DKIM with your From domain so authentication adds no negative weight. Remove any public-blocklist listing through that blocklist's own delisting process, after fixing the cause of the listing. Reduce complaint drivers: suppress recipients who have complained, stop sending to addresses that never engage, and avoid sudden volume spikes from a cold list. Reputation recovers gradually as clean sending accumulates. The lever is consistent low-complaint sending over time, not a single configuration change.