If mail to outlook.com or a Microsoft 365 tenant takes minutes or hours to arrive while Gmail gets it in seconds, the delay is almost never your server being slow. Microsoft is throttling you on purpose, because it does not yet have enough confidence in the sender to accept mail at the rate you are offering it.
Read the delay out of the headers and logs
Received headers carry timestamps, so the queue delay is measurable rather than a feeling:
Received: from mail.yourdomain.com (203.0.113.10) by BN1PR01MB123.outlook.com; Wed, 14 Oct 2026 09:41:52 +0000 Received: from app-sender-3 (10.0.0.7) by mail.yourdomain.com; Wed, 14 Oct 2026 09:12:04 +0000
Half an hour between your own MTA and Microsoft's edge is deferral, not transit. Your mail log will show why:
| Response | Meaning |
|---|---|
451 4.7.500 Server busy, please try again later | General throttling of your IP |
451 4.7.650 The mail server [IP] has been temporarily rate limited | Explicit rate limit on thin reputation |
452 4.5.3 Too many recipients | Per-transaction recipient limit exceeded |
421 4.4.2 Message submission rate exceeded | Submission-rate limit, often tenant-side |
All 4.x.x — temporary. Retry with backoff. Treating them as failures and suppressing recipients throws away valid addresses and does nothing about the cause.
The things that actually reduce deferral
Authentication that passes with alignment. Microsoft tightened requirements for high-volume senders to consumer Outlook domains in 2025: SPF, DKIM and a published DMARC policy with the From domain aligned to at least one. Unauthenticated mail gets the most conservative treatment available, and a 550 5.7.515 is the hard version of the same verdict.
A volume shape that does not jump. Microsoft's filtering reacts to change. A sender at a steady 50 a day that suddenly offers 800 looks like a compromised mailbox. Increase gradually, spread sends across the working day instead of firing one morning batch, and do not restart at full volume after a pause.
Sender reputation on the IP, not just the domain. Microsoft weights the sending IP more heavily than Gmail does. On shared pools you inherit your neighbours; on a dedicated IP you own the outcome entirely.
Clean recipients. Invalid addresses and spam-trap hits drive the complaint and trap columns in SNDS, and those are what turn a reputation grade yellow. A yellow grade means more deferral, which is the delay you are trying to remove.
Retry behaviour that is not aggressive. Hammering a 451 makes it worse. Exponential backoff with a sane cap is both correct and faster in aggregate.
Dedicated versus shared IPs
The honest answer is that it depends on volume, and the common advice is backwards for small senders.
- A shared pool has established volume and established reputation. On a well-managed pool that reputation is a head start. On a poorly managed one you are paying for someone else's complaints, and you cannot see it because Microsoft publishes no blocklist to check.
- A dedicated IP has no reputation at all on day one, and Microsoft treats unknown as suspicious. It only pays off when you send enough, consistently enough, to build and hold a reputation of your own — and it requires warm-up from zero.
If your volume is modest, a clean shared pool will deliver faster than a cold dedicated IP. If it is substantial and steady, dedicated plus SNDS registration gives you both control and visibility.
Get the only visibility Microsoft offers
Register the IPs you own with SNDS for per-IP volume, complaint rate, trap hits and a colour reputation grade, and enrol in JMRP so every junk report is forwarded to you with the recipient intact. Neither backfills, so register before you need them. There is no Microsoft blocklist to query — these two feeds and your SMTP responses are the whole picture.
For an IP-level block rather than throttling, Microsoft's delist portal takes a one-off mitigation request. Change the sending behaviour first; a repeat request with nothing fixed is declined.
What not to do
- Do not retry `4.7.x` responses faster. Backoff is the correct response and the quicker one overall.
- Do not suppress recipients that produced a temporary failure. You are deleting deliverable addresses.
- Do not buy a dedicated IP to escape deferral at low volume. You will trade a shared reputation for no reputation.
- Do not send one large morning batch. Spread it; burst traffic from a thin-reputation IP is the most reliable way to earn a rate limit.
- Do not measure speed with your own Outlook account. Mail from a domain you correspond with is handled differently from mail to a stranger.
- Do not treat an SNDS green grade as proof of fast inbox delivery. It means no recorded problem, not good placement.
How MailPilot helps
MailPilot warms Outlook and Microsoft 365 mailboxes over OAuth, and SMTP senders including SendGrid, Amazon SES, Mailgun, Postmark and custom hosts, with a ramp and an intra-day spread designed to avoid the burst patterns that trigger Microsoft's rate limiting. It measures Microsoft placement separately with a seed-inbox network, checks SPF, DKIM and DMARC alignment, and tracks each mailbox's reputation daily so a drift toward deferral is visible before a campaign stalls.
Ready to reach the inbox every time?
Automated email warmup across real peer mailboxes. Live inbox placement monitoring. Free 7-day trial - no credit card required.
Start free trial