In Office365, we have a distribution group, [email protected]
, set up with the following members:
- [email protected]
- [email protected]
- [email protected] (@gmail.com, for example)
If an internal user (i.e. an @company.com email address) sends an email to [email protected]
, all members of the group receive the email.
However, if an external user sends an email to [email protected]
, only the internal users receive an email. The external users don't even receive an NDR, even though I have ReportToOriginatorEnabled set to True on the group.
This question shows how to fix issue of emails not being delivered in Exchange 2010: Distribution list with external email sent from outside, however, the solution in the linked question was already in place. There was nothing for me to change, so I'm still experiencing the same issue.
Message Trace in Office365 reports that the email to the external member of the group was successfully delivered to the external SMTP server, but I have tested using Gmail and several other services, and none of them receive the email, or an NDR.
This can be related to security settings on external recipient side. For example gmail contact sends mail to your DL, that has another gmail contacts inside. On Exchange side, DL is opened, and Exchange forwards mail to internal and internal recipients. Internal, all works fine, but when it is forwarded to external one, it creates a situation when GMAIL sender sends mail to GMAIL recipient, but mail arrives not from GMAIL server IP, and security system on GMAIL side drops it (SPF, etc.)
This is an interesting scenario. I have a few of these groups setup, and no special configuration was required. They seem to be routed and delivered according to MX records.
Are the recipients added as mail contacts inside Exchange?
It may also be something with the send connector. I know for local Exchange 2013/2016, you have to grant extended permissions to allow connector relay messages externally - it may be something like occurring.
I would open a support case with MS. In some cases there can be org configs or other settings that were not provisioned correctly when the tenant was created, this can cause issue that are sometimes hard to find, and not all settings can be changed by admins.