451 4.7.650 'Temporarily Rate Limited Due to IP Reputation': How to Fix It

451 4.7.650 The mail server [your IP] has been temporarily rate limited due to IP reputation means Microsoft's consumer mail servers (Outlook.com, Hotmail, Live, MSN) are slowing down how much mail they accept from your sending IP, because that IP's reputation has dropped. It is temporary. Your server will keep retrying. The fix is to send less, send better, and let the reputation recover. Pushing harder makes it last longer.

What the bounce line tells you

A typical deferral looks like this:

451 4.7.650 The mail server [203.0.113.25] has been temporarily rate limited due to IP reputation. For e-mail delivery information, see https://aka.ms/postmaster (S775)

• 451 is a temporary failure. RFC 5321 says the sender should retry later.
• 4.7.650 is Microsoft's own enhanced code for this throttle.
• The IP in brackets is the IP Microsoft is judging. This is your sending server's public IP, or your provider's shared IP, not your domain.
• (S775) is an internal Microsoft tag. Spam Resource's write-up of the February 2026 wave (26 February 2026) quotes the same tag.

Nothing in the line points to a single recipient. Every Microsoft consumer address you send to from that IP is affected.

Is it you, or Microsoft?

Usually it is your IP. Sometimes it is Microsoft.

In February 2026 Microsoft posted a note on its sender support form saying it was "aware of an issue that may result in certain IP addresses being temporarily rejected at higher rates" and was investigating. That note is quoted in the Spam Resource post above. Senders with clean IPs and steady volume saw this code at the same time as everyone else.

A quick way to tell which case you are in:

Sign	Points to
Only one of your IPs is affected; others sending similar mail are fine	Your IP's reputation
It started after a volume jump, a new list or a new campaign	Your IP's reputation
Hard bounces or complaints rose in the same week	Your IP's reputation
Many unrelated, well-run IPs hit it in the same narrow window, and deliverability forums are full of it	A Microsoft-side incident
Gmail, Yahoo and business domains are accepting your mail normally the whole time	Either. This code is Microsoft-consumer specific

If it looks like an incident, the right move is to slow down, keep retrying normally, and wait. Do not rebuild your infrastructure over a provider-side problem.

Who sees this code

Microsoft judges the IP that connects to it. That determines whose reputation is on the line:

• You run your own SMTP server or VPS (Postal, Mailcow, a cold-email SMTP provider with dedicated IPs): it is your IP and your reputation.
• You send through an ESP on a shared IP (SES, SendGrid, Mailgun shared pools): the IP's reputation is shared with other customers. Your provider sees the deferrals too and often moves traffic between IPs. Tell their support.
• You send cold email through Google Workspace or Microsoft 365 mailboxes: the connecting IP belongs to Google or Microsoft, so this exact code is rare. If you see it in a sequencer's logs, check which SMTP route the inbox is using.

Our post on shared vs dedicated IPs covers the trade-off.

What raises the risk

Microsoft does not publish its scoring. The causes reported in Microsoft Q&A threads and deliverability write-ups are consistent:

1. Sudden volume. A new IP, or an old IP that jumps from hundreds to tens of thousands of Microsoft messages a day.
2. Invalid addresses. A batch of 550 5.5.0 Requested action not taken: mailbox unavailable bounces from Hotmail tells Microsoft the list is old or scraped.
3. Spam traps. Recycled Hotmail and Outlook addresses that Microsoft turned into traps after long inactivity. See how spam traps get on your list.
4. Complaints. Outlook users clicking Junk. Microsoft reports these through JMRP if you have signed up.
5. Low engagement. Mail that nobody opens or replies to, sent at volume.
6. Missing or broken authentication. Microsoft's bulk-sender rules for Outlook.com require SPF, DKIM and DMARC for high-volume senders. Our Microsoft and Outlook sender requirements post covers them.
7. Weak DNS identity. No reverse DNS (PTR) on the IP, or a PTR that does not match the HELO name.

How to recover, step by step

1. Stop the volume climbing

Cut the volume you send to Microsoft consumer domains, today. If you can, route those addresses to a separate campaign or queue so you can control them separately from Gmail and business mail. Keep sending a steady, smaller amount rather than stopping dead. Microsoft needs to see good behaviour to raise the score, and silence does not show it anything.

2. Leave retries at normal settings

Let your MTA retry with its normal backoff. Hammering retries every minute adds connections from an IP Microsoft is already wary of. If your queue lifetime is short (some tools use a few hours), deferred messages will expire and bounce. That is better than a retry storm.

3. Send only to your best addresses

While the throttle is on, mail only to Microsoft consumer addresses that replied, clicked or opened recently, or that you verified in the last few days. Hold everything else until the deferrals ease.

4. Clean what is left

Run the held Microsoft addresses through a verifier and drop invalid ones. Be aware that Microsoft's consumer domains at times refuse checks from verifier networks, including ours, so some will come back unconfirmed rather than valid. Treat those as "send later, slowly", not as safe.

5. Check the basics

• Blocklists. Run your IP through the blacklist check. This code can appear with no public listing, but if you are on Spamhaus as well, fix that first. See how to get off a blacklist.
• Authentication. Confirm SPF, DKIM and DMARC pass and align with the Microsoft sender requirements checker.
• Reverse DNS. Check that the IP has a PTR record that resolves back, with the reverse DNS lookup. Our PTR record guide explains why it matters.
• SNDS and JMRP. Microsoft's Smart Network Data Services shows how its systems see IPs you control, and JMRP sends you complaint copies. A clean SNDS view does not prove there is no problem, but a red or yellow one confirms there is.

6. Ask Microsoft, once you have fixed things

If the IP is clean, authentication passes, volume is moderate and deferrals continue for several days, use Microsoft's sender support request form, linked from the postmaster page in the bounce (aka.ms/postmaster). Include the IP, sample bounce lines with timestamps, and what you changed. If you send on a shared ESP IP, your provider should file this, not you.

7. Ramp back up slowly

Once mail is flowing, increase Microsoft-bound volume gradually, for example by a quarter or so per day, and watch the deferral rate. If it climbs again, step back to the last level that worked.

A worked example (illustrative)

A team sends cold email from two dedicated IPs. They load a new list of 40,000 contacts, about a fifth of them on Hotmail and Outlook.com, and send 6,000 a day per IP. On day three, Microsoft-bound messages start deferring with 4.7.650. Gmail is unaffected.

They cut Microsoft-bound volume to 500 a day per IP, aimed only at people who replied to earlier campaigns. They verify the remaining Hotmail addresses and drop the invalid ones. They also notice the second IP had no PTR record and add one. Deferrals fall over the following week, and they ramp Microsoft volume back up over the next two.

What made it happen was the list, not the IPs: a large, unverified consumer-heavy batch sent at full speed on day one.

How to stop it happening again

• Verify before every new list goes out. Invalid Hotmail addresses are one of the clearest bad signals you can send Microsoft. Upload on the verify page or with the CSV email verifier.
• Segment by mail provider. Microsoft consumer, Gmail and business mail behave differently. The bulk email provider lookup tags each row so you can pace them separately.
• Ramp new IPs and new lists. See our email warmup schedule.
• Watch your bounce mix, not just your bounce rate. Paste bounces into Bounce Doctor to separate bad addresses from blocks and deferrals.

The first 100 checks on SimpleVerifier are free with a Google sign-in, and plans are on the pricing page.