Microsoft 365 cold email deliverability troubleshooting

Microsoft 365 cold email deliverability troubleshooting starts with one question: did Exchange Online send the message, did another server reject it, or was it accepted and filtered after delivery?

Those are different failures. A restricted mailbox needs an admin investigation. A remote rejection needs the exact SMTP response. A message accepted into junk needs recipient-side or placement evidence. Low replies need a wider campaign diagnosis.

Preserve one failed example before changing anything. Save the sender, recipient domain, UTC timestamp, message ID, full non-delivery report when present, message trace result, and received headers when available.

Classify the Microsoft 365 symptom first

Put the incident in the narrowest row you can prove.

Symptom	What it proves	Check first
Message never appears in trace	Microsoft 365 may not have received the submission	Sending tool connection, mailbox authentication, campaign logs, UTC time window
Sender gets 5.1.8	Microsoft 365 restricted the outbound sender	Restricted entities, alerts, sign-in activity, sending-limit evidence
Trace shows failed or a remote 4xx or 5xx	A transport or destination system did not accept the message	Exact enhanced status code, response text, recipient domain, affected sender
Trace shows sent or delivered	Exchange Online completed its recorded transport action	Recipient-side acceptance, headers, folder, quarantine, gateway evidence
Message reaches junk	The receiver accepted and classified the message	Authentication results, reputation, message surface, recipient policy
Replies fall while acceptance stays stable	Campaign performance changed	Reply routing, provider-level scope, placement sample, audience, message changes

Do not turn a trace status into a folder-placement claim. Microsoft notes that a message marked as spam or sent to quarantine can still appear as Delivered in Exchange Online message trace. For mail sent to an external provider, the trace cannot see the final folder inside that provider.

1. Confirm that the message entered Exchange Online

Search message trace in the Exchange admin center with the exact sender, recipient, and UTC time range. Record the message ID and event details.

If the message is absent, check the layer before transport:

• The mailbox is still connected to the sending tool.
• The tool completed the send instead of queuing, pausing, or failing it.
• The account can send a manual test through the same Microsoft 365 mailbox.
• The trace used the correct UTC window and envelope recipient.
• The connector or SMTP submission method is the one the operator expects.

A missing trace is not a reputation result. It means there is no Exchange Online transport result yet. Fix submission or connection evidence before investigating inbox placement.

If the message is present, export or copy the event details before retrying. The next decision comes from the status and the SMTP response, not from a general dashboard health score.

2. Check whether Microsoft restricted the sender

Microsoft 365 can restrict a user or connector after suspected outbound spam or a sending-limit event. Microsoft documents 550 5.1.8 Access denied, bad outbound sender as a common symptom for a restricted user.

Open the Restricted entities page in the Microsoft Defender portal and review the related alert. Follow Microsoft’s blocked-user investigation and recovery steps before removing the restriction.

Check for:

• Unexpected sign-ins.
• Unknown inbox or forwarding rules.
• Messages the operator did not send.
• A sudden jump in recipients or send cadence.
• A legitimate campaign that crossed a service or policy limit.
• A connector that was used by an unexpected application or tenant.

Do not simply unblock and resume. If the account was compromised, secure it first. If planned volume triggered the restriction, reduce the affected path and review whether Exchange Online is the right transport.

Microsoft states that Exchange Online is not designed for bulk mailing. Its sending-limit guidance documents service limits, including a 10,000-recipient rolling daily limit per mailbox and a 30-message-per-minute submission limit. Those are service ceilings, not recommended cold email volumes and not proof that sending below them is safe.

3. Read the complete NDR before editing DNS

Copy the enhanced status code and the diagnostic text from the non-delivery report. Keep the remote server response intact.

Use the evidence to separate causes:

Evidence	Likely investigation	First action
5.1.8 bad outbound sender	Microsoft 365 sender restriction	Review Restricted entities and security alerts
550 5.7.23	SPF or outbound authentication path	Compare live SPF with the actual sending source
550 5.7.1	Authentication, connector, relay, or recipient policy	Read the complete response and message trace
Remote 421 or other 4xx	Temporary deferral, throttling, or policy	Group by recipient provider and retry timing
Remote 550 invalid recipient	Address or recipient-domain failure	Validate the address and recipient MX
Microsoft 5.7.511 or banned-IP response	Microsoft receiver-side IP block	Confirm the source IP, then follow the named delist route

The same leading status class can hide different causes. The response text, emitting server, sender, and recipient-provider pattern matter.

