This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(160, 84%, 25%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECM%3C/text%3E%3C/svg%3E)
I wonder if someone is able to confirm this for me please?
We had a recent issue where emails from our M365 to our on-prem Exchange were being delayed, and we found that one of our 2 Exchange servers had domain secure enabled. This caused mail to not go to one of the servers and had to timeout and be directed to the server without domain secure enabled. Disabling this setting allowed our emails to flow without delay to on-prem again. The issue is this should be enabled.
While looking we have a load balancer in front of the Exchange doing SSL offload for port 25 for incoming mail. From what I read domain secure needs to have a direct route from M365 to on-prem without anything in between that can packet share or modify certificates. Is this still the case and could the SSL offload cause the issue when domain secure is enabled?
Many thanks
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(70.4, 18%, 16%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ENM%3C/text%3E%3C/svg%3E)
Hi @Chris M,
Based on your description, I understand you had a concern about if enable SSL offload load balancer and domain secure connector meantime make a difference to the delay of email.
Offloading should only be enabled when you're running a hardware load balancer, and you're happy with how you've got your network secured, and your Exchange Servers would benefit from the reduced overhead of not having to perform SSL decryption.
However, the Offloading should be disabled when you need connect directly to an Exchange Server over HTTPS and it is not supported with a TLS protected connection.
You could kindly disable the SSL offload and then enable the domain secure connector to see if it works.
Hope the information helps and if you have any questions, please feel free to contact me.
Just checking in to see if above information was helpful.
If the issue has been resolved, please mark the helpful replies as answers.
Hi @Noah Ma-MSFT ,
Sorry about the delay in my response. Thank you for your reply we are just looking into going down this route, when we started experiencing a mail delay again. No settings were changed on our end but every so often a few emails from our M365 to on-prem are getting "LED=450 4.4.317 Cannot connect to remote server Message=UntrustedRoot". A majority of our emails are received with no problems.
The Expected Subject and Presented Subject are the same and the thumbprint matches our certificate that is signed by GoDaddy. It is installed on the LB and has a concatenated certificate that contains our certificate and the GoDaddy intermediate.
So at the moment we double checking our on-prem, looking at the 2 Exchange servers and the SSL offload on the LB. Which had been working since putting our temporary fix in place of disabling domainsecure on the Exchange receive connectors.
Hi,
As you mentioned, I know emails from your M365 to on-prem are getting LED=450 4.4.317 error.
This error code could be the following scenarios
The reason why the error occurred could be that Exchange Online doesn't fetch intermediate certificates on–demand.
Therefore, a remote MTA that provides a certificate should include the full certificate chain.
For more information, please refer to NDR error code 450 4.4.317 (Cannot connect to remote server [Message=UntrustedRoot]) - Exchange | Microsoft Learn.
Also, please double check if there are any device between the on-prem and M365 that may be interfering with the mail flow.
If there are anything else you need help with, please let me know.
Just checking in to see if above information was helpful.
If the issue has been resolved, please mark the helpful replies as answers.
Thank you that did help, we had the issued certificate and the intermediate concatenated into a single certificate. However we found that the Kemp was not showing the leaf certificate and it needed to be uploaded to it into the intermediate store.
Once we had done that we no longer saw an issue, we have also bee able to enable the DomainSecure setting on our receive connectors.
Hi @Chris M,
I am so glad to know that the issue disappeared and didn't happen again.
If my answer is any helpful to you, please click on ACCEPT ANSWER as it could help other members of the Microsoft Q&A community who have similar questions to reference. Thanks for your understanding.
If there are anything else about the issue you need help with, please feel free to contact me.
If the answer is any of help to you, please click on ACCEPT ANSWER as it could help other members of the Microsoft Q&A community who have similar questions to reference. It will also help the community grow to help you better in the future!
Thanks for your understanding.