Microsoft 365

Status: preview. The Microsoft 365 path is being validated with a pilot tenant. Contact ScaiLabs before connecting a production tenant.

How mail flows#

This follows Microsoft's documented pattern for third-party email services:

1. A transport rule sends outgoing mail from your organisation to external recipients through an outbound connector to scailine-relay.scailabs.ai.
2. The relay signs the message in memory and immediately sends it back to your tenant.
3. An inbound connector in your tenant accepts it, authenticated by a certificate issued for your organisation only (<your-organisation>.scailine-relay.scailabs.ai).
4. Exchange Online delivers the message as usual, with your own DKIM signing, journaling, DLP and reputation.

The relay never delivers mail to the internet itself and never writes a message to disk. If the relay cannot be reached, Exchange Online keeps the message queued and retries.

Setting it up#

1. Verify your sending domains and configure templates and rules (Quickstart steps 1 to 4).
2. Under Platforms, add a Microsoft 365 connection. It starts as pending and in shadow mode. During the preview, ScaiLabs registers your Microsoft 365 tenant ID on the connection (Entra admin center → Overview → Tenant ID); the console has no field for it yet.
3. Download the generated PowerShell script from the connection's row and run it in an Exchange Online PowerShell session as an Exchange administrator. It creates the outbound connector, the inbound connector and the transport rule.
4. Add <your-organisation>.scailine-relay.scailabs.ai as a domain in your tenant; Microsoft requires the certificate name of an inbound connector to be verified.
5. Activate the connection. In shadow mode the relay records what it would have done and delivers the original; turn shadow mode off when you are satisfied.

Attribution#

Because many Microsoft 365 tenants share Microsoft's mail servers, the connecting address alone says nothing about who sent a message. The relay therefore accepts a message for your organisation only if:

• it comes over TLS from Exchange Online Protection. The address ranges come from Microsoft's published endpoint list and are refreshed daily; an update that would remove most of the list is held back for review instead of applied;
• the sender's domain is verified for your organisation;
• the X-MS-Exchange-CrossTenant-Id header equals your registered Microsoft 365 tenant ID.

Anything else is rejected with 550 5.7.1. This is the only place where ScaiLine does not fail open: nobody else's tenant may use your signatures or your inbound connector.

Loop prevention#

Signed mail comes back into your tenant as mail from your own organisation, so the transport rule would match it again. The rule therefore has an exception for messages whose X-ScaiLine header matches v=\d. Do not remove it.

Switching it off#

Disable the transport rule:

1

Disable-TransportRule -Identity "ScaiLine Signatures"

Mail then flows directly again, without signatures. Removing the connectors is not necessary.