Provider deliverability · Microsoft 365 / Exchange Online

Why is Microsoft blocking my automated emails?

Samuel Chenard

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

Microsoft blocks automated mail (scanners, CRMs, monitoring alerts) for three reasons: the app or device fails SPF and DKIM alignment for your domain; it uses a submission method the tenant no longer accepts, like Direct Send or Basic-auth SMTP; or it trips Exchange Online throttling. The Office 365 mail filter treats unauthenticated app mail as anonymous internet traffic.

The 30-second check

Start with the record that decides most of these blocks. Automated senders almost always fail because the platform or device IP was never added to the domain's SPF record, so the Office 365 mail filter sees mail claiming to be your domain from an address it has no reason to trust. The free SPF checker shows exactly what your record authorizes right now.

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
The app or device isn't in your SPF record, or DKIM doesn't alignThe classic third-party sender problem. Your CRM, ticketing system, or copier sends as yourdomain.com, but its IPs aren't in your SPF record and its DKIM signature (if any) signs the vendor's domain instead of yours. Exchange Online Protection scores that mail as unauthenticated, and Microsoft's own device-sending doc tells you to publish SPF, DKIM, and DMARC for exactly this reason (checked 2026-07-17).
The device uses Direct Send and the tenant now rejects itDirect Send (unauthenticated port-25 delivery to your MX endpoint) was the default trick for scanners and LOB apps for a decade. Microsoft shipped a tenant switch, RejectDirectSend, that refuses it outright with a 550 5.7.68 bounce, and Microsoft's device doc now says most customers don't need Direct Send and that it is working on disabling it by default. If IT hardened the tenant, your scanner's mail stopped that day.
Direct Send mail is filtered like anonymous internet trafficEven where Direct Send still works, Microsoft's doc is explicit: messages are treated just like anonymous email from the internet, with all scanning and protections applied. So your alert mail competes with spam on equal terms, lands in Junk or quarantine, and mail addressed to anyone outside your tenant is rejected outright, because Direct Send only delivers to your own Microsoft 365 recipients.
SMTP AUTH is disabled, or Basic authentication is on its way outSMTP AUTH is disabled by default for organizations created after January 2020, and Microsoft disabled it in every tenant where it wasn't being used. On top of that, Basic authentication (plain username and password) for SMTP AUTH is scheduled for retirement: Microsoft's updated timeline disables it by default for existing tenants at the end of December 2026. Devices that can't do OAuth or TLS 1.2+ fail to submit at all.
You hit Exchange Online's throttling limitsAuthenticated client submission is capped at 10,000 recipients per day and 30 messages per minute per mailbox (per Microsoft's device-sending doc). A monitoring system having a bad night can burn through 30 messages a minute in seconds, and everything after that defers or fails. SMTP relay via connector has higher but still 'reasonable' limits enforced by Microsoft's outbound protections.
Connector requirements aren't met: dynamic IPs and third-party hostsSMTP relay connectors authenticate by TLS certificate or static public IP. Microsoft states dynamic IP addresses aren't supported or allowed, and that you can't use SMTP relay to send from a third-party hosted service such as Azure. An app on a cloud VM or a device behind a changing IP silently stops matching the connector and gets treated as an unknown internet sender.
Your sending IP is on Microsoft's blocked senders listIf the app sends from its own infrastructure and that IP picked up a bad reputation (or inherited one from a shared range), Exchange Online refuses the connection with codes in the 5.7.606 to 5.7.649 range. This is an IP-reputation block, not a content verdict, and it has its own self-service removal path at sender.office.com.
Seven-item checklist card for getting automated mail past the Office 365 filter: a supported submission method instead of Direct Send, the platform in the SPF record under 10 lookups, DKIM signing as your own domain, OAuth with TLS 1.2 or later before Basic auth retires, a certificate or static IP for connectors, volume under Microsoft's per-mailbox limits, and a sending IP clear of Microsoft's blocked senders list.

How to fix it, step by step

  1. Run the SPF check on your sending domain

    Use the free checker above (or at /tools/spf). It shows every IP and include your record currently authorizes, so you can see in seconds whether the CRM, scanner subnet, or monitoring host that's bouncing is actually in there. Check the DNS lookup count too; SPF breaks past 10 lookups.

  2. Put each mail source on the right Microsoft method

    Microsoft documents four: SMTP AUTH client submission (smtp.office365.com, port 587, TLS 1.2+, a licensed mailbox, sends anywhere), SMTP relay via an inbound connector (certificate or static IP, no mailbox needed, higher limits), Direct Send (internal recipients only, fully filtered), and High Volume Email for internal bulk. Match the method to what the device can do; don't leave a capable app on Direct Send.

  3. Authenticate every third-party platform as your domain

    Add the vendor's documented include or IP range to your SPF record, then enable custom-domain DKIM signing at the vendor so the signature says yourdomain.com, not the vendor's default. Verify with /tools/spf and /tools/dkim. Alignment with your From domain is what makes DMARC pass and what stops the filter treating the mail as spoofed.

  4. Clear 550 5.7.68 with a connector, not a workaround

    If bounces cite 550 5.7.68, the tenant has RejectDirectSend enabled. Don't ask IT to turn it back off; that switch exists because attackers abused Direct Send to spoof internal mail. Instead, create an inbound connector that attributes the device's certificate or static IP to your organization, or move the device to authenticated submission.

  5. Migrate devices off Basic authentication before the deadline

    Microsoft's updated timeline disables Basic auth for SMTP AUTH by default for existing tenants at the end of December 2026, with new tenants not getting it by default. Move each device or app to OAuth-based SMTP AUTH where supported; where it isn't, Microsoft points to High Volume Email for internal mail or Azure Communication Services for external.

  6. Size for the limits, re-test, and keep DMARC reports flowing

    Keep client-submission senders under 30 messages per minute and 10,000 recipients per day per mailbox, or move heavy streams to a connector. Then send a test through each repaired path, confirm spf=pass, dkim=pass, and dmarc=pass in the received headers, and monitor DMARC aggregate reports so the next unauthenticated app shows up in a report instead of a bounce.

