Microsoft 365 Email Deliverability: Test Before Sending Company-Wide

Microsoft 365 email is tenant-scoped. When something goes wrong — a missing DKIM selector, an Exchange Online connector pointing at the wrong smart host, an SPF record that still lists last year's marketing platform — the impact does not stop at one mailbox. It hits every user sending under your primary domain. The helpdesk queue fills up with "my reply never arrived" tickets, sales blames marketing, IT blames the provider, and the executive team wants answers by end of day.

The fix is straightforward in hindsight: run an inbox placement test before any tenant-wide mail change hits production. Send a campaign from the new connector, the new signing key, or the new outbound IP to a set of seed mailboxes that mirror where your real recipients live — Outlook.com, Gmail, Yahoo, and the major corporate tenants. If placement drops, you know before the rollout. If it holds, you ship with evidence.

How Microsoft 365 actually sends your mail

Exchange Online Protection (EOP) handles both inbound filtering and outbound delivery for every M365 tenant. When a user clicks Send in Outlook, the message hops through the tenant's outbound connectors, gets signed (if DKIM is enabled for the sending domain), and hands off to the recipient's MX. Receivers then evaluate SPF alignment against your MAIL FROM, DKIM alignment against the header From, and DMARC policy for the aligned domain.

Three configuration surfaces in M365 quietly decide whether that message lands in the inbox:

Accepted domains & DKIM selectors. Each sending domain needs DKIM explicitly enabled in the Defender portal. M365 creates two CNAMEs (selector1 and selector2) that must be present in DNS before signing activates.
Outbound connectors. If your tenant routes mail through a smart host (a gateway, archiver, or a hybrid on-prem Exchange), the connector's authentication method and TLS certificate affect how EOP signs and how receivers see the sender IP.
SPF record for the tenant. include:spf.protection.outlook.com is mandatory. Third parties that send on your behalf (HubSpot, Mailchimp, ticketing systems) each need their own include. SPF is capped at ten DNS lookups — exceed it and every recipient sees permerror.

The ten-lookup SPF trap

Tenants accumulate SPF includes over years. Once you hit eleven lookups, SPF evaluation fails for everyone — no warning, no email, just quiet inbox decay. Audit the chain before you add one more vendor.

Inbound vs outbound: both matter

Most teams think deliverability in one direction — can our users' mail reach external recipients? With M365, the inbound side matters just as much. If your tenant's inbound rules misclassify replies from a prospect, your sales rep never sees the answer, the deal stalls, and from the outside it looks like a deliverability issue.

A proper pre-deploy check covers both:

Outbound placement. Send from a user mailbox in the new configuration to seed addresses across Gmail, Outlook.com, Yahoo, and the corporate M365 tenants you care about. Record inbox versus Junk versus Promotions placement per provider.
Inbound placement. Send from a matching set of external senders into a seed mailbox inside your tenant. Check whether EOP routed them to Focused, Other, Junk, or Quarantine — and whether any custom transport rules you added are overriding the verdict.

What to check before a tenant-wide change

Whether you are rolling out a new DKIM selector, switching to a new outbound smart host, enabling DMARC enforcement, or onboarding a new sending vendor — the checklist is the same.

1. Confirm DKIM is signing what you think it is

View the raw headers of a test message. The d= value in the DKIM-Signature header must match the header From domain, or DMARC will fail alignment. A common M365 mistake is a tenant signing with d=onmicrosoft.com because DKIM for the vanity domain was never enabled.

2. Confirm SPF resolves cleanly

Run your SPF through a lookup counter. Anything ten or above is a live incident. Flatten vendor includes, retire abandoned platforms, and consider moving rarely-used third-party senders to a subdomain with its own SPF.

3. Confirm DMARC policy matches your rollout stage

A tenant at p=none will not affect placement much, but it will not protect you either. A tenant jumping straight from p=none to p=reject without first fixing alignment for every legitimate sender is where catastrophic drops happen. Move via p=quarantine pct=25 first.

4. Seed-test from the new configuration

Send a representative message to a seed set that mirrors your audience. A single seed run after the DKIM rotation, after the connector change, or after the SPF edit gives you live evidence that placement is stable. If inbox drops from 98 percent to 60 percent, you rollback the change — you do not rollback the entire mail platform.

CRM integration in beta

A native integration for leading CRMs is in private beta — placement tests inside the CRM, alerts on drops.

→ Join the beta waitlist

A concrete pre-deploy routine

Here is a workable pattern for a mid-size tenant with a few hundred users and two or three third-party senders:

Day -2  Pull the current SPF, DKIM, DMARC records. Snapshot them.
Day -2  Enumerate every connector, transport rule, and journaling rule.
Day -1  Make the planned change in a staging sending domain
         (e.g. mail-test.your-domain.com) rather than the primary.
Day -1  Run a seed placement test from the staging domain.
Day  0  If placement holds, apply the same change to the primary domain.
Day  0  Run a second placement test from a real user mailbox.
Day +1  Review DMARC aggregate reports for alignment failures.
Day +7  Re-run the placement test. Confirm nothing drifted.

The pattern does not require new tooling — it requires discipline. The seed placement test is the single piece of evidence that turns a "we think it's fine" hand-wave into a "here is the data" green light.

Signals that point at M365 specifically

When a placement test comes back bad, the failure pattern often identifies the root cause:

Outlook.com Junk, Gmail inbox. Almost always DMARC alignment. Microsoft is stricter on alignment than Google. Check the d= on your DKIM signature.
All providers Junk. SPF permerror or a listed sending IP. Check your SPF lookup count and run the outbound IP through a blacklist lookup.
Gmail Promotions, everything else inbox. Content, not infrastructure. Your M365 config is fine — your template is triggering Google's marketing heuristic.
Corporate M365 inbox, personal Outlook.com Junk. Outlook.com applies consumer-grade bulk filters that enterprise tenants override with their own allow lists. Treat the consumer result as the true signal.

FAQ

Does enabling DKIM in Microsoft 365 require a tenant-wide outage?

No. Enabling DKIM publishes two CNAME selectors and flips signing on for a given domain — existing mail flow continues throughout. The risk is if you enable DKIM without the CNAMEs in DNS, in which case signing fails silently. Publish DNS first, verify resolution, then enable.

Can we test a new outbound connector without affecting real users?

Yes. Route a dedicated test domain (or a test distribution group) through the new connector using a transport rule. Send from that scope, measure placement with a seed test, and only widen the rule once results are green.

How often should a tenant run placement tests?

Continuously for any team doing meaningful outbound volume — weekly is a reasonable floor. And always before DNS changes, connector changes, new vendor onboarding, or DMARC policy tightening.

What is the single biggest cause of M365 placement drops we see?

DMARC alignment failures after a third-party sender is added without its own DKIM on the sending domain. The vendor authenticates under their own identity, alignment fails, and strict-policy receivers push to Junk. Enable custom DKIM for every vendor that sends as your domain.