Outlook.com/Microsoft 365 senders cannot deliver mail to my domain - no NDR, no connection attempt logged

Question

Outlook.com/Microsoft 365 senders cannot deliver mail to my domain - no NDR, no connection attempt logged

Vipa 0

Hi everyone,

I administer the mail server for the domain shapedbox.de (self-hosted Postfix/Dovecot on Plesk, Ubuntu 24.04). Mail from Outlook.com/Microsoft 365 senders is not being delivered to any address on this domain.

What I've confirmed so far:

MX record correctly points to srv02.shapedbox.de (82.165.253.157 / IPv6 2001:8d8:1801:42::1)
TLS certificate valid (Let's Encrypt), TLSv1.2/1.3 supported, no handshake errors
My mail server logs show zero SMTP connection attempts (no MAIL FROM/RCPT TO, not even a reject) for any Microsoft-originated mail addressed to shapedbox.de — Microsoft's servers simply never try
Control test: mail from the same Outlook.com sender to a different domain (the-grid.ch) hosted on the identical server/IP at the same time was delivered successfully — this rules out a server, IP, or TLS/SNI issue
Multiple recipient addresses within shapedbox.de are affected, not just one mailbox
Even Microsoft's own automated account-verification emails fail to reach shapedbox.de addresses
Submitted my sending IP (82.165.253.157) to the Outlook.com IP delist tool — confirmed not on any IP block list
Contacted Outlook.com Deliverability Support twice (SR# 01M0XHZNSMAP000A2ZBHP3HBT8) — was redirected to general account support, then to Partner/Premier Support, neither of which seems appropriate for this issue

My working theory: shapedbox.de may be on an internal Microsoft recipient suppression list, possibly a leftover from a mail server migration I completed earlier this year (old server decommissioned, new server/IP took over the domain).

Has anyone dealt with a similar "silent" domain-level block from Microsoft as the sending party (not the receiving party)? Any pointers on the right escalation path would be much appreciated.

Thanks, Marc

0 comments

2 answers

Your answer

Answer 1

Update: I've identified and resolved the root cause. It was not related to IPv6 connectivity (which was already functioning correctly, including PTR and firewall configuration), but to a DANE/TLSA mismatch.

Our MX record (shapedbox.de → srv02.shapedbox.de) pointed to our server's generic hostname, which is shared across multiple hosted domains. The TLS certificate actually served under that generic hostname's default configuration no longer matched the TLSA record published in DNS for it — most likely due to a certificate change that wasn't reflected in the corresponding TLSA record. As a result, your servers connected successfully and completed EHLO/STARTTLS, but DANE validation failed immediately afterward, so MAIL FROM was never sent — consistent with the commands=3 sessions and the tlsa-invalid NDR we received.

Worth noting for anyone else hitting this: the DANE failure was completely silent on the sending side. Testing manually from an outlook.com mailbox (via the actual mail client, not just a bounce/NDR check), I never received any error or delivery failure notification at all — the message simply appeared to send successfully with no feedback that it hadn't reached the recipient. The only reason I found the actual rejection reason was a separate NDR that happened to surface from a different Microsoft 365 tenant/mailbox sending to the same domain. Outlook.com itself gave no indication anything was wrong.

Fix implemented:

Changed the MX record for shapedbox.de to a domain-specific hostname (mail.shapedbox.de) with its own certificate binding via SNI
Published correct, matching TLSA records for that hostname
Verified externally via dane.sys4.de and internet.nl — both now report valid DANE

Confirmation: A test message sent from an Outlook.com account was successfully delivered to ******@shapedbox.de following the fix.

Thank you again for pointing me toward IPv6/DANE-related checks — while the specific cause turned out to be DANE rather than IPv6 itself, that direction led directly to the actual problem. Marking this as resolved on my end.

Answer 2

Pavle Peković 6,650 Volunteer Moderator

It looks like, your domain is not connected to any Microsoft tenant.

One other thing, Microsoft prefers IPv6 when an AAAA exists You do have AAAA. A firewall rule, missing IPv6 PTR, or inet_protocols=ipv4 in Postfix produces exactly zero log entries because the connection never reaches Postfix.

Test from outside the network to connect to port 25 using IPV6.

If IPv6 on port 25 does not answer, or has no PTR, maybe the solution is to remove the AAAA from the MX target until it is fixed. I'm guessing here, so, be careful with DNS and Postfix changes pls.

0 comments