Composite Authentication via on premise connectors

Edit: this doesn't seem to now work for outbound mail. But for inbound, comp auth is still passing.

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).