Quick answer
A high Spam Confidence Level (SCL) means Exchange Online Protection scored your mail as spam on its -1 to 9 scale. That is a filtering and reputation signal, not a hard NDR: high-SCL mail typically lands in the Junk folder rather than bouncing, and there is no public Microsoft "5.7.500" code for it. A sudden volume spike can instead trip the transient throttle 451 4.7.500-699 Access denied, please try again later, which lifts shortly on its own. This is not an authentication failure, so SPF, DKIM, and DMARC can all pass while the SCL stays high. The durable levers are authentication alignment, blacklist hygiene, and stable sending patterns. Microsoft's internal SCL is not visible from public DNS, so a public check cannot read the score itself.
What the SCL is
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. It is a filtering and reputation signal, not a status code. A high SCL is what drives Junk-folder placement: the filter judges a message likely to be spam and routes it away from the inbox rather than returning a permanent rejection. There is no public Microsoft NDR code "5.7.500" for high spam confidence; high-SCL handling is delivery to Junk, not a specific bounce.
The one code Microsoft documents in that numeric range is transient, not permanent: 451 4.7.500-699 Access denied, please try again later. Microsoft describes it as suspicious activity that temporarily restricts sending for further evaluation, and the restriction is lifted shortly if the activity is valid. That is short-lived IP throttling — for example after a volume spike — and it is unrelated to a fixed high-SCL rejection.
Why a high SCL happens
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 send mail to Junk.
This is why a high SCL 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. This sets it apart from the authentication codes 5.7.23 and 5.7.509, which a sender fixes directly in DNS, and from the spam-abuse account ban behind the 5.7.501 code.
How to diagnose a high SCL
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. If a volume spike instead produced a transient 451 4.7.500-699 deferral, that resolves on its own as you ramp sending down to a steady rate.
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 a given message. 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 durable levers are authentication alignment, blacklist hygiene, and stable sending patterns over time, not a single configuration change.