A Microsoft deferral is a temporary SMTP refusal, a response starting with 4, that Outlook.com or a Microsoft 365 server sends when it won't take your message right now. Your server should keep it and retry. The best known is 451 4.7.500 Server busy. Please try again later, and the same code can mean "your sending looks suspicious" or "Microsoft is having a bad day".

On September 4, 2026 it meant the second, and at least one experienced operator spent the morning chasing the first. Here's how to tell them apart.

Key takeaways

• Read the host first. *.olc.protection.outlook.com is Outlook.com consumer mail, *.mail.protection.outlook.com is a Microsoft 365 tenant. Different docs, different escalation.
• A 4xx means queue and retry: RFC 5321 says at least 30 minutes apart, for at least 4 to 5 days. A 5xx means stop. Microsoft's policies forbid retrying it.
• If every IP gets the same Microsoft code in the same minute while Gmail and Yahoo are fine, suspect Microsoft and check mailop before changing anything.
• Since May 5, 2025, Outlook.com has enforced SPF, DKIM and DMARC for domains sending 5,000 or more messages a day. 550 5.7.515 is always yours to fix.
• Register sending IPs in SNDS and JMRP now. SNDS access expires after 10 months unless you reattest.
• Don't retry harder, rotate to fresh IPs or suppress deferred contacts.

First, find out which Microsoft you are talking to

Microsoft runs two receiving systems.

Outlook.com is consumer mail: outlook.com, hotmail.com, live.com and msn.com, with MX hosts like hotmail-com.olc.protection.outlook.com. It has the Outlook.com Postmaster site, SNDS for reputation and its own sender support form.

Microsoft 365 (Exchange Online) hosts business mailboxes. Mail for acme.com goes to acme-com.mail.protection.outlook.com. Errors are documented on Microsoft Learn, blocks go through sender.office.com, and the recipient's admins control how their tenant treats you.

The domain name won't tell you which one you're hitting. The response will. In this log line posted to mailop on September 4, the relay= host is a Microsoft 365 tenant:

relay=xxxx-com.mail.protection.outlook.com[52.101.10.16]:25, dsn=4.7.500,
status=deferred (host xxx-com.mail.protection.outlook.com[52.101.10.16] said:
451 4.7.500 Server busy. Please try again later from [199.89.3.6]. (S77714)
[BN2PEPF000055E1.namprd21.prod.outlook.com 2026-09-04T10:28:53.346Z ...]
(in reply to end of DATA command))

Decode the response

Read the basic code (451), the enhanced code (4.7.500) and the bracketed subcode like (S77714). Microsoft doesn't publish S-subcodes, but many senders reporting the same one at once is a signal.

Sources: Microsoft's Exchange Online NDR reference, ASxxx article, Postmaster code table and 550 5.7.515 article; Al Iverson on S775 and S3115; Twilio SendGrid on S3140/S3150 blocks.

The 4 versus the 5 is the instruction

M3AAWG's Sender Best Common Practices say that after a temporary failure "the sender should close the connection and open a new connection later", and that senders must never treat a tempfail as permanent. Microsoft's sender policies on 5xx: "the sender must not attempt to retransmit that message to that recipient."

A 451 is not a bounce. If your platform or a script treats it as one, fix that first.

Microsoft incident or your reputation

Microsoft's 4.7.500 guidance points you at your own sending. Usually that's right, but not always.

What September 4, 2026 looked like

Qboxmail told mailop the problem "started at 9:47 CEST on all our IPs at once", with subcodes S77714, S77717 and S77719. Poppulo's status page quoted Microsoft's incident ID, EX1467029, starting 11:19 BST.

Per emailexpert's September 10 write-up, one operator blamed fiber cuts until One.com, Qboxmail, Mailjet and Poppulo reported the same codes across every sending IP and region. Microsoft blamed an anti-spam model, then a throttling rule still firing during recovery. emailexpert found no public post-incident report. A separate authentication fault, MO1465074, ran about 67 hours from August 31 to September 3. Our September report covers those ten days.

Five checks before you act

1. Your own scope. Platform problems hit every IP, domain and stream within minutes. Reputation problems usually start on one.
2. Other providers. If Gmail, Yahoo and Apple accept normally and other senders report the same Microsoft code, the cause is probably Microsoft.
3. Your last 72 hours. A volume spike, new IP, imported list, DNS edit or reactivation send needs fixing regardless.
4. Ask around. Check the mailop archive and status pages. A Microsoft 365 admin can open Health > Service health, whose Issue history covers the last 7 or 30 days of incidents posted to your tenant. That's where Poppulo found EX1467029.
5. SNDS. Green with no blocks while deferrals pile up points away from you.

Routing a Microsoft response, from Microsoft's docs and the September 2026 incident reports.

SNDS and JMRP: set them up before you need them

Smart Network Data Services (SNDS) is Microsoft's free per-IP reputation portal for Outlook.com. The SNDS FAQ lists what each authorized IP shows:

• Filter result. Green is under 10% spam verdicts, yellow 10% to 90%, red over 90%.
• Complaint rate, complaints over recipients. More than 30% of IPs stay under 0.3%, "a good bar to shoot for."
• RCPT commands versus message recipients. A big gap means stale lists.
• IP status: Blocked, Bot or Junked.

Data "may not be present for IPs which sent less than 100 messages on the given day." To get access, request an IP, range or ASN, and SNDS emails a link to addresses it finds via reverse DNS (postmaster@, abuse@) or RDAP. No manual requests.

SNDS relaunched in June 2026. Al Iverson noted on June 19 that JMRP return-paths no longer reliably identify campaign and recipient, so encode those elsewhere. Per the SNDS home page (updated September 22), access expires 10 months after approval or migration, with three reminders. Calendar it.

