How to handling authenticated vs anonymous relay without creating an open relay?

Hi Rosie Brunson

I have conducted some research and found that Authenticated SMTP submission (typically port 587) enforces “send as” authorization based on the authenticated identity. In practice, it will only allow the client to submit mail using the authenticated mailbox address (or other mail-enabled identities in AD/Exchange where the account has explicit Send As rights).

This is why it works when the “From” matches the mailbox but fails for arbitrary sender addresses that don’t exist as mail-enabled objects.

To support an ERP/application sending with custom “From” addresses that are not tied to AD mailboxes, use a dedicated anonymous relay Receive connector (Frontend Transport, TCP 25) scoped only to the ERP/app servers’ static IPs. This design is the recommended approach because it enables relay while preventing an open relay by restricting who can use the connector.

1. Create a dedicated Receive connector (Frontend Transport / Custom) bound to port 25 and restrict RemoteIPRanges to only the ERP/app server IPs (remove the default 0.0.0.0-255.255.255.255).
2. Configure permissions using one of the supported methods (choose one):
   • Anonymous method: set PermissionGroups to AnonymousUsers and grant Ms-Exch-SMTP-Accept-Any-Recipient to NT AUTHORITY\ANONYMOUS LOGON.
   • Externally secured method: set AuthMechanism to ExternalAuthoritative and PermissionGroups to ExchangeServers (use only if those hosts are fully trusted, since it grants broader trust

You can read here for more information:

https://learn.microsoft.com/en-gb/answers/questions/906258/exchange-on-prem-setup-receive-connector-with-basi

https://learn.microsoft.com/en-us/exchange/receive-connector-permissions-exchange-2013-help

https://learn.microsoft.com/en-us/exchange/mail-flow/connectors/allow-anonymous-relay

Hope my answer will help you.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".   

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Authenticated SMTP submission and anonymous relay solve different problems and must be configured separately to avoid creating an open relay.

Key points from the scenario:

• Authenticated SMTP (client submission) only allows sending as the authenticated mailbox (or as identities explicitly allowed by mailbox permissions like Send As/Send on Behalf).
• Granting ms-Exch-SMTP-Accept-Any-Sender on a Receive connector does not change this behavior for client submission; it applies to messages coming in via that connector, not to mailbox-authenticated SMTP clients.
• To allow arbitrary “From” addresses (for ERP/devices) without creating an open relay, use a dedicated anonymous relay Receive connector restricted by IP, not by authentication.

Recommended approach

1. Keep authenticated SMTP for normal users
   • Use client SMTP submission for users or apps that send as their own mailbox or as identities they are explicitly allowed to use.
   • This is described as “Client SMTP submission” and is intended for authenticated mailboxes, not arbitrary senders.
2. Create a dedicated anonymous relay connector for ERP/devices
   • In Exchange Server, create a dedicated Receive connector in the Front End Transport service on a Mailbox server, listening on TCP 25, and restrict it to the ERP server and any other trusted devices by IP.
   • Do not modify the default Receive connectors.
   • This connector is what will honor the “any sender” behavior for those IPs while still not becoming an open relay.
   Key design rules from the guidance:
   • Use a dedicated Receive connector for anonymous relay.
   • Scope it to a specific list of internal IPs so that only those systems can use it.
   • This prevents the server from becoming an open relay.
3. Choose one of the two supported permission models on that dedicated connector There are two supported ways to allow anonymous relay on the dedicated connector; choose one, not both: Option A – Anonymous connections (minimal permissions, safer)
   • Set the connector’s permission group to AnonymousUsers and explicitly grant the “any recipient” right to anonymous:

          Set-ReceiveConnector "Anonymous Relay" -PermissionGroups AnonymousUsers
          
          Get-ReceiveConnector "Anonymous Relay" | Add-ADPermission \
            -User "NT AUTHORITY\ANONYMOUS LOGON" \
            -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"
     

   • With this method, connections use NT AUTHORITY\ANONYMOUS LOGON and get the minimum required rights:
     • ms-Exch-Accept-Headers-Routing
     • ms-Exch-SMTP-Accept-Any-Recipient
     • ms-Exch-SMTP-Accept-Any-Sender
     • ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
     • ms-Exch-SMTP-Submit
   • Messages are still treated as anonymous: they do not bypass antispam or size limits, and sender addresses are not resolved to GAL display names.
   • This is the recommended model when the ERP/devices just need to send mail with arbitrary From addresses.
   Option B – Externally secured (treat IPs as trusted Exchange servers)
   • Configure the connector as externally secured and add the ExchangeServers permission group:

          Set-ReceiveConnector "Anonymous Relay" \
            -AuthMechanism ExternalAuthoritative \
            -PermissionGroups ExchangeServers
     

   • Or via EAC: set Authentication to Externally secured and Permission groups to Exchange servers.
   • Connections are treated as MS Exchange\Externally Secured Servers and get a broad set of rights, including:
     • ms-Exch-SMTP-Accept-Any-Recipient
     • ms-Exch-SMTP-Accept-Any-Sender
     • ms-Exch-Bypass-Anti-Spam
     • ms-Exch-Bypass-Message-Size-Limit, and others.
   • This effectively treats those IPs as fully trusted internal senders; use only if those systems are completely trusted and tightly IP-restricted.
4. Why authenticated SMTP still fails with arbitrary From addresses
   • Client SMTP submission is designed so that the authenticated mailbox is the sender. It does not rely on Receive connector extended rights like ms-Exch-SMTP-Accept-Any-Sender.
   • To send as arbitrary addresses via authenticated SMTP, the service account would need appropriate mailbox-level permissions (Send As/Send on Behalf) for each sender identity, which doesn’t exist for non-AD/custom addresses.
   • Therefore, for ERP/custom From scenarios, the supported pattern is:
     • ERP/device connects anonymously from a trusted IP to the dedicated anonymous relay connector.
     • That connector is configured as above to allow any sender/recipient while being IP-restricted to avoid open relay.
5. Ensuring it is not an open relay
   • Restrict the connector’s Remote network settings to only the ERP server and other trusted internal IPs.
   • Do not allow 0.0.0.0/0 or broad internal ranges unless truly necessary.
   • Do not add anonymous relay permissions to default connectors.

This design gives:

• Normal users/apps: authenticated SMTP, sending as their own or permitted identities.
• ERP/devices: anonymous relay via a dedicated, IP-restricted connector that allows arbitrary From addresses without exposing the server as an open relay.

References:

• Allow anonymous relay on Exchange servers
• How to set up a multifunction device or application to send email using Microsoft 365 or Office 365