Why are Microsoft email addresses bouncing and how do I fix it?
Updated on 24 Oct 2026: We updated this guide for Outlook.com sender requirements and clearer Microsoft bounce-code troubleshooting.
Microsoft email addresses usually bounce because Microsoft has rejected the sending IP, the message failed an authentication or reputation check, the sender hit Microsoft-specific throttling, or the recipient account cannot accept mail. The fix starts with the bounce code in the non-delivery report (NDR), delivery status notification (DSN), or SMTP transcript. A 550 5.7.1 or 554 5.7.0 rejection points to policy, content, or reputation. A 451 4.7.500 or 421 4.2.1 response points to temporary throttling or service unavailability. A 550 5.1.1 response usually means the mailbox does not exist.
Separate Outlook.com consumer mailboxes, including Hotmail, MSN, and Live.com, from business domains hosted in Microsoft 365. A failure affecting one recipient needs a different investigation from a spike across Microsoft domains. Read the exact SMTP response before deciding whether the cause is sender reputation, authentication, or a recipient restriction.
After reading the rejection, test a real message and compare it with your DNS records and bounce logs. Suped's email tester shows authentication results and message-level issues for that comparison.
How to fix Microsoft email bounces
If Microsoft says part of your network is on its block list, pause the affected sending stream, identify the IP or range, and confirm authentication and reverse DNS. Inspect recent traffic for abuse or sending changes, correct confirmed problems, and request a review if the block persists.
- Capture the exact bounce: Save the SMTP code, enhanced status code, affected IP, recipient domain, UTC timestamp, message ID, generating server, and rejecting server.
- Classify the bounce: Separate mailbox errors, authentication failures, throttling, policy blocks, content verdicts, and blocklist (blacklist) responses.
- Decide who controls the fix: Sender reputation and DNS issues sit with you or your provider, while mailbox restrictions and recipient-gateway decisions sit with the recipient organization.
- Segment Microsoft traffic: Track bounce rate, complaint rate, delivery rate, and spam placement for Microsoft recipients only.
- Check infrastructure: Verify SPF, DKIM, DMARC, PTR, HELO/EHLO identity, TLS, and sender domain consistency.
- Check the sending path: If the failure happens only in Outlook desktop, test webmail and check account authentication. For a manually configured SMTP account, verify the provider's supported submission host and encryption settings, then check for stuck Outbox messages.
- Reduce pressure: Back off queued 421 or 451 deferrals with fewer connections. Stop automatic retries for 5xx rejections and correct the reported cause before sending a new message.
- Escalate with evidence: Contact your sending provider, the recipient admin, or Microsoft support according to which server rejected the message. Include bounce samples, IPs, dates, volume, and remediation already completed.
For temporary deferrals such as 421 or 451, keep the addresses out of hard-bounce suppression while the sending server's retry window is open. Use lower concurrency and wider retry spacing. Once the queue expires or a final NDR is issued, review the cause before sending a new message. Increase timeouts only when logs show connection or greeting timeouts.
A clean result in a public blocklist check does not prove Microsoft is accepting your mail. Microsoft can reject based on its own private reputation data, recipient engagement, recent traffic changes, spam folder placement, network-level signals, or abuse patterns near your IP. That is why the exact Microsoft response matters more than a generic clean status.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
If you are testing a Microsoft bounce alert rather than troubleshooting a live incident, send one controlled message and trace its message ID through the alert path. Do not create volume by sending to batches of fake Outlook or Hotmail addresses. Repeated intentional failures can resemble directory harvesting and worsen the same Microsoft signals you are trying to understand.
What the Microsoft bounce code means
Microsoft bounces are usually specific enough to point the investigation in the right direction. Read the full SMTP response from the rejecting server alongside the sending provider's dashboard label. A 5xx policy rejection is a hard failure for that message; it does not prove the recipient address is invalid.
Suppress confirmed invalid recipients, and investigate other permanent failures according to their full reply text. Temporary 4xx responses need scheduled retries and investigation of the stated cause. Separating hard bounces and soft bounces helps you choose between recipient cleanup, authentication repair, and a support request.
Microsoft policy rejection exampletext
smtp; 550 5.7.1 Unfortunately, messages from [54.240.46.27] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150).
|
|
|
|---|---|---|
550 5.7.1 | Policy, permission, or reputation block | Read the full reply to distinguish sender blocks from recipient restrictions |
554 5.7.0 | Content, policy, or reputation rejection | Read the full text and identify the rejecting server |
S3150 | Microsoft network blocklist (blacklist) signal | Check IP range and provider escalation |
451 4.7.x | Temporary deferral; reason depends on the full reply | Back off and check for throttling, authentication, or TLS errors |
421 4.2.1 | Temporary service unavailable or connection refusal | Back off and reduce concurrent connections |
550 5.1.1 | Invalid recipient | Suppress the address |
550 5.5.0 | Outlook.com or Hotmail recipient not found during address lookup | Confirm the spelling and active mailbox status with the recipient |
5.2.2 | Mailbox quota or sender submission quota exceeded | Read the reply text to identify whose quota was exceeded |
550 5.1.10 | Bad recipient or forwarding target | Share the full NDR with the recipient admin |
550 5.7.12 | Recipient rejects external senders | Ask the recipient admin to change delivery restrictions |
550 5.7.134 | Mailbox rejects external senders | Use an alternate contact until the recipient updates the mailbox |
550 5.7.23 | SPF violation or configuration issue | Fix SPF and inspect the original remote-server response |
550 5.7.509 | DMARC failed with a p=reject policy | Repair SPF or DKIM authentication and the domain match |
550 5.7.515 | Outlook.com high-volume sender authentication requirements not met | Verify SPF, DKIM, and DMARC on the affected sending path |
550 5.1.8 | Bad outbound sender or Restricted entities block | Check Microsoft Defender and sender-account security |
550 5.7.233 | Tenant external-recipient limit reached | Review tenant external-recipient usage and the rolling 24-hour window |
550 5.7.236 | onmicrosoft.com external-recipient limit reached | Send from a verified custom domain and review volume |
550 5.7.705 | Tenant blocked after suspicious outbound traffic | Investigate compromise and contact Microsoft support |
Common Microsoft bounce patterns and first actions
For Microsoft consumer domains, watch for sudden changes by date. If bounces rose sharply after one campaign, one new customer, one migrated list, one new IP, or one DNS change, treat that as the starting point. Microsoft does not need to behave like Gmail or Apple. Its filtering thresholds, reputation inputs, and mitigation process are separate.
Microsoft's NDR reference explains the documented code meanings. Match each code to the complete remote-server reply and the service that rejected the message.
Read the final rejection in a multi-hop NDR
A Microsoft-generated NDR does not prove Microsoft made the final rejection. Exchange Online can accept a message for delivery, connect to the recipient's MX or filtering gateway, receive a rejection there, and wrap that downstream response in its own NDR. Check the fields for the generating server, the server named after 'Message rejected by,' and every response after 'Remote server returned.'
Illustrative downstream spam rejectiontext
Generating server: <Exchange Online server> Remote server returned: 550 5.7.350 Remote server returned message detected as spam -> 550 5.7.1 Message rejected as spam by recipient server
- Identify the rejecting server from the remote-server response. The NDR generator can be a different server; use the response chain to establish who rejected the message.
- Read the response chain to the final specific line. A 5.0.350 wrapper is generic, while 5.7.350 says an external recipient server or filter returned a spam verdict.
- Match the fix to the final reason. A spam verdict calls for content and reputation comparison, while 5.4.1 can mean an invalid recipient or a recipient-domain routing problem.
- Escalate to the right admin. Send the complete NDR to the recipient admin when their gateway or downstream MTA rejected the message.
Do not treat every Microsoft-branded NDR as an Outlook.com, Hotmail, or Microsoft blocklist incident. The full response chain decides whether the sender, Microsoft, the recipient gateway, or the recipient mailbox controls the fix.
Separate sender and recipient fixes
Not every Microsoft bounce is a sender reputation problem. Some NDRs mean the recipient's Microsoft 365 tenant, mailbox, group, MX record, accepted domain, hybrid route, transport rule, firewall path, filtering gateway, or forwarding rule is rejecting the message. In those cases, fixing your SPF, DKIM, DMARC, or sending IP will not change the result.
|
|
|
|---|---|---|
Recipient requires authenticated senders | Recipient admin | Ask the admin to review the recipient's external-sender delivery restrictions |
Mailbox rejects external senders | Recipient admin | Use another contact path while they update mailbox delivery restrictions |
Recipient storage full or mailbox disabled | Recipient or admin | Ask for a working mailbox; Outlook.com recipients should check email storage and Microsoft cloud storage |
Accepted domain, MX, or hybrid routing error | Recipient admin | Share the full NDR so they can check domain and routing configuration |
Downstream gateway rejection | Recipient admin or gateway admin | Share the response chain and the name of the rejecting server |
Forwarding rule creates a rejection | Recipient admin | Check the failed recipient address, mailbox forwarding, and Inbox rules |
Content rejection | Recipient admin or Microsoft policy | Compare the message body, URLs, attachments, and sender domain against a clean control message |
Recipient-side bounce signals and who controls the fix.
The key distinction is control. Sender-side blocks improve when the sending source is cleaned up. Recipient-side restrictions require the recipient or their Microsoft 365 admin to change mailbox, group, routing, content filtering, or policy settings. If the bounce started after DNS hosting, firewall, Exchange hybrid, gateway, or accepted-domain changes, ask for the full NDR and have the recipient admin verify the MX path and authoritative domain state.
For one-off recipient errors, type the full address again instead of selecting an Outlook autocomplete entry. Confirm spelling and mailbox status with the recipient. For a Microsoft 365 address, ask the admin to check aliases and directory sync if the failure persists.
If the recipient received the original message but you still got a bounce, compare the failed address in the NDR with your intended recipient. The failure can belong to an automatically forwarded copy, as documented in a Microsoft Q&A case. Ask the recipient to inspect Mail settings for Rules and Forwarding. An unknown forwarding target warrants removing the rule and securing the account with a password reset, session revocation, and multifactor authentication.
If you never sent the message named in a bounce, compare its original message ID and timestamp with server logs or message trace. Missing Sent Items alone does not establish what happened. A forged envelope sender can generate backscatter without account access; unexplained sends in the logs require an account-security investigation.
For a storage-related rejection, Outlook.com recipients need to check both their mailbox quota and Microsoft cloud storage. Microsoft's Outlook.com delivery troubleshooting confirms that full cloud storage prevents sending and receiving email. After capacity is restored, send a new message if the original was rejected.
Why Microsoft can bounce clean-looking mail
A Microsoft-only bounce spike can happen even with low global complaints and no public blocklist hit. Microsoft evaluates its own recipient traffic separately from the sender's global dashboard. A campaign can have a low total complaint rate and still have weak Microsoft engagement or a Microsoft-specific complaint issue.
What your dashboard says
- Global complaint rate: All recipient domains are averaged together.
- Public listing status: Public blocklists do not expose every Microsoft decision.
- Imported list history: Previous performance at another sender does not transfer cleanly.
What Microsoft sees
- Microsoft-only rate: Complaints and bounces are judged inside Microsoft traffic.
- Private reputation: Internal signals can cause blocks without a public listing.
- Network context: Nearby IPs, provider pools, and PTR identity can affect trust.
This is also why migrated lists cause surprises. A list that performed well at a previous platform can behave differently when it moves to a new IP, a new DKIM domain, a new return-path domain, or a new sending cadence. Introduce a new sending identity gradually; an established domain's history can still help a new IP.
Flowchart showing the Microsoft email bounce troubleshooting path from bounce code to mitigation request.
Check authentication before blaming reputation
Even when a bounce message points at reputation, check authentication first. Verify SPF and DKIM on the actual message, then check whether an authenticated domain matches the visible From domain for DMARC. Reverse DNS and HELO/EHLO identify the connecting server and need separate checks.
- SPF pass: The envelope sender domain authorizes every legitimate outbound path. Stay within the limit of 10 DNS-querying mechanisms and modifiers during evaluation, including nested includes; this is not a count of every DNS packet.
- DKIM pass: Verify a valid message signature and compare its d= signing domain with the visible From domain for DMARC.
- DMARC domain match: At least one passing SPF or DKIM identity must match the From domain. Relaxed mode permits the same organizational domain; strict mode requires an exact domain match.
- PTR identity: Reverse DNS exists, matches a sensible host, and forward-confirmed DNS resolves back to the IP.
- HELO/EHLO identity: The server should announce its own fully qualified hostname with valid DNS. Check this identity separately from the message's From domain.
For hybrid or relay setups, authentication breaks when Microsoft 365 sends some mail, an on-premises server sends another stream, and only one path is in SPF or DKIM. Test a real message from each path before assuming the domain is covered.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped's domain health checker gives a quick read on DMARC, SPF, and DKIM status. For ongoing production mail, Suped's DMARC monitoring connects those DNS checks to real aggregate reports so you can see which sources pass, fail, or drift after a provider change.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Fix Outlook.com high-volume sender authentication failures
Outlook.com's high-volume sender requirements took effect on May 5, 2025. Domains sending more than 5,000 emails per day to its consumer accounts must meet the authentication requirements in Microsoft's Outlook.com sender policy. These requirements cover consumer delivery, including Hotmail and Live.com; Microsoft 365 tenant sending limits are a separate issue.
- SPF must pass for the sending domain.
- DKIM must pass on the message.
- Publish a valid DMARC record with at least p=none.
- For DMARC, a passing SPF or DKIM domain must match the visible From domain under the configured matching mode.
A 550 5.7.515 rejection means the sending domain did not meet the required authentication level. DMARC can pass through SPF while DKIM fails, so DMARC pass alone is insufficient for these requirements. Test each sending source and inspect message-level authentication results before resending.
Reverse DNS and sender infrastructure
Microsoft requires valid reverse DNS for sending servers. A dedicated IP's PTR can point to a provider-owned hostname. That hostname alone does not explain a network block; check that it is valid and that its forward DNS resolves back to the sending IP.
For dedicated IPs, ask the provider whether custom reverse DNS is available. A custom PTR such as mail1.sender.example can make ownership and responsibility clearer, but it will not fix poor list quality, spam complaints, or failed authentication.
Look up the IP's PTR, then confirm the returned hostname resolves back to the same IP. Include those results and the HELO/EHLO identity in a support case. Ask the IP owner or sending provider to correct missing or inconsistent reverse DNS.
If Hotmail or Outlook.com only bounces from one network, read the sending IP in the rejection. For manually configured SMTP accounts, use the provider's authenticated submission host and supported encryption, commonly STARTTLS on port 587. POP and IMAP retrieve mail; they do not submit it. Compare a webmail test with the desktop failure to isolate the sending path.
Reverse DNS checks with example valuesbash
dig -x 54.240.46.27 +short # Replace this example with the hostname returned by the PTR lookup. dig mail1.sender.example A +short
If you send through a shared pool, ask the provider for pool health details and help isolating affected traffic. Keep transactional and opted-in marketing streams separate from suspect traffic. Consider a dedicated IP only with enough consistent volume and a gradual warm-up plan; a new IP starts with limited reputation.
Find the cause in recent sending changes
Most Microsoft bounce spikes have a trigger. Build a short timeline and look for the first change before the bounce increase. A new customer, a new list import, a volume jump, a cadence change, a DNS edit, or a new content stream can all push Microsoft over a threshold.
What to separate in your logs
Illustrative queue snapshots separate accepted messages, pending temporary deferrals, and permanent rejections. The percentages are examples for log segmentation.
Accepted
Temporary
Rejected
- New sender: Compare their Microsoft bounce rate against the platform average.
- New list: Check the first-send bounce rate and suppress stale Microsoft addresses.
- New cadence: Daily sends to a large list can create fatigue even with familiar content.
- New identity: A changed DKIM domain, return-path, or IP changes the reputation signals. Introduce the new path with a controlled volume ramp.
Do not override a Microsoft 550 5.1.1 with a validation pass. Microsoft sees the mailbox state at send time, while validation checks cannot force Outlook.com or Hotmail to disclose final mailbox status. Suppress the address, then audit the list age and import source.
Track Microsoft complaints alongside Microsoft SMTP-accepted volume, and document the reporting coverage and denominator. Use the denominator supplied with Microsoft's complaint data when available. A low observed complaint rate does not establish inbox placement, and SMTP acceptance does not establish inbox delivery.
Handle Microsoft blocklist and mitigation cases
If the bounce mentions Microsoft's block list or a code like S3150, treat it as a Microsoft-side blocklist (blacklist) case even when public blacklist checks say the IP is clean. The sender still needs a clean public reputation check, but the fix depends on the private Microsoft decision.
Blocklist checker
Check your domain or IP against 144 blocklists.
Suped's blocklist monitoring checks public domain and IP listings alongside authentication signals. Compare those listings with the full Microsoft bounce; Microsoft's private block decisions require Microsoft evidence.
Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
Use the support route for the rejecting service. Outlook.com consumer blocks need Outlook.com sender support; Microsoft 365 IP blocks need the process specified in the NDR. A recipient tenant's own restriction needs its admin. Microsoft's IP removal documentation distinguishes the consumer support route from Microsoft 365 IP removal and the separate handling of 5.7.511.
Mitigation requests work best after you reduce the behavior that caused the block. If Microsoft says the IP is not eligible, do not keep blasting retries. Pause the affected stream, throttle, isolate the suspect sender, validate authentication, and gather fresh bounce samples. Check for compromised accounts, unauthorized connectors, and address-probing traffic before asking again with specific evidence.
Repeatedly retrying rejected Microsoft recipients can extend the problem. Treat hard policy rejections as a stop signal until the cause is found, not as a queue backlog to push harder.
Check Microsoft diagnostics and sending limits
If you control the IP space, Microsoft sender data can help show complaint and reputation signals for the affected range. If your provider owns the IP space, you often need the provider to approve access or provide the data. That gap is common with cloud-owned sending IPs.
For a sudden failure across multiple mailboxes or unrelated senders, check Microsoft service health before changing DNS. Microsoft 365 admins should review Exchange Online incidents in the admin center; personal Outlook.com delivery issues need the consumer service status. Keep the rejection timestamps for comparison with any incident window.
If your organization sends through Microsoft 365 and the NDR mentions Restricted entities, 550 5.1.8, 550 5.7.233, 550 5.7.236, or 550 5.7.705, investigate the account and tenant before requesting unblocking. Check Restricted entities, outbound spam policies, message trace, compromised-account evidence, unauthorized connectors, per-user and tenant sending limits, and whether the message used the high-risk delivery pool.
Exchange Online permits up to 10,000 recipients per mailbox in a rolling 24-hour window, subject to lower administrative restrictions. Submissions above 30 messages per minute are throttled. 550 5.7.233 identifies the tenant external-recipient rate limit, and 550 5.7.236 identifies the 100-external-recipient organizational limit for default onmicrosoft.com domains in a rolling 24-hour window. Review tenant usage for 5.7.233 and resume after the rolling count falls below the applicable limit. See Microsoft's Exchange Online limits for the service definitions.
For a suspected content rejection, send one plain-text control message without links or attachments, then compare it with the failing message. Check the body, URLs, attachments, and sending pattern. If Microsoft accepted the message but the recipient cannot find it, ask the admin to inspect message trace and quarantine; quarantine is an accepted-message outcome rather than an SMTP bounce.
Microsoft SNDS sender IP reputation table for investigating Outlook.com and Hotmail bounce spikes.
The useful support packet is short: affected IPs, full bounce text, Microsoft recipient domains, start date, send volume before and after the change, current throttling, authentication results, and what you removed or paused. A provider can act faster when the request proves you have already reduced the risky traffic.
Illustrative support packet outlinetext
Affected IPs: 54.240.46.27 Domains: outlook.com, hotmail.com, msn.com, live.com First seen: 2026-05-14 09:20 UTC Message ID: <message-id@sender.example> Bounce: 550 5.7.1 network on block list S3150 Action taken: paused sender X, throttled Microsoft traffic Authentication: SPF pass, DKIM pass, DMARC domain match Requested action: review eligibility for mitigation
Use Suped to verify authentication and public listings
Microsoft bounce evidence sits in DNS records, DMARC aggregate reports, and sending logs. Suped's DMARC and email authentication platform brings DNS checks and aggregate-report results into a workflow for investigating sending sources. Compare those findings with the Microsoft rejection logs from your sending system.
- Automated issue detection: Suped flags broken authentication, unverified sources, and DNS problems with steps to fix them.
- Report-based alerts: Authentication failures and source changes can notify the team as receiver reports are processed. Aggregate reporting is delayed and does not provide instant bounce alerts.
- Hosted SPF and DMARC: Teams can manage senders, flatten SPF, and stage DMARC policy without constant DNS edits.
- Blocklist monitoring: IP and domain reputation checks sit beside DMARC, SPF, and DKIM evidence.
- MSP dashboard: Agencies can manage multiple client domains and spot the one sender that changed the risk profile.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Use Suped's findings to document authentication corrections and public listings in the Microsoft support case. Combine them with the full NDR and your sending logs to show which source failed and what you fixed.
Views from the trenches
Best practices
Preserve full SMTP replies before classifying Microsoft bounces in a dashboard.
Measure complaints against Microsoft delivered mail, not total campaign volume.
Throttle Microsoft traffic and retry temporary deferrals with lower concurrency.
Common pitfalls
Assuming public blocklist cleanliness means Microsoft has no private reputation issue.
Migrating a large list and expecting old engagement history to transfer cleanly.
Treating 421 or 451 deferrals as hard bounces can remove valid recipients.
Expert tips
Ask the IP owner to approve Microsoft sender data access when cloud IPs block setup.
Use custom reverse DNS on dedicated IPs when the provider supports that workflow.
Track Microsoft deferrals, hard rejects, and later deliveries as separate metrics.
Marketer view
Marketer from Email Geeks says the bounce message is the first place to look because Microsoft often states the rejection reason directly.
2022-10-20 - Email Geeks
Marketer view
Marketer from Email Geeks says dedicated cloud IPs can still inherit network-level concern when Microsoft references the surrounding provider range.
2022-10-20 - Email Geeks