For an external sender rejected by Microsoft, Microsoft’s delisting guidance applies only when the NDR identifies the sending IP as blocked and directs the sender to the portal. A delist request is not a generic repair for junk placement, authentication failure, or weak campaign performance.

Use the cold email bounce troubleshooting checklist when rejection is the main symptom. It provides a broader workflow for separating invalid recipients, dead domains, sender failures, and provider blocks.

4. Verify Microsoft 365 authentication on a real message

Check live DNS first, then verify what one received message actually used.

For SPF:

• Publish exactly one SPF record for the sending domain.
• Include every active sender without exceeding the SPF lookup limit.
• Confirm the envelope sender domain and connecting source used by the message.
• Remove retired sending sources only after proving they are inactive.

Microsoft’s SPF setup guidance states that SPF alone is not enough. The domain also needs a deliberate DKIM and DMARC setup.

For a custom Microsoft 365 domain, do not assume DKIM signing is active. Microsoft’s custom-domain DKIM instructions require two selector CNAME records and enabling signing for the domain. Both selectors matter because the inactive selector supports key rotation.

In the received message, inspect:

• Authentication-Results for SPF, DKIM, DMARC, and composite authentication results.
• DKIM-Signature for the active selector and d= signing domain.
• From and Return-Path for alignment.
• Received headers for the route and connecting IP.
• Any ARC results when another system modified or relayed the message.

A selector can exist in DNS while the tenant is not signing with the custom domain. A dashboard can show the domain as connected while a third-party sending route uses another return path. The received message resolves those assumptions.

Run the SPF, DKIM, and DMARC checker for the public layer. Then compare its result with the live message headers.

5. Separate Microsoft 365 as sender from Microsoft as receiver

Microsoft 365 can be the service sending your campaign. Microsoft can also be the service receiving a message at Outlook.com or at a corporate Exchange Online tenant. These roles create different evidence.

When Microsoft 365 sends to Gmail, Yahoo, or another provider, your tenant’s message trace covers the sender-side transport. The recipient provider owns the final filtering decision.

When any platform sends to a Microsoft-hosted recipient, the receiving Microsoft system can reject, quarantine, or place the message in junk. Recipient admins may have tenant-specific anti-spam policies, transport rules, blocked-sender lists, security gateways, or user rules.

One company-wide failure pattern can be local to that tenant. Compare:

• Outlook.com consumer addresses.
• Microsoft 365 business tenants at more than one organization.
• Gmail and Yahoo controls.
• Corporate domains behind non-Microsoft security gateways.

If only one company is affected, ask its administrator for the receiving trace, quarantine reason, or relevant headers. Do not generalize one tenant’s rule into a Microsoft-wide reputation conclusion.

The receiver requirements guide covers the public and message-level evidence available for Gmail, Yahoo, and Microsoft receivers.

6. Inspect the message surface after authentication passes

Passing SPF, DKIM, and DMARC removes one class of failure. It does not prove good inbox placement.

Inspect the message that was sent, not only the template shown in the campaign editor:

• Every visible link and redirect hostname.
• Open-tracking pixels.
• A branded tracking CNAME and the provider host behind it.
• Plain-text and HTML parts.
• Link destinations added by signatures, calendar tools, or templates.
• Unsubscribe headers and the visible opt-out path when they apply.
• Differences between the failed message and a prior successful one.

Then review sending behavior:

• Recent changes in volume or cadence.
• Bounce and complaint trends.
• New domains, new mailboxes, or long-idle accounts.
• Concentration at one recipient provider.
• Changes to the offer, audience, subject, copy, links, or tracking.

Use the tracking domain checker for the configured tracking host. Use the spam placement troubleshooting guide when accepted mail reaches junk even though authentication passes.

7. Know the common false assumptions

Avoid these shortcuts:

“Microsoft 365 accepted the campaign, so the setup is ready.” Exchange Online submission proves that the service received the message. It does not verify every live authentication identity, tracking host, reputation signal, or receiver rule.

“Message trace says Delivered, so it reached the inbox.” Delivered is a transport status. It can coexist with junk or quarantine handling, and sender-side trace cannot see an external provider’s final folder.

“The Microsoft 365 DNS setup screen is green, so DKIM passed.” Record presence and tenant state are inputs. A received message proves which selector and signing domain were actually used.

“I stayed below the published sending limit, so Microsoft will not restrict the mailbox.” Service limits are not permission to send unsolicited bulk mail and not a reputation guarantee. Microsoft can still detect suspicious patterns or route mail through a high-risk path.

