Надежная платформа электронной почты, календаря и совместной работы, разработанная Microsoft, предназначенная для корпоративного общения и управления данными.Другие темы, которые не попадают под определенные категории.
Please note that this is the ru-ru forum. I kindly recommend posting your question in Russian so that more community members can assist you. Alternatively, you may consider posting in the English forum if you prefer to use your native language. I sincerely appreciate your understanding.
Please note that Exchange 2019 reached End of Support on October 14, 2025. After this date, Microsoft no longer provides security updates, bug fixes, technical support, or time zone updates for this product.
Based on the information you provided, I understand that your static distribution group is configured with Only senders inside my organisation, but most messages originating from external senders are still accepted. Only a small number are rejected with 550 5.7.133 RESOLVER.RST.SenderNotAuthenticatedForGroup
The important distinction is that Exchange does not enforce this restriction solely by looking at the visible From address or the sender’s domain. The setting corresponds to RequireSenderAuthenticationEnabled = True
Based on the information I found, RequireSenderAuthenticationEnabled does not determine whether a sender is internal or external by comparing the sender’s email address with your organisation’s directory. Instead, Exchange determines the sender’s internal or external status based on the actual mail flow path. More specifically, it considers whether the SMTP session that delivered the message was authenticated, or whether the message travelled through a connector or route that Exchange trusts as internal. This applies regardless of the original sender’s actual email address.
As a result, messages that are relayed through an intermediate system before reaching the distribution group may be treated by Exchange as authenticated, even if the original sender is external. From Exchange’s perspective, the final connection that delivered the message came through a trusted path. The message is therefore treated as authenticated because of the delivery connection, not because the sender’s address is considered internal.
The six messages that failed with 550 5.7.133 RESOLVER.RST.SenderNotAuthenticatedForGroup indicate that the distribution group restriction is still working for messages that Exchange actually classifies as unauthenticated. The difference is therefore more likely to be in the inbound mail route or the authentication context assigned to each message, rather than in the distribution group itself.
I suggest comparing the headers and message tracking data from one accepted external message with those from one rejected external message. In particular, check the following authentication-related headers:
X-MS-Exchange-Organization-AuthAs
X-MS-Exchange-Organization-AuthSource
X-MS-Exchange-Organization-AuthMechanism
The value of X-MS-Exchange-Organization-AuthAs can help determine whether Exchange recognised the message as internal or anonymous.
Once you have identified the Receive Connector that processed the accepted messages, check its permission groups and authentication mechanism by using Exchange Management Shell:
Get-ReceiveConnector "<ConnectorName>" |
Format-List PermissionGroups,AuthMechanism
You can also review the connector’s Security settings through ADSI Edit.
If Anonymous Users is combined with extended permissions such as Accept Any Sender and Accept Authoritative Domain Sender, or if Externally Secured is enabled for a mail path that should not be trusted in this way, that connector configuration may be causing externally originated messages to be treated as authenticated.
I hope this information helps.