Provider deliverability · Microsoft 365 / Exchange Online

Why is Microsoft 365 blocking outbound emails?

Samuel Chenard

By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 17, 2026

Microsoft 365 blocks outbound mail for three reasons: a user or connector exceeded outbound sending limits and landed on the Restricted entities page; Exchange Online classified the mail as spam and routed it through the high-risk delivery pool; or the tenant hit Exchange Online's service limits. Recipient-side rejections trace to missing SPF, DKIM, or DMARC.

The 30-second check

Start with the domain, because half of these blocks end there. The free Microsoft compliance checker tests your tenant's sending domain against the SPF, DKIM, and DMARC checks Microsoft and every major recipient now apply, and tells you which record is missing or misaligned before you go spelunking in the Defender portal.

Check your domain now

Enter your sending domain and the check runs instantly on the next page. Free, no signup.

Why Microsoft 365 / Exchange Online is blocking your email

Likely causeWhat's happening
A user or connector is on the Restricted entities pageWhen an account exceeds Exchange Online's outbound sending limits or the thresholds in an outbound spam policy, Microsoft blocks it from sending (it can still receive) and lists it under Restricted entities in the Defender portal. Every send attempt then bounces with 550 5.1.8. Microsoft's restricted-entities documentation says the restriction is typically the result of a compromised account (checked 2026-07-17), and the pattern fits: one phished mailbox blasting spam, and the tenant's outbound mail stops.
Outbound mail was classified as spam and routed through the high-risk delivery poolExchange Online marks suspicious outbound messages as spam regardless of their spam confidence level and sends them from a separate IP pool reserved for low-quality mail, to keep the normal Microsoft 365 IPs off blocklists. Microsoft's own doc says delivery from that pool isn't guaranteed because many receiving systems refuse it. Your message technically left the tenant; it just left through the door recipients slam.
You hit Exchange Online's service sending limitsThe fixed caps are 10,000 recipients per mailbox per 24 hours and 30 messages per minute via SMTP client submission, with up to 1,000 recipients on a single message. On top of that sits the Tenant External Recipient Rate Limit (TERRL), a license-based tenant-wide daily cap on external recipients; trial tenants get 5,000 a day. Distribution groups in personal contacts count each member individually, which is how a modest send hits the ceiling.
Your custom domain has no DKIM signing, so recipients reject the mailMicrosoft's DKIM documentation is blunt: currently, no DKIM signing occurs for outbound mail from custom domains until an admin enables it (checked 2026-07-17). Only the *.onmicrosoft.com domain is signed automatically. Pair that with a stale SPF record and your tenant's mail fails the sender requirements Gmail (February 2024) and Outlook.com (May 2025) now enforce, so the block arrives from the recipient's side.
You're still sending from the onmicrosoft.com domainMicrosoft throttles outbound mail from default onmicrosoft.com domains to 100 external recipients per organization in a rolling 24-hour window; past the cap, sends bounce with 550 5.7.236. The domain also carries zero reputation with recipients. New tenants and quick app integrations hit this constantly.
Forwarded or relayed mail is leaving through the relay poolMail forwarded or relayed through Microsoft 365 goes out via a special unpublished relay pool unless the outbound sender is in one of your accepted domains or SPF passed when the message arrived. Auto-forwards to external addresses and on-premises relay through connectors are the usual triggers; note the default outbound spam policy setting Automatic - System-controlled now disables external auto-forwarding outright.
Six-step card for fixing a Microsoft 365 outbound block: check SPF, DKIM, and DMARC on the sending domain, review Restricted entities and secure the account before unblocking, trace the delivery pool via OutboundIpPoolName, enable DKIM for the custom domain, tune outbound spam policy limits, and move bulk mail off Exchange Online.

How to fix it, step by step

  1. Run the Microsoft compliance check on your tenant's domain

    Use the free checker above (or at /tools/microsoft-compliance-checker). It verifies SPF, DKIM, and DMARC for the domain your tenant sends as and pinpoints which record is missing or misaligned, which separates a Microsoft-side restriction from a recipient-side authentication rejection in about thirty seconds.

  2. Check the Restricted entities page, secure first, then unblock

    In the Defender portal go to Email & collaboration, Review, Restricted entities (security.microsoft.com/restrictedentities). Before unblocking, reset the password, enable MFA, and follow Microsoft's compromised-account steps; the restriction exists because the account looks hijacked. Unblock via the flyout, or Remove-BlockedSenderAddress in PowerShell. Restrictions normally clear within an hour.

  3. Run a message trace and read OutboundIpPoolName

    In the Exchange admin center, trace a recent outbound message and check the OutboundIpPoolName property. If it names the high-risk pool, Exchange Online is classifying your mail as spam, and the fix is upstream: find the compromised or misbehaving sender, not the recipient's filter.

  4. Enable DKIM for the custom domain and align SPF and DMARC

    On the Email authentication settings page (security.microsoft.com/authentication), publish the two selector CNAME records for your domain and flip DKIM to Enabled; Microsoft won't sign custom-domain mail until you do. Confirm SPF covers every sending service with /tools/spf, then publish DMARC and verify with /tools/dmarc.

  5. Tune outbound spam policy limits and alerts

    In the Defender portal's anti-spam policies, set external, internal, and daily recipient limits below the service caps (0 to 10,000; 0 means service defaults) so a compromised mailbox trips a policy long before it burns your tenant's reputation. Keep the User restricted from sending email alert on so admins hear about restrictions from Microsoft, not from users.

  6. Move bulk and application mail off Exchange Online

    The 10,000-recipient and 30-message-per-minute caps are fixed, and Microsoft's own guidance for higher volumes is Azure Communication Services or a dedicated provider. Put newsletters and automated sends on a subdomain with its own SPF and DKIM, then watch DMARC aggregate reports so the next failing sender surfaces in a report instead of a restriction.