The Junk Mail Reporting Program (JMRP), enrolled inside SNDS, returns each message an Outlook.com user marks as junk, often "within as little as 72 hours" of enrolling. Remove complainers from every list and enroll new IPs as you add them. On shared IPs you can't register, ask your provider what it watches.

Sender support and delisting

Outlook.com. The support form on the Postmaster troubleshooting page needs a Microsoft account, covers only the four consumer domains, and "does not guarantee" delivery. Twilio SendGrid (vendor advice) says to include your domain, IPs, stream description, bounce text and SNDS screenshots, answer the automated first reply asking for escalation, and request your volume quota and a Volume-Based Limit review.

Microsoft 365. For 5.7.606-649, use the delist portal at sender.office.com: one address and one IP per visit, confirmed by email. Removal "might take up to 24 hours or longer." For 5.7.511, email the NDR to delist@microsoft.com, and expect a reply within 48 hours.

An ASxxx throttle has no delist. If the recipient company filters inbound mail through a third party before Microsoft 365, the Learn article says a connector set up by its admin removes the throttling. Otherwise it clears as you build history.

Retry, throttle and ramp

Retry on a schedule. RFC 5321, section 4.5.4.1 says "the retry interval SHOULD be at least 30 minutes" and the give-up time "generally needs to be at least 4-5 days," with two attempts in the first hour, then one every two or three hours. Don't shorten it for an urgent send.

Throttle per destination. M3AAWG says receivers expect adjustment "as a wholesale process for all emails sent to them by the same IP address." When Microsoft defers, slow everything to that MX family (Outlook.com or Microsoft 365).

Watch connections. Outlook.com policy says senders "must not open more than 500 simultaneous connections" without prior arrangement. That's a ceiling, and a 4.7.652 (S3115) means you're over yours.

Ramp new IPs and domains. Microsoft says a new IP "can expect to be fully ramped within a couple of weeks or sooner," depending on volume, list accuracy and complaints. New IPs covered by an existing SPF record inherit some domain reputation. Start with recent engagers.

What not to do

• Retry harder. Flushing the queue every few minutes piles connections onto an IP Microsoft wants slowed, and earns you a 4.7.652.
• Switch IPs to dodge it. New IPs have no reputation and are more likely to have problems, and spreading mail across fresh IPs is what snowshoe spammers do.
• Retry a 5xx. Microsoft forbids it, and after "multiple non-delivery responses" you must stop sending to that recipient.
• Suppress deferred contacts. The address is still valid.
• Re-send to deferred recipients. Their messages are still queued. You'd send duplicates.
• Edit DNS in a panic. Changing SPF or DKIM mid-incident adds a second problem, unless you got a 5.7.515.

For DMARC alignment and moving from p=none to enforcement, see our deliverability guide. To keep password resets and receipts moving, our transactional email guide covers putting them on their own domain.

How this looks in Brew

Brew runs the sending infrastructure and retries temporary failures, so you never tune queues or connection limits. What you see:

• Delayed events. A deferral records a Delayed event (delivery_delayed), and the recipient moves from accepted to delayed, then delivered or bounced. In Events, search "delayed", then type @hotmail.com or @outlook.com to narrow to Outlook.com (domain filters combine with OR; Microsoft 365 recipients use their own domains). The event says the message is waiting, not why.
• Bounce details. A bounced event's Metadata holds the bounce type and provider message.
• Counts over the API. The analytics overview returns deliveryDelayed and pending beside delivered and bounced. get_email_analytics does the same over MCP.
• Suppression that respects 4xx. Hard bounces and complaints suppress immediately. Soft bounces suppress only after three within 30 days.
• Ramping. Gradual send splits a large send into hourly or daily percentage batches you can pause if Outlook.com starts deferring.
• Domain health. Each domain's Deliverability card scores 0 to 100 across inbox placement, reputation, authentication, content and sending setup, also available via the get_domain_health MCP tool. An inbox placement test (10 credits) hits seed mailboxes at Gmail, Outlook, Yahoo, Apple and others.

Per-provider breakdowns, delivery webhooks and SNDS or JMRP data aren't in Brew yet, so use Microsoft's portals for reputation. During a suspected Microsoft incident, we'd leave the send alone and watch Delayed turn into Delivered.

Frequently asked questions

What does 451 4.7.500 Server busy mean from Outlook or Microsoft 365?

It's a temporary refusal from Microsoft 365 (Exchange Online), listed as "Access denied, please try again later" after suspicious activity. Usually your sending pattern changed, but on September 4, 2026 it was a Microsoft incident (EX1467029). Let your server retry and check whether other senders see it too.

How long will Microsoft keep deferring my email?

Microsoft says pattern-based throttling resolves "over a period of a few days" as you build history, and delisting can take up to 24 hours or longer. Keep retrying for at least 4 to 5 days, as RFC 5321 recommends, and most deferred mail still delivers.

What is 550 5.7.515 and how do I fix it?

Outlook.com rejects mail from domains sending 5,000 or more a day that miss its authentication rules, enforced since May 5, 2025. SPF and DKIM must pass, the domain must publish DMARC (p=none is enough), and SPF or DKIM must align with the From domain.

Should I get a new IP address if Microsoft blocks mine?

No. Microsoft says new IPs have no reputation and are more likely to have problems. Fix the cause, request delisting and ramp back up on the IP you have.

Do Microsoft deferrals count as bounces?

No. M3AAWG says senders must not treat a 4xx as permanent. It becomes a bounce only if retries run out or the server returns a 5xx. In Brew, a deferral shows as a Delayed event, and contacts are suppressed only after repeated soft bounces.