Microsoft 365 Email Going to Spam? Fix It

Start with the real Microsoft 365 fix

If Microsoft 365 email is going to spam, do not start by rewriting every subject line. Start by proving that your domain is allowed to send the mail.

Gmail, Outlook.com, and Microsoft 365 tenants make spam decisions from many signals, but authentication is the fastest thing you can audit and fix. Microsoft documents the same core chain: SPF identifies allowed sending sources, DKIM signs the message, and DMARC checks whether SPF or DKIM aligns with the visible From domain. Google sender guidelines also say unauthenticated mail can be marked as spam or rejected.

Run a free InboxRadar domain check first. It reads your live SPF, DKIM, DMARC, and MX records and tells you which record is missing, broken, too weak, or drifting.

• Send a test message from the exact Microsoft 365 mailbox or app that is landing in spam.
• Open the full recipient headers and look for spf=, dkim=, dmarc=, compauth=, and the domain each result used.
• If SPF, DKIM, or DMARC fails or uses the wrong domain, fix DNS before changing copy, templates, or sending volume.

Fix SPF for Microsoft 365

SPF is a DNS TXT record that lists the hosts allowed to send mail for your domain. For Microsoft 365, the common include is spf.protection.outlook.com.

If Microsoft 365 is your only sender, Microsoft's setup example for a cloud-only domain uses v=spf1 include:spf.protection.outlook.com -all. If you also send through a CRM, help desk, billing app, website server, or email service provider, those sources must be included in the same SPF record. Do not publish two SPF records for the same domain.

Be careful with the ending. -all tells receivers that hosts not listed in SPF are not authorized. ~all is a softer testing posture, but unlisted sources still do not satisfy the SPF side of DMARC because DMARC needs an aligned SPF pass or an aligned DKIM pass. Never use +all.

Also stay under the SPF DNS lookup limit. RFC 7208 sets a limit of 10 lookup-causing mechanisms and modifiers during SPF evaluation. Too many nested includes can produce SPF permerror, which can hurt filtering outcomes even when the record looks long and complete.

• Keep exactly one SPF TXT record at the sending domain.
• Include Microsoft 365 and every other legitimate sender.
• Remove stale senders that no longer send for your domain.
• Keep the record under the 10 DNS lookup limit.

Turn on DKIM signing for your custom domain

DKIM matters because SPF can break when mail is forwarded, but a valid DKIM signature can still survive and pass DMARC if the message is not modified in a way that breaks the signature.

In Microsoft 365, DKIM for a custom domain is not finished just because the domain is verified. You need the DKIM DNS records Microsoft gives you, usually selector-based CNAME records, and signing must be enabled for the custom domain. The important result is that outbound mail has a DKIM-Signature header whose d= domain aligns with the visible From domain.

If your message is signed only by a vendor domain, or by an onmicrosoft.com domain while the From address is your custom domain, DMARC may not get the aligned DKIM pass you need. Check the headers, not just the admin toggle. RFC 6376 is the DKIM source of truth.

• Enable DKIM signing for the custom Microsoft 365 domain.
• Publish the selector records exactly as Microsoft provides them.
• Send a fresh test after DNS propagation.
• Confirm the header shows d=yourdomain.com or an aligned subdomain.

Publish DMARC without breaking good mail

DMARC is the rule that ties SPF and DKIM to the domain people actually see in the From address.

A safe starting record is v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com at _dmarc.yourdomain.com. That does not quarantine mail. It lets you collect aggregate reports and see which services are passing, failing, or spoofing your domain. After every real sender passes with SPF or DKIM alignment, move toward p=quarantine and then p=reject if your mail streams can handle it.

DMARC passes when SPF or DKIM passes and aligns with the From domain. It fails when both aligned checks fail. That means a message can show spf=pass and still fail DMARC if SPF passed for a different envelope domain. Microsoft documents this alignment requirement for Microsoft 365, and RFC 7489 defines the same policy model with p=none, p=quarantine, and p=reject.

• Start at p=none with rua reporting.
• Identify every sender in the reports before enforcing.
• Fix SPF or DKIM alignment for each sender.
• Only tighten policy after legitimate mail is passing.

Check MX, blocklists, and reputation next

If SPF, DKIM, and DMARC all pass and align, Microsoft 365 mail can still land in spam because authentication is necessary, not a guarantee.

Confirm your MX points to the right place for inbound mail and that old gateways, forwarding rules, or hybrid Exchange routing are not rewriting messages in a way that breaks authentication. For inbound Microsoft 365 mail, MX commonly points at a host under mail.protection.outlook.com. For outbound, make sure apps are not bypassing Microsoft 365 with an unauthenticated server while still using your domain in the From address.

Then check public blocklists and sending behavior. A compromised mailbox, high bounce rate, bought list, deceptive subject line, missing unsubscribe path, or sudden volume jump can make Outlook or Gmail place mail in spam even when SPF, DKIM, and DMARC pass. Microsoft also uses reputation, sender history, recipient history, and behavioral signals in addition to explicit authentication.

• Review recent sign-in and sending activity for compromised Microsoft 365 accounts.
• Check whether your sending IP or domain appears on major blocklists.
• Stop sending to old, scraped, or unengaged lists.
• Use a real From address and Reply-To address that can receive mail.
• For newsletters or bulk mail, include a clear unsubscribe link and honor it quickly.

Use the headers to pick the right fix

The fastest way to stop guessing is to compare what DNS says with what the recipient headers say.

If headers show spf=fail, fix the SPF source list or the envelope sender. If they show dkim=fail or dkim=none, fix Microsoft 365 DKIM selectors and signing. If they show dmarc=fail, fix alignment, not just the raw SPF or DKIM result. If authentication passes but the message still lands in spam, move to reputation, content, list quality, and blocklist checks.

InboxRadar is built for this audit path. Check the domain at /#check, then use the related deliverability guides when you need a deeper SPF, DKIM, DMARC, or blacklist walkthrough.