Related free tools: SPF checker · DKIM checker · DMARC checker · Domain reputation · Email security score

If you send in volume: Microsoft 365 / Exchange Online's published rules

Microsoft publishes hard outbound caps for Exchange Online: 10,000 recipients per mailbox per day, 30 messages per minute over SMTP client submission, and a license-based Tenant External Recipient Rate Limit on external recipients per day (trial tenants: 5,000). Default onmicrosoft.com domains are capped at 100 external recipients per organization per 24 hours. Microsoft's limits page states plainly that customers needing legitimate bulk email should use third-party providers, and recommends Azure Communication Services for high-volume external sending (checked 2026-07-17). Separately, if your tenant sends 5,000+ messages a day to Outlook.com consumer addresses (outlook.com, hotmail.com, live.com), Microsoft's May 2025 sender requirements demand passing SPF, passing DKIM, and a DMARC record of at least p=none aligned with SPF or DKIM.

Check your standing with Microsoft 365 / Exchange Online

Bounce codes you may be seeing

Blocks in this cluster surface as specific SMTP codes. Match yours below; the linked guides cover each code's verbatim provider messages and full fix.

The real root cause: unenforced authentication

Trace any of these blocks back far enough and you land on the same two facts: an account that could be abused, and a domain whose authentication doesn't prove who may send as it. A compromised mailbox gets restricted because nothing else stops it from spending your reputation; unauthenticated custom-domain mail gets refused because recipients can't tell it from spoofing. The durable fix is the same for both: correct SPF and DKIM for every sending service, DMARC alignment on the From domain, and enforcement at p=reject so a hijacked account or an impersonator can't send as your domain from outside your tenant at all. Monitoring the DMARC reports tells you which senders are failing; enforcement is what turns the restriction-and-delist cycle into a solved problem.

Enforce it — don't just monitor it

Palisade's AI agent takes domains all the way to enforcement: hosted SPF, DKIM, DMARC, and MTA-STS records, DMARC reports monitored continuously, and policies advanced to p=reject automatically. Your first domain is free, and the full product is open for 15 days, no card.

Free 15-day trial · No credit card · Your own domain free forever (NFR)

Fixing this across every client domain

For an MSP, the failure mode multiplies: every tenant needs its own DKIM enablement, its own SPF hygiene, its own outbound spam policy tuning, and its own 2 a.m. restricted-user incident when a client mailbox gets phished. Palisade collapses that into one workflow: it hosts and manages the SPF, DKIM, DMARC, and MTA-STS records for every client domain, surfaces failing or unknown senders from DMARC reports before Microsoft or a recipient starts refusing mail, and walks each domain to p=reject automatically. Alerts land in ConnectWise, HaloPSA, or Autotask through native PSA integrations, pricing is per domain ($9, dropping to $7 at 100+ and $5 at 1,000+), and your own MSP domain is a free NFR domain to prove it on.

Frequently asked questions

That's the signature of a restricted user. When an account exceeds Exchange Online's outbound limits or an outbound spam policy threshold, Microsoft blocks sending but leaves receiving intact and lists the account on the Restricted entities page in the Defender portal. Secure the account, then unblock it there; restrictions normally lift within an hour.

Exchange Online allows 10,000 recipients per mailbox per 24 hours, 30 messages per minute over SMTP client submission, and up to 1,000 recipients on a single message. Tenants also carry a license-based Tenant External Recipient Rate Limit (TERRL); trial tenants are capped at 5,000 external recipients per day (per Microsoft's limits page, checked 2026-07-17).

It's a separate outbound IP pool Microsoft uses for messages its filters classify as spam, so the main Microsoft 365 IPs keep their reputation. Microsoft states delivery from that pool isn't guaranteed because many receivers refuse it. Run a message trace and check the OutboundIpPoolName property to see which pool carried your mail.

In the Defender portal, go to Email & collaboration, then Review, then Restricted entities, select the user, and choose Unblock. Reset the password and enable MFA first; Microsoft treats the restriction as a compromise indicator. In PowerShell, Remove-BlockedSenderAddress does the same. Expect the block to clear within an hour, up to 24 in edge cases.

Usually authentication. Microsoft does not DKIM-sign outbound mail from custom domains until you enable it, and recipient systems like Gmail and Outlook.com now reject unauthenticated mail under their sender requirements. Publish SPF, enable DKIM for your custom domain in the Defender portal, add DMARC, and verify with the compliance checker on this page.

No. Outbound spam policies only let you set limits lower than the service caps (values 0 to 10,000, where 0 means service defaults). The 10,000-recipient daily limit and 30-message-per-minute rate are fixed. Microsoft's own guidance for higher volume is Azure Communication Services or a dedicated sending provider instead of Exchange Online.

Microsoft throttles the default onmicrosoft.com domains to 100 external recipients per organization in a 24-hour window; senders past the cap get NDRs with code 550 5.7.236. The domain also carries no reputation of its own. Add a custom domain, authenticate it, and move all outbound mail off the onmicrosoft.com address.

Yes. Microsoft restricts both user accounts and connectors; a restricted entity is either one, blocked from sending over indications of compromise. If on-premises servers relay through a blocked connector, all of that route's mail stops. Connectors have their own removal flow on the same Restricted entities page in the Defender portal.

Related guides

Email deliverability, fixed: the full guide