A temporary error that behaves like a permanent one. Dashboards that contradict the rejections. A support pipeline that answers in circles. Meet S3150's slipperier sibling, and the closest thing 2026 has to a defining Microsoft deliverability problem.
In February, we published a post about S3150, the most frustrating error code in email deliverability. Two days later, Microsoft's filters delivered a sequel.
Starting on February 23, 2026, email operators around the world began seeing this in their logs:
451 4.7.650 The mail server [x.x.x.x] has been temporarily rate limited due to IP reputation. For e-mail delivery information, see https://aka.ms/postmaster (S775) [Name=Protocol Filter Agent][AGT=PFA]
The February wave eventually subsided. The error didn't. New S775 reports have surfaced on the mailop operators' list and Microsoft's own Q&A forums in May, in July, and as recently as August 4, each following the same script: an unexplained rate limit, self-service tools that see nothing wrong, and a support process that leads nowhere.
This is what months of public reports tell us about S775: what it is, what happened in February, why it keeps coming back, and what you can realistically do when it hits you.
What Is S775, Exactly?
Familiar answer: nobody outside Microsoft is entirely sure.
Here's what can be established from the error itself and from Microsoft's published documentation:
- It's a 451, which in SMTP means temporary failure, retry later. That's meaningfully different from S3150, which returns a 550 permanent failure. The retry contract is, at least nominally, intact.
- It's stamped
[Name=Protocol Filter Agent][AGT=PFA]: the same filtering agent the community associates with S3150's IP-level blocks. S775 appears to be the throttling flavor of the same machinery. - It affects Microsoft's consumer platform: outlook.com, hotmail.com, live.com, and msn.com addresses.
- It is not documented. Microsoft's postmaster troubleshooting page publishes a table of SMTP error codes (421 RP-001 through 550 OU-002). S775 and 4.7.650 appear nowhere in it. The closest official document is a Microsoft Learn page titled "Fix NDR error 451 4.7.500-699 (ASxxx) in Exchange Online". That page describes graylisting for new senders in Exchange Online Protection, never mentions 4.7.650 or S775, and covers the enterprise platform rather than the consumer one where S775 actually fires.
One more thing the error text doesn't tell you: "rate limited" suggests some mail gets through. During the February event, operators reported that in practice delivery dropped to effectively zero.
The Week of February 23
The scale of the February 2026 event is worth putting on record, because it's the best-documented S775 episode we have.
On February 23, a mail hosting operator opened a thread on mailop titled "Outlook rate limiting, just us?", reporting 451 4.7.650 rejections despite strict outbound spam controls and active feedback-loop processing. The answer to "just us?" arrived fast. Within days the thread had drawn more than two dozen replies from operators across hosting providers, ISPs, and ESPs.
An operator at a large Dutch ISP described the shape of the problem:
"We are having the same issue. Our IPs disappeared from our SNDS dashboard. [...] Right now about 10 of our IPs are rate limited, severely impacting our deliverability to microsoft customers. We have hundreds of thousands of mailboxes and can't get our queues out."
And the part that should worry anyone who trusts dashboards:
"After we reinstated one, it shows all green with no abuse hits. But that IP is rate-limited anyways and we cant get our queues sent there."
His conclusion: "I think microsoft has moved to a new system that's not working very well."
On Microsoft's Q&A forum, a parallel thread started by an ESP that reported serving millions of users (first one IP rate limited, then all of its ranges across the EU and US) collected more than 60 commenters reporting the identical error within days, most with an onset clustered around 19:53 UTC on February 23. The affected infrastructure spanned SendGrid dedicated IPs, OVH addresses, and self-hosted Postfix boxes. Compliant SPF, DKIM, and DMARC everywhere. Complaint rates under control. Same rejection for everyone.
Microsoft's only public acknowledgment was a banner on the sender support page:
"We are aware of an issue that may result in certain IP addresses being temporarily rejected at higher rates. We are actively investigating the issue."
No incident ID. No post-mortem. And when the event ended around February 25-26, it ended the way it began: silently. One operator reported over 300,000 451 4.7.650 errors one day and zero the next, with no update on any of the support tickets that had been filed. The community's read, based on the timing, was that Microsoft deployed a fix on its side; the tickets themselves resolved nothing.
We wrote about that chaotic week at the time in The Week Microsoft Broke Email for Everyone. What we didn't know then: February wasn't the end of S775. It was the beginning.
It Never Really Ended
May 2026. A mailop thread titled "Persistent Outlook.com S775 rate limiting since May 8?" describes multiple IPs failing for a week. The operator retried at 12, 24, and 48 hours. No change. Microsoft support replied: "We have implemented mitigation for your IP, and this process may take 24-48 hours to replicate completely throughout our system." The mitigation was "implemented" repeatedly. The error continued regardless.
August 2026. A fresh thread, "hotmail rate limiting my IPs (S775)", opened on August 4. A provider's two sending IPs were rate limited after a customer, in the poster's words, "sent a newsletter containing errors to a recipient list." This time SNDS did show the IPs in the red. The support ticket drew an automatic reply that the IPs "do not qualify for mitigation." A detailed follow-up went unanswered. The operator's questions to the list are the questions everyone has: how long do these blocks last, and does Microsoft ever actually respond?
And between the mass events, the slow cases grind on. In one Microsoft Q&A thread from March, a low-volume sender reported S775 rejections while the delist portal cheerfully returned:
"Nothing was detected to prevent your mail from reaching Outlook.com customers."
SNDS showed no data at all; it generally doesn't for small senders. After three escalations over a week, the forum moderator's final answer was remarkably candid:
"As this issue is affecting many users and the backend team has confirmed they are actively investigating it, there are no additional steps we can take at this time."
Notice the asymmetry. In the February mass event, large ESPs and ISPs were restored within roughly 24-72 hours. The isolated cases since, disproportionately smaller senders, report timelines of weeks to months, or no resolution at all.
The Feedback Loop Is Broken
Read enough S775 reports and four contradictions repeat, almost word for word:
1. The error says you're rate limited. The delist portal says nothing is wrong. "Nothing was detected to prevent your mail from reaching Outlook.com customers", while the 451s keep coming.
2. SNDS disagrees with the filter. Operators have documented every combination: IPs vanishing from the SNDS dashboard entirely, IPs showing "all green with no abuse hits" while rate limited, and IPs turning red only after the limiting began. Whatever reputation system drives S775, SNDS is not a reliable window into it.
3. Support confirms mitigation. The error continues. The May thread's "we have implemented mitigation" loop is the canonical example.
4. Or you simply "do not qualify." The August case got an automated rejection with no published criteria for what qualifies and no path to appeal.
There's also the small indignity of the process itself: Microsoft's sender support forms require signing in with a Microsoft account. When an operator raised this on mailop in July, veterans confirmed it has essentially always been that way. One noted he'd never found a Microsoft reporting form that didn't require an account; another advised, pragmatically: create the free account, because "in a perfect world, you shouldn't have to do this. We don't live in a perfect world."
How much does the form actually help? One low-volume sender, blocked with a related block-list code (S3140) since the spring, reported on mailop in July: ten weeks of form submissions and follow-ups produced no response and no change; the block eventually "lifted spontaneously after a couple of months." His verdict: "I wouldn't put any value in the form or the process behind it."
Meanwhile, the Lights Are Going Out
Here's what makes 2026's S775 story genuinely worse than a filtering hiccup: while the rate limiting kept resurfacing, the visibility tools senders rely on were being cut back.
Over the course of 2026, Microsoft overhauled SNDS and the Junk Mail Reporting Program. The postmaster portal moved to a new home, with legacy automated SNDS URLs deprecated in June. JMRP complaint reports switched to header-only format (message bodies removed, complainant addresses redacted), breaking suppression workflows that depended on knowing who complained. Then, effective July 22, 2026, Microsoft removed spam-trap hit counts from SNDS data reports entirely, explaining the change was made "to protect the integrity and effectiveness of our anti-abuse systems." The transition wasn't smooth either: in mid-June an operator reported the JMRP page returning server errors while report formats flip-flopped, causing, in his word, "havoc" in abuse handling.
The human channel thinned out too. Microsoft's long-time representative in the email operations community, a genuinely appreciated presence, retired earlier this year. In July, an operator asked mailop directly: is anyone from Microsoft still on this list? Plenty of people replied. None of them were from Microsoft.
So the 2026 equation for senders looks like this: more unexplained rate limiting, less reputation data, fewer complaint details, and no humans on the channel where operators have compared notes for two decades.
What You Can Actually Do
The honest playbook, assembled from what operators have documented actually working:
Treat it as temporary, because technically it is. S775 is a 451. Unlike S3150's bogus 550, the SMTP retry contract is intact: keep the mail queued and retry with sensible backoff. Documented resolutions range from hours to days (the mass events) to, in the worst isolated cases, months.
Pattern-match your own telemetry first. Alert on 4.7.650 and S775 in your deferral logs, broken down per IP and per destination domain, and note the onset time. This matters for a practical reason: if the limiting started for you at the same moment it started for everyone else (February's 19:53 UTC cluster), the problem is on Microsoft's side and no amount of list hygiene will fix it. If it started right after a specific campaign, like August's errored newsletter, you have an actual lead. Your logs are the one dataset in this story that never contradicted itself.
Check SNDS, then distrust it appropriately. Register your ranges and look, but remember the documented failure modes in both directions. Green does not mean unthrottled; absent data does not mean unmonitored.
File the ticket anyway, and push past the auto-reply. The single positively documented fix in the February event came roughly 23 hours after a ticket was escalated, with Microsoft replying that "the connection and throttling limitation against your IP has been set to a more appropriate level based on your reputation." The first response will likely be automated and useless. Persistence occasionally isn't.
Slow your delivery to Microsoft domains. This is community folklore rather than documented Microsoft guidance (there are no published thresholds to aim for), but spacing out delivery attempts to consumer Microsoft domains is the most commonly repeated operator advice for keeping a temporary rate limit from escalating.
Give critical mail an exit route. If password resets and receipts are stuck behind an S775'd IP, the one cleanly documented workaround is routing around it: one blocked operator relayed Microsoft-bound mail through an alternate host while waiting out a block that took months to lift on its own. Whether a fresh, unwarmed IP helps or hurts is exactly the question operators are still debating; a cold IP has no reputation, which is its own risk.
Write everything down. Volumes, timestamps, error strings, SNDS state, ticket numbers, form submissions. Every documented case that eventually got traction had a paper trail.
The Bigger Picture
S3150 and S775 are two flavors of the same problem. One returns a permanent error that often isn't permanent; the other returns a temporary error that sometimes isn't temporary. Both come from the same filtering agent. Both are undocumented. Both route the sender into self-service tools that contradict the rejections and a support pipeline that answers in form letters.
What's changed in 2026 is the direction of travel. Google spent this year rolling out plain-language deliverability verdicts in Postmaster Tools, moving toward telling senders, in words, why their mail is treated the way it is. Microsoft spent this year removing trap-hit data from SNDS, stripping complaint details from JMRP, and going quiet on the operator channels, all while an undocumented rate limit cycled through its third recurrence.
The lesson we keep coming back to: you cannot outsource deliverability visibility to the mailbox provider. Microsoft's own dashboards disagreed with Microsoft's own filters, publicly, for months. The senders who understood what was happening to them in February, May, and August were the ones watching their own deferral and bounce telemetry closely enough to see the pattern the dashboards missed. That's not a Microsoft-specific lesson. It's just the place where it's currently being taught most expensively.
If S775 is hitting you right now: you're not alone, you're probably not doing anything wrong, and the operator community has, as usual, better documentation than the vendor.
Seeing 4.7.650 in your logs? Engagor ingests raw SMTP events across your ESPs and MTAs and flags deferral anomalies like S775 the moment they start, with the per-IP, per-domain timeline you'll need whether you're diagnosing it or escalating it.
Frequently Asked Questions
What does "451 4.7.650 temporarily rate limited due to IP reputation (S775)" mean?
It means Microsoft's consumer mail platform (outlook.com, hotmail.com, live.com, msn.com) is deferring mail from your IP because its internal reputation system has flagged it. The code is issued by Microsoft's Protocol Filter Agent and is not documented anywhere in Microsoft's published error-code references. It is a temporary (4xx) rejection, so receiving servers expect you to retry.
How long does S775 rate limiting last?
There is no published duration. In the documented mass event of February 2026, most senders were restored within one to three days, apparently by a Microsoft-side fix. In isolated cases since, operators have reported timelines from days to multiple months, including blocks that lifted spontaneously after support channels produced nothing.
Is 451 4.7.650 the same as 451 4.7.500 "Server busy"?
No. Microsoft's documentation covers 451 4.7.500-699 as graylisting/IP-throttling in Exchange Online Protection, typically triggered by new sending patterns, and prescribes building sending history over a few days. But that document never mentions 4.7.650 or S775, which fire on the consumer platform against established senders, including, in February 2026, senders whose patterns hadn't changed at all.
What's the difference between S775 and S3150?
S3150 is a 550 permanent rejection ("part of their network is on our block list"): Microsoft refusing your mail outright. S775 is a 451 temporary deferral based on IP reputation. Both are emitted by the same Protocol Filter Agent, and neither appears in Microsoft's published documentation. Community reports suggest sustained S775 throttling and S3150 blocks can be related stages of the same reputation machinery, but Microsoft has never confirmed how the codes relate.
Does the Microsoft delist portal help with S775?
Usually not. The delist portal at sender.office.com addresses banned-IP errors (550 5.7.606-649), and S775-affected senders commonly get back "Nothing was detected to prevent your mail from reaching Outlook.com customers" while the rate limiting continues. The path that has documented results is filing a sender support ticket (olcsupport.office.com, Microsoft account required) and escalating past the automated first response.
This post is based on public discussions from the mailop mailing list (February-August 2026), public Microsoft Q&A threads, Microsoft Learn and postmaster documentation, and reporting by Spam Resource and emailexpert. No private communications were used. Quotes are reproduced from public archives.
