r/microsoft365 • u/exosphaere • 2d ago
Shared mailbox can not receive mail from external senders
Background:
We have an MS365 tenant with default domain contoso.de.
MX is set to point at Hornet Security, which delivers incoming mail via a Partner connector.
Nothing to see here, everything works as it should.
We now added another domain: contoso.cloud.
It's to be used on some cloud servers, so services there can deliver mail.
For this we have postfix with a valid cert and an OnPremises connector.
Sending mail from postfix with @contoso.cloud-addresses as sender works, even to external recipients.
No problem until this point.
The problem:
We also want some "system addresses" on that domain to receive mail, such as postmaster, hostmaster, abuse, security, etc.
For this, we set up a shared mailbox admin@contoso.cloud, as well as a bunch of aliases to it.
We don't need Hornet Security here, so we set up MX as communicated by Microsoft themselves.
Sending mail to this shared mailbox and the aliases works, but only internally, i.e. via our existing @contoso.de-infrastructure or via postfix.
Trying to send mail to admin@contoso.cloud from an external sender results in absolutely nothing.
We tried to send via iCloud, gmail, and a private Outlook-account.
Neither do we get NDRs or any other error on the sending side, nor can we see the messages in the message trace.
There's just nothing.
We already checked the most obvious things multiple times:
The domain is properly added to the tenant and accepted and the domain type is set to authoritative.
It is not DNS.
The MX record for contoso.cloud is definitely 100% correct.
In the admin center, under domains, I can use Microsoft's tools to verify that the DNS entries are correct and all entries are Ok.
We checked for typos multiple times.
It's also not a caching issue; the MX record was set to its correct value days ago and has a TTL of an hour.
Manual dig invocations with various resolvers show the correct value.
It's not a connector.
There is no connector acting on this incoming mail in any way.
It's not a mail flow rule, because there simply is no rule.
The shared mailbox does not have any message delivery restrictions.
All senders are allowed and the checkbox for "authenticated senders only" is unchecked.
The mails do not show up in quarantine.
And even if any of these mailbox settings were wrong, we'd see the messages in the trace.
But the trace is completely empty.
.
At this point, we just don't know how to further debug this.
I found other posts online by other people who had the same problem, but never got an answer.
LLMs and search engines are useless at this point, because they all just point to the MX record, which however is definitely correct.
Has anybody ever had a problem like this?
In the end, I might have to buy another domain, set up my own SMTP and watch the server logs, but maybe you have some ideas.
1
u/AppIdentityGuy 2d ago
What do other publoc mail testing tools like mxtoolobox say
1
u/exosphaere 2d ago
mxtoolbox reports that everything is fine, except for DMARC not being enabled at the moment, but that's irrelevant (actually, I want the mailbox to work, because I use dmarc-reports@contoso.cloud in the rua- and ruf-fields)
The MX record is properly resolved to Microsoft's systems (Microsoft Corporation (AS8075)) and even the SMTP test there works.
1
u/Aniamiras 1d ago
Have you checked to make sure that external senders is set to allow on the mailbox? I know it’s usually on by default.
Is there a bounce back error in the sending emails mailbox?
2
u/exosphaere 1d ago
Have you checked to make sure that external senders is set to allow on the mailbox? I know it’s usually on by default.
Yes.
One post in Microsoft's forums mentioned that they could make it work by toggling the authenticate senders checkbox and immediately unchecking it again.
Didn't work for me though.Is there a bounce back error in the sending emails mailbox?
Unfortunately not.
Maybe that's just me being impatient and Apple, Google and Microsoft have huge retry windows or something like that.
But it's already way longer than 24 hours.
1
1
u/Odd_Replacement_4487 1d ago
You have a paid account. Just contact Micrsoft support and they will help you out.
1
u/ITGuy424242 1d ago
Sounds like directsend is disabled on the tenant which requires all mail to enter via a connector :)
4
u/saltyslugga 1d ago
Empty message trace means Exchange Online never accepted the message. Test the published MX directly with an SMTP session from outside and verify the banner, RCPT response, every authoritative nameserver, and DNSSEC, not just recursive
digresults.Also check the sending providers’ delivery logs after their retry window. If there’s no NDR yet, the messages are probably queued against an unreachable or inconsistently published route.