When migrating or operating multiple Exchange Servers in an organization, problems can occur when sending and receiving emails between the Exchange Servers. One reader had a case where users from one Exchange server could no longer email users on the other Exchange server. The emails were stuck in the queue with the following error:
EventId : SUBMITDEFER
Source : STOREDRIVER
EventData : {, [DiagnosticInfo, Error: RetrySmtp, Diagnostic Information:
Stage:UpdateMsgIdToPoisonContextMapping, SmtpResponse:451 4.4.395 Target host responded with error. -> 451
5.7.3 Cannot achieve Exchange Server authentication, details:FailedRecipientCount:0;
RetryRecipientCount:0], [DeliveryPriority, Normal]}
In this case, the important part of the error message is the following:
451 4.4.395 Target host responded with error. -> 451 5.7.3 Cannot achieve Exchange Server authentication
Specifically, this means that the target Exchange server rejects the mails with authentication errors. The cause of this error is usually incorrect authorizations or incorrect scope definitions on the receiving connectors.
The mails from Exchange Server to Exchange Server are received via the receive connector "Default Frontend SERVERNAME". The security mechanisms "Exchange Server Authentication" and the authorization groups "Exchange Server" and "Legacy Exchange Server" should be activated on this receive connector. Here is a screenshot of the standard authorizations:
All standard authorizations of the receive connectors are listed on the following page:
If the authorizations on the receive connector are OK, then other receive connectors with an incorrect scope definition are often to blame. For example, if there are other receive connectors, e.g. for the relay, then the IP addresses of the Exchange servers must not be specified as a range on this connector.
In this screenshot, two IPs are specified as a range:
If one of these IPs is an Exchange server, this connector is used. In this case, the above-mentioned authentication error occurs due to the incorrect security settings:
The solution here is to remove the IPs of the Exchange server from the range so that the "Default Frontend" connector is used again.
