Some customers sending mail from external domains to recipients hosted on Outlook or Microsoft 365 are seeing messages disappear. The messages do not arrive in the inbox or Junk folder, and there is no rejection or bounce. SPF, DKIM, and DMARC all pass, and the sending IPs do not appear on the usual blocklists. Exim logs show that Microsoft's servers accept the messages immediately.
The same domains can send successfully to free Outlook.com or Hotmail accounts, where the messages arrive in the inbox and authentication checks pass. The sending server is about two months old. During its first few days, messages were rejected even by Hotmail, but Microsoft support resolved that quickly. Delivery then worked until this problem began recently. We do not administer the affected Microsoft 365 tenants, and support has repeatedly said they are not seeing a Microsoft-wide delivery problem. What should we investigate next?
4 Answers
MTA-STS is worth checking as part of a general mail-flow review, but it is not normally required for a sender to deliver mail to Outlook-hosted domains. Focus first on message trace, recipient-side filtering, connector configuration, and the reputation of the relatively new sending IP or domain. A recent reputation or throttling change could affect some tenants while allowing delivery to consumer accounts.
An SMTP acceptance is not the same as final delivery. The recipient tenant may accept the message and then send it to quarantine, moderation, a transport rule, or another filtering system. Someone with access to the recipient tenant needs to check message trace and the quarantine or threat-protection logs. Without that information, the sender-side logs cannot show what happened after acceptance.
Have the recipient administrator verify tenant-specific mail-flow rules, quarantine policies, safe-list settings, and mailbox rules. Microsoft 365 often accepts suspicious mail and silently routes it away from the mailbox instead of rejecting it. A message trace that follows the message ID from receipt through filtering should reveal whether it was delivered, quarantined, redirected, or dropped.
Check whether the affected tenants use a third-party gateway or filtering service before Microsoft 365. Those systems can alter the apparent client IP and cause DMARC alignment or reputation checks to fail even when the original message passed authentication. If there is an inbound connector, the tenant administrator may need to configure enhanced connector filtering so Microsoft can evaluate the original sending source correctly.
DMARC aggregate reports may help confirm whether the message is failing authentication after passing through another gateway, although they will not explain every filtering decision.
That makes sense, but getting the affected tenants to investigate has been difficult. The sending logs only show successful acceptance by Microsoft.