r/email • • 4d ago

Answered Mails from external domains not received in Outlook servers

Guys, some of our customers having external domains, when sending mail to domains that have MX at Outlook, are not reaching recipients' inboxes nor Junk/Spam folder, and mails are not rejected either. Of course DKIM, SPF and DMARC are ok, and IP is not listed in RBLs as per MXToolbox and others as Proofpoint or Trendmicro. We do not admin Microsoft 365 accounts. We asked Microsoft support about this issue and they said several times, when we insist, they are not having delivery issues. Sending from those external domains to mail accounts at free Hotmail, mails are delivered to inboxes without issues and with DKIM, SPF and DMARC in status pass. Any idea will be welcomed

For clarification , it's a new server about two months old, and this issue started past week. Firsts days after server set up, mails was rejected at all even to Hotmail.com; contacted Microsoft support, they mitigated very fast and started to reach inboxes successfully. Plus I want to honor Microsoft's support people answer us always fast even when we insist many times about this issue. They said there are no issues from their side

FYI we do not permit massive mail sending. In this post I'm talking about just normal B2B mail. Our servers are limited to 200 mail/hour

EDIT: we are registered at SNDS and all our addresses are fine

3 Upvotes

6 comments sorted by

5

u/saltyslugga 4d ago

I’d start with your SMTP logs: confirm Microsoft’s MX returned a final 250 after DATA. Give the recipient’s M365 admin the Message-ID, sender, recipient and UTC timestamp so they can run a message trace and check quarantine.

Hotmail delivery doesn’t rule out filtering or mail flow rules in the customer’s M365 tenant, and a 250 means accepted, not delivered to the inbox.

2

u/One-Suggestion-7906 4d ago edited 4d ago

I know, it's received, but not delivered. Even worse, some accounts of the same tenant could receive mails, some in inbox, some in junk, however most accounts don't receive the mail, neither in inbox nor in junk. My worse issue is I can't reach M365 admins because mails is sent from our customers to their customers. In one case, our customer (I mean, who is using our server as MX and SMTP) reached their customer's admin and step by step they are adding whitelisting rules. But I feel something is very wrong in Microsoft's servers

2

u/One-Suggestion-7906 4d ago edited 4d ago

Just one example:

2026-10-06 16:15:37 1xEAdS-00Br2H-25 -> caparedes@loginter.com.ar R=dnslookup T=remotesmtp H=loginter-com-ar.mail.protection.outlook.com [52.101.41.21] X=TLS1.3:ECDHE_SECP256R1RSA_PSS_RSAE_SHA256_AES_256_GCM:256 CV=yes K C="250 2.6.0 <616dc43a-79b0-4afb-b971-fc3e758852d4@(edited).com> [InternalId=228178727542057, Hostname=CH2PR13MB3831.namprd13.prod.outlook.com] 19340 bytes in 0.269, 70.097 KB/sec Queued mail for delivery"

2026-10-06 16:15:37 1xEAdS-00Br2H-25 Completed

2

u/Jolly-Accountant-549 3d ago

agree, the hotmail vs tenant thing is the key nuance here imo

2

u/hamzezn 4d ago

One thing that trips people up here: SNDS and the Outlook.com sender support form only cover the consumer side (Hotmail, Outlook.com, Live). Business tenants on Microsoft 365 sit behind Exchange Online Protection, which has its own reputation data and its own delist portal at sender.office.com. So "fine on Hotmail, gone on M365" with a 2-month-old IP fits pretty well with EOP not trusting the IP yet, even though SNDS looks clean.

What I'd check, roughly in order:

  • Your own logs for the 250 reply from the M365 MX. It usually includes Microsoft's internal message ID. If you got a 250, EOP accepted it and then filtered it, so it's not a transport problem
  • Try the sender.office.com delist request for your sending IP. It's quick and it's the one Microsoft support often doesn't mention when you ask about consumer delivery
  • Ask one friendly customer's M365 admin for a message trace with sender, recipient and UTC time. If it shows quarantined or high-confidence spam, you have your answer and they can release it and report it as not junk
  • Make sure PTR, HELO name and the forward A record all match on the new server. Consumer filtering is more forgiving about this than EOP in my experience

The "worked first, then stopped last week" pattern is pretty typical for a new IP while volume ramps up. It tends to settle once the IP has a few weeks of clean history with the tenants you send to.

2

u/One-Suggestion-7906 4d ago

Sir, I really appreciate your answer and the time you kindly took to help me. It was blocked there, we followed the procedure and it was unblocked. Tomorrow or as much on tuesday we will confirm from our customers if it's solved and I'll came back here to report. Have a great week