---
summary: How Exchange Online routes mail through the hosted ScaiLine relay, how attribution
  protects you, and how to switch it off. In preview.
order: 2
title: Microsoft 365
path: operating/microsoft-365
status: published
---

# 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:

```powershell
Disable-TransportRule -Identity "ScaiLine Signatures"
```

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