During legacy migration from 2016 to new onprem exchange SE our authenticated relay stops working.

The problem you are facing with the authenticated relay stopping after moving the arbitration mailbox SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} to the new Exchange server may be linked to permission issues related to that mailbox. When this arbitration mailbox is on the new server, it might not have the necessary permissions for the authenticated relay to function correctly.

To troubleshoot and resolve this issue, consider the following steps:

1. Enable the Arbitration Mailbox: Ensure that the arbitration mailbox is enabled on the new server. You can do this by executing the following command in the Exchange Management Shell:

      Enable-Mailbox -Arbitration -Identity "SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}"
   

2. Check Permissions: Verify that the permissions for the arbitration mailbox are correctly set. The relay may not work if the mailbox lacks the appropriate permissions.
3. Recreate the Mailbox if Necessary: If the mailbox is missing or corrupted, you may need to recreate it. You can follow the steps outlined in the context to re-create the arbitration mailbox:

      .\Setup /preparead /IAcceptExchangeServerLicenseTerms
      Enable-Mailbox -Arbitration -Identity "SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}"
   

4. Verify MRS Proxy Settings: Check if the MRS Proxy is enabled on the server that hosts the arbitration mailbox. Use the following command to check:

      Get-WebServicesVirtualDirectory -Server <servername> | fl *mrsproxy*
   

   If it is not enabled, you can enable it with:

      Get-WebServicesVirtualDirectory -Server <servername> | Set-WebServicesVirtualDirectory -MRSProxyEnabled:$true
   

After completing these steps, test the authenticated relay again to see if the issue persists. This should help in resolving the problem with the relay when the arbitration mailbox is moved to the new server.

Please note that our forum is a public platform, and we will modify your question to hide your personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.

Hi Robert Eriksson

Thank you for reaching out to Microsoft Q&A forum

As far as I know, this behavior occurs because applications or devices typically authenticate with a service account that has no associated mailbox, a common legacy configuration that previously allowed sending from any address without explicit Send As permissions. In older Exchange versions, when such a mailbox-less account submits mail, the Frontend Transport service proxies the session to the server hosting this particular arbitration mailbox, where the Send As check was historically lenient.

Based on my research, as states in Allow anonymous relay on Exchange servers, the supported solution is to stop relying on the legacy "mailbox-less authenticated user" behavior and instead configure a dedicated internal application relay Receive Connector.

You can use the below cmdlet to see if it can resolve your problem:

# Create a dedicated Frontend relay connector on port 25
New-ReceiveConnector -Name "Internal Application Relay" `
  -Server YOUR_EXCHANGE_SERVER_NAME `
  -TransportRole FrontendTransport `
  -Custom `
  -Bindings 0.0.0.0:25 `
  -RemoteIPRanges 192.168.1.0/24,10.0.0.0/8   # <-- Only app/device subnets
# Require TLS; allow (but not require) Basic SMTP auth if some senders can authenticate.
Set-ReceiveConnector "Internal Application Relay" `
  -AuthMechanism "TLS,BasicAuth,BasicAuthRequireTLS" `
  -PermissionGroups "AnonymousUsers"
# Grant extended rights to allow sender/recipient override and submission
Get-ReceiveConnector "Internal Application Relay" | Add-ADPermission `
  -User "NT AUTHORITY\ANONYMOUS LOGON" `
  -ExtendedRights `
    "ms-Exch-Smtp-Accept-Any-Sender",
    "ms-Exch-Smtp-Accept-Any-Recipient",
    "ms-Exch-Smtp-Submit",
    "ms-Exch-Smtp-Accept-Authoritative-Domain"

Notes:

• Using AnonymousUsers is correct for IP-scoped relays. The extended rights are applied to ANONYMOUS LOGON, which is the right principal for port‑25, IP‑trusted submissions.
• Keeping BasicAuth available can be useful for certain apps; if none of your devices can authenticate at SMTP, you can omit BasicAuth and keep TLS only.
• Repeat on all Frontend servers behind your load balancer to maintain consistency and avoid “works on server A, fails on server B”.

Hope my answer will help you, for any further concern, kindly let me know in the comment section.

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.