“A Microsoft delist request will fix spam placement everywhere.” Delisting addresses a named Microsoft block for a specific source IP. It does not repair content classification, recipient rules, domain reputation, or another provider’s decision.

“A manual email to myself reached the inbox, so the campaign is fine.” A same-tenant or familiar-recipient test does not reproduce the campaign’s route, message surface, recipient mix, or filtering context.

8. Run a controlled placement test only when the question remains

Run a controlled inbox placement test when all of these are true:

1. The message appears in Microsoft 365 trace and no sender restriction explains the incident.
2. The destination accepted the test or no clear rejection remains unresolved.
3. SPF, DKIM, DMARC, and alignment pass on a representative received message.
4. The live tracking and link hosts have been inspected.
5. The unresolved question is where accepted mail lands across providers or Microsoft tenants.

Keep the test controlled:

• Use the same mailbox and sending route as the affected campaign.
• Use the exact campaign message or record every intentional change.
• Hold links, tracking, timing, and volume constant for the baseline.
• Include Microsoft consumer and business seeds plus non-Microsoft controls.
• Record Inbox, Other tab, Junk, Missing, or Rejected separately.
• Change one variable in the next run.

A placement test is a dated sample. It can show that the same message landed differently across its test mailboxes. It cannot guarantee the next prospect’s outcome.

If the test reproduces Microsoft-only junk placement, compare the received headers and Microsoft tenant types before changing the sender. If the result is poor across providers, broaden the investigation to reputation, message surface, list quality, and sending behavior. If the test does not reproduce the incident, keep the original failed message and recipient-domain evidence. Do not overwrite it with a clean sample.

The seed-list testing and infrastructure QA comparison explains why the placement sample and the setup verdict belong beside each other.

Microsoft 365 cold email troubleshooting checklist

Require evidence in every row before resuming or scaling.

Area	Evidence to save	Decision
Submission	Sending-tool event, trace presence, UTC timestamp, message ID	Ready / Needs Fix / Do Not Launch
Restrictions	Restricted entities result, alert, security review, full 5.1.8 NDR	Ready / Needs Fix / Do Not Launch
Transport	Trace events, remote SMTP response, recipient provider	Ready / Needs Fix / Do Not Launch
Authentication	Live SPF, both DKIM selectors, DMARC, received-message alignment	Ready / Needs Fix / Do Not Launch
Message surface	Headers, links, tracking hosts, text and HTML parts	Ready / Needs Fix / Do Not Launch
Reputation and behavior	Domain and IP evidence, complaints, bounces, cadence changes	Ready / Needs Fix / Do Not Launch
Placement	Controlled result by provider and Microsoft tenant	Evidence only
Recovery	One changed cause, deterministic rerun, new trace and headers	Ready / Needs Fix / Do Not Launch

FAQ

Why is Microsoft 365 blocking my outbound cold email?

Start with the NDR and the Restricted entities page. A 5.1.8 response can mean the mailbox was restricted after suspected spam or a sending-limit event. A remote 4xx or 5xx response can instead come from the recipient system. Preserve the exact code before changing DNS or reconnecting the mailbox.

Does Delivered in Microsoft 365 message trace mean the email reached the inbox?

No. Message trace proves what Exchange Online did with the message and can expose routing, policy, or delivery events. It does not prove that an external recipient placed the message in the inbox. You need recipient-side evidence or a controlled placement test for that question.

Does Microsoft 365 enable DKIM automatically for a custom domain?

Do not assume it does. Microsoft documents a separate DKIM setup for custom domains using two selector CNAME records and a tenant-side signing setting. Verify a real received message because published records alone do not prove that the active message was signed and aligned.

Can Microsoft 365 cold email go to spam when SPF, DKIM, and DMARC pass?

Yes. Authentication proves identity and alignment. It does not prove good reputation, wanted content, safe tracking hosts, stable sending behavior, or favorable recipient-side policy.

When should I run an inbox placement test?

Run a controlled placement test after you confirm that Microsoft 365 sent the message, no restriction or clear rejection explains the incident, authentication passes on a real message, and the unresolved question is where accepted mail lands. Keep the sender, message, links, timing, and volume controlled so the result is interpretable.

Check the sending domain before the next test

Run the free email deliverability checker for the Microsoft 365 sending domain. It checks observable authentication, routing, reputation, domain-age, tracking, and SMTP identity signals.

A passing infrastructure result does not predict inbox placement. It removes known setup uncertainty before you use message trace, received headers, and a controlled placement sample to answer the remaining question.