In Office365, we have a distribution group, group@company.com, set up with the following members:

  • internaluser1@company.com
  • internaluser2@company.com
  • externaluser@external.com (@gmail.com, for example)

If an internal user (i.e. an @company.com email address) sends an email to group@company.com, all members of the group receive the email.

However, if an external user sends an email to group@company.com, 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.

2 Answers 2


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.

  • It's most likely the send connector extra privs. Adding that cmdlet info to the answer would save someone else from adding a redundant answer and likely get you an update.
    – SamErde
    Jul 21, 2018 at 11:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.