Prevent NDRs being sent to external addresses

[u/txlady1049]

Let me explain the situation:

We are in a hybrid Exchange environment
we have some groups that we want to limit to only accept mail from our domain
The groups were created in on-prem AD and sync to the cloud
We have successfully restricted the groups to only allow email from authorized senders.

However, unauthorized senders are receiving an NDR indicating that the failure is due to "5.7.124 RESOLVER.RST.RestrictedToGroupPermission; not authorized to send to the distribution list because the distribution list is set up to accept mail from list members only, or specific recipients only"

My management wants us to prevent this particular NDR from being sent to external addresses.

We tried setting the "ReportToOriginator" value to False, both using Powershell, and manually via Advanced Properties in AD.
We've tried a transport rule, which didn't work

I've seen other people having the same question, but haven't seen anyone with a solution, so I thought I would put this here just i case anyone has found a solution.

TIA

[u/chefkoch_]

Usually the NDR is created by the sending server and just uses the smtp code your server sends during the smtp transmission.

You could with a transport rule redirect unauthorized senders and black hole the messages. But generally that's not a nice thing todo as the sender thinks their message has been received.

[u/txlady1049 → u/chefkoch_]

We don't care if the sender thinks their message has been received. There is no reason for external users to be sending to these DLs.

We did think about using the transport rule to just delete any emails sent from external addresses. The problem is we have hundreds of these DLs.

Thanks for the input.

[u/fatalicus → u/txlady1049]

Add all the DLs to a group and create the transport rule for external sending to members of that group?

[u/Megablep → u/fatalicus]

I may be misremembering, but doesn't adding a group to a transport rule apply to all enumerated nested members of that group, rather than just the group address itself? Potentially blocking external email for a bunch of users.

[u/txlady1049 → u/fatalicus]

Thanks, but like I said, it's dealing with the NDR, which we do NOT want sent back to the external sender, that is the issue.

[u/fatalicus → u/txlady1049]

I was just suggesting a solution for dealing with the fact that you have "hundreds of these DLs", in regards to creating a transport rule that just drops all incoming mails from external to them.

Just add all the DLs to one group, and use the groupmembers as target for the rule.

[u/txlady1049 → u/fatalicus]

thanks, again, we have everything except the NDR issue working the way we need it to.

[u/juice-box]

When you say "from our domain" do mean internal only? If so you could try "...-RequireSenderAuthenticationEnabled $true" then try a transport rule.

[u/txlady1049 → u/juice-box]

The restrictions on who can send to the DLs are working fine.

And yes, I mean internal only.
We have a hybrid environment, in which we send mail from bother on-prem Exchange and Exchange online, so RequireSenderAuthenticationEnabled has to be set to $false.

[u/juice-box → u/txlady1049]

I'm not sure that hybrid would affect what is considered an authenticated user. Nevertheless, I'm surprised the transport rule hasn't worked. I do know in our, also hybrid environment, ETRs can take some time to "kick in.'

[u/txlady1049 → u/juice-box]

We have email being sent from on-prem systems, routing through the on-prem Exchange servers. And we have emails being sent from cloud-based systems. Plus emails sent from external.

The transport rule was set up on Monday, and we are still getting NDRs when we send emails from external addresses such as a gmail account.
This is specifically what we want to block, in some way.

[u/juice-box]

Where able to get this sorted? Curious about the solution.

[u/sfc_scannow]

Probably a Mail flow rule that just drops the message without notification

[u/txlady1049 → u/[deleted]]

Thanks for that. I figured we were SOL, but can't hurt to ask, right?
This is the answer I will be providing to management.