Prefacing this with, this is all in my testing across multiple Exchange Online environments. I have also raised a Microsoft support ticket for it.

Consider a mail-flow scenario where an email enters EOP, is then redirected to a 3rd party service. The email is then sent back to EOP via an on-premise connector.

This allows for both inbound and outbound email to be redirected. A partner type inbound connector does not allow external relay.

Then we have authentication. On the first hop to EOP, assume SPF/DKIM/DMARC/ARC/CompAuth passes.

On the re-delivery to EOP after the 3rd party has interacted with the email, it is likely SPF/DKIM will fail and therefore DMARC will. ARC should pass.

However, it is known that composite authentication is not calculated against emails received via an on-premise type connector.

Microsoft changed their on-premise type inbound connectors on approx 24th June 2024, to make several properties “partner connector” only. This includes RequireTLS and RestrictDomainsToCertificate.

Assuming our connector is using a unique accepted domain per tenant (which is required per MS documentation), and this value is set in the TlsSenderCertificateName parameter.

After the changes on the 24th, I set the RestrictDomainsToCertificate value to $false, so that I could continue to edit the connector in future. This is because MS made it impossible to edit a connector with that value set – they have since reverted this restriction.

However, I found that the value set for my TlsSenderCertificateName had changed slightly.

Instead of xyz.domain.com, it has a special character prepended to it. This was unicode character “LEFT-TO-RIGHT MARK” https://unicode-explorer.com/c/200E.

So it looked like (character)xyz.domain.com, note that it’s not a visible character.

Following this, all my inbound emails, being delivered after the 3rd party service, had composite authentication calculated.

With no other changes, it was compauth=none.

If I added the TLSSenderCertificateName, simply xyz.domain.com, to the Trusted ARC Sealers configuration, then it would show compauth=pass reason=130.

The special character isn’t visible in the GUI, but if you run Get-InboundConnector you can see the character taking up the space.

If I override it in PowerShell and set it to the certificate without the character, composite authentication is disabled again. But now, I can manually set the character and it enables it.

I can validate that this works for outbound relayed mail also, which would fail if the connector was configured incorrectly.

Try it out:

Set-InboundConnector -identity “yourConnector” -TlsSenderCertificateName “yourCertName”

Make sure you prepend the “yourCertName” with the “LEFT-TO-RIGHT MARK” charcater from here https://unicode-explorer.com/c/200E(you can copy it to clipboard from there).

​Prefacing this with, this is all in my testing across multiple Exchange Online environments. I have also raised a Microsoft support ticket for it. Consider a mail-flow scenario where an email enters EOP, is then redirected to a 3rd party service. The email is then sent back to EOP via an on-premise connector.This allows for both inbound and outbound email to be redirected. A partner type inbound connector does not allow external relay. Then we have authentication. On the first hop to EOP, assume SPF/DKIM/DMARC/ARC/CompAuth passes.On the re-delivery to EOP after the 3rd party has interacted with the email, it is likely SPF/DKIM will fail and therefore DMARC will. ARC should pass.However, it is known that composite authentication is not calculated against emails received via an on-premise type connector. Microsoft changed their on-premise type inbound connectors on approx 24th June 2024, to make several properties “partner connector” only. This includes RequireTLS and RestrictDomainsToCertificate. Assuming our connector is using a unique accepted domain per tenant (which is required per MS documentation), and this value is set in the TlsSenderCertificateName parameter. After the changes on the 24th, I set the RestrictDomainsToCertificate value to $false, so that I could continue to edit the connector in future. This is because MS made it impossible to edit a connector with that value set – they have since reverted this restriction. However, I found that the value set for my TlsSenderCertificateName had changed slightly. Instead of xyz.domain.com, it has a special character prepended to it. This was unicode character “LEFT-TO-RIGHT MARK” https://unicode-explorer.com/c/200E.So it looked like (character)xyz.domain.com, note that it’s not a visible character. Following this, all my inbound emails, being delivered after the 3rd party service, had composite authentication calculated.With no other changes, it was compauth=none.If I added the TLSSenderCertificateName, simply xyz.domain.com, to the Trusted ARC Sealers configuration, then it would show compauth=pass reason=130. The special character isn’t visible in the GUI, but if you run Get-InboundConnector you can see the character taking up the space.If I override it in PowerShell and set it to the certificate without the character, composite authentication is disabled again. But now, I can manually set the character and it enables it. I can validate that this works for outbound relayed mail also, which would fail if the connector was configured incorrectly. Try it out:Set-InboundConnector -identity “yourConnector” -TlsSenderCertificateName “yourCertName” Make sure you prepend the “yourCertName” with the “LEFT-TO-RIGHT MARK” charcater from here https://unicode-explorer.com/c/200E(you can copy it to clipboard from there).  Read More

​