Related free tools: DKIM checker · DMARC checker · Microsoft compliance check · IP reputation · Blocklist checker

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

If your automated mail also goes to consumer Outlook.com addresses (outlook.com, hotmail.com, live.com), Microsoft's May 5, 2025 sender requirements apply: domains sending more than 5,000 messages a day there must pass SPF, DKIM, and a published DMARC policy of at least p=none with alignment. Microsoft's documented rejection for non-compliance is "550 5.7.515 Access denied, sending domain <domain> does not meet the required authentication level." (per Microsoft's postmaster site and support documentation, checked 2026-07-17). Transactional volume counts the same as marketing volume, so a busy notification stream can cross the threshold on its own.

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

Strip away the plumbing (ports, connectors, auth methods) and every cause above is the same question: can Microsoft prove this message legitimately represents your domain? Direct Send died as a default because unauthenticated mail claiming to be you is indistinguishable from spoofing; that's also why the Office 365 mail filter quarantines your own scanner's output. The durable fix is to make the proof automatic: SPF covering every legitimate app and platform, DKIM signing aligned to your From domain, and DMARC enforced at p=reject so mail that can't prove itself is refused everywhere, by policy, instead of case by case. Monitoring the DMARC reports shows you which automated sender breaks next; enforcement is what keeps the fixed ones fixed.

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.

Start free trialBook a demo

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

Fixing this across every client domain

Automated senders are where multi-tenant deliverability goes to die: every client fleet has scan-to-email copiers, a legacy CRM, an RMM alert stream, and none of them were authenticated by whoever set them up. Each Microsoft policy change (RejectDirectSend, the Basic auth retirement) breaks them tenant by tenant, on Microsoft's schedule, not yours. Palisade turns that into one workflow: it hosts and manages SPF, DKIM, DMARC, and MTA-STS records for every client domain, surfaces each unauthenticated app in the DMARC reports before Microsoft starts bouncing it, and walks every 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 first.

Frequently asked questions

Usually one of three Microsoft changes: SMTP AUTH is disabled (it's off by default for organizations created after January 2020), the device only speaks Basic authentication or old TLS (Microsoft requires TLS 1.2 or later), or the tenant enabled RejectDirectSend and the copier was relying on unauthenticated Direct Send delivery.

SMTP AUTH submits through a licensed mailbox on smtp.office365.com and can reach any recipient. SMTP relay authenticates a device by certificate or static IP through an inbound connector, with higher limits. Direct Send delivers unauthenticated to your MX endpoint, reaches only your own tenant's recipients, and is fully spam-filtered.

It's the bounce from Microsoft's Reject Direct Send feature: "TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources". The recipient tenant has opted out of accepting unauthenticated mail that claims its own domains. Fix it by attributing your device through an inbound connector or by moving to authenticated submission.

It depends on the path. Direct Send messages are treated, in Microsoft's own words, just like anonymous email from the internet, so all scanning and protections apply even for internal recipients. Authenticated client submission bypasses most spam checks for mail to your own tenant's mailboxes, which is one more reason to authenticate.

Client SMTP submission is capped at 10,000 recipients per day and 30 messages per minute per mailbox. SMTP relay via connector has no fixed published number; Microsoft imposes 'reasonable limits' through its outbound protections. High Volume Email removes recipient and rate limits but only for internal recipients.

Not for long. Microsoft's updated retirement timeline disables Basic authentication for SMTP AUTH by default for existing tenants at the end of December 2026, and new tenants won't have it by default. Move apps to OAuth-based SMTP AUTH, an inbound connector, High Volume Email, or Azure Communication Services before then.

If bounces show codes between 5.7.606 and 5.7.649, submit the IP through Microsoft's self-service delist portal at sender.office.com; Microsoft says removal can take 24 hours or longer. For a 5.7.511 block, forward the bounce to delist@microsoft.com. Fix SPF and DKIM first, or the listing tends to come back.

Because the CRM can't prove it's you. Its IPs aren't in your SPF record, and its DKIM signature signs the vendor's domain rather than yours, so the mail fails alignment and reads as spoofed. Add the vendor's SPF include, enable custom-domain DKIM in the CRM, and verify both with the free checkers.

Related guides

Why is Microsoft 365 blocking outbound emails?Why is Outlook blocking my emails?How to stop emails going to spam in OutlookWhy are my emails being blocked?550 5.7.1550 5.7.509421 4.7.0include:10-DNS-lookup limitadkim / aspfselector
Email deliverability, fixed: the full guide