> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xorlab.com/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> Pages under /latest/ document the current release. Paths that begin with a version number, for example /10.0/, are frozen snapshots of superseded releases kept for reference only — never present their instructions as current. If the reader's version is unknown, answer from /latest/ and say which version the answer describes.
> xorlab is deployed on-premises, hybrid, or as a cloud service, and integrates with either Microsoft 365 or on-premises mail infrastructure. Configuration steps often differ between these. State which deployment and integration mode an instruction applies to instead of presenting one as universal.
> Distinguish inline mode from monitoring mode when describing anything that acts on email. Monitoring mode observes a copy and cannot block or quarantine; inline mode routes mail through xorlab and can.
> Write the product name as lowercase 'xorlab'. Use the documented component names: xorlab Control Center (XCC), xorlab MTA, xorlab Sandbox (DANA), xorlab Natural Language Understanding (NLU). After the first mention, use the short forms XCC, MTA, Sandbox, and NLU. Do not use DANA as a standalone name for the Sandbox, but keep it where it is a literal string in configuration keys, container names, and hostnames.
> Do not invent configuration keys, rule parameters, list names, log properties, or API fields. If a value is not present in this documentation, say that it is not documented rather than guessing.
# Add a New Tenant
> Step-by-step onboarding of a new tenant, including the one-time prerequisites for the first tenant.
**Prerequisites (only for first tenant)**
* Make sure your xorlab is in the correct mode: Inline vs Monitoring, follow [Choose between Inline and Monitoring mode](/latest/before-begin-integration#choose-between-inline-and-monitoring-mode).
## Configure guarded domains and routing
The first step is to add all domains of the tenant and configure their routing (where should their emails be sent to).
1. Follow the guide below that matches the topology where your new tenant will be integrated. On top are the two most common ones.
| Topology | Description |
| :-------------------------------------------------------------------------------- | :------------------------------------------------------------------------ |
| [Default](/latest/multi-tenancy-domain-and-routing#default-chain-topology) | xorlab is located between your gateway and your internal Exchange server. |
| [M365](/latest/multi-tenancy-domain-and-routing#m365-topology) | xorlab integrates directly with M365. |
| [Front MTA](/latest/multi-tenancy-domain-and-routing#front-mta-topology) | xorlab is your gateway/front MTA. |
| [Star](/latest/multi-tenancy-domain-and-routing#star-topology) | Your gateway integrates xorlab in a Star layout. |
| [Full Chain](/latest/multi-tenancy-domain-and-routing#full-chain-topology) (Rare) | Same as Default, but inter-tenant emails pass through xorlab twice. |
2. Optional: If you need a special mode (like *toothless* or Monitoring) specifically for that tenant, contact [support@xorlab.com](mailto:support@xorlab.com).
## Activate mail flow
The next step is outside of xorlab and involves activating the mail flow. Choose the matching guide, depending on:
* **Topology**: M365 vs. all others
* **Mode**: Inline vs Monitoring
Emails pass from M365 through xorlab and then back to M365.
xorlab receives only a copy of every email from M365, and discards it after processing.
The actual activation of the mail flow depends on the system you are using. Here we provide instructions for a few common ones.
To configure on-premises Exchange for inline mode with xorlab, follow:
* [On-premises Exchange](/latest/on-prem-exchange-inline)
For monitoring mode, we have available guides for:
* [On-premises Exchange](/latest/on-prem-exchange-monitoring-mode)
* [Cisco ESA](/latest/on-prem-esa-monitoring-mode)
Now xorlab should be receiving emails for that tenant.
## Reduce reputation complexity for small tenants
For tenants below 50 seats, we recommend to reduce the `complexityFactor` in the `guarded_tenants.yml` file. This helps xorlab to learn faster from processed emails. Otherwise, learning can take quite a while to stabilize for small tenants, since fewer emails are available.
We recommend the following values:
| Number of seats | Value |
| :---------------- | :--------------------- |
| Above 50 | Keep the default (100) |
| Between 25 and 50 | 50 |
| Below 25 | 25 |
```yaml /shared/guarded_tenants.yml highlight={5-6} theme={null}
tenants:
- name: tenantA
domains:
- tenantA.com
reputation:
complexityFactor: 50
```
After updating `shared/guarded_tenants.yml`, click **Publish**. The new configuration becomes active within about one minute.
## Configure detection for the tenant
Detection is configured per tenant, so a new tenant starts without the manual inputs that xorlab needs for optimal protection.
1. Open the **Admin** view in the upper right and select the new tenant in the dropdown on top.
2. [Configure the built-in lists](/latest/detection-overview#configure-built-in-lists) for that tenant, in particular the VIP names and high value targets.
3. [Review the default actions](/latest/detection-overview#review-default-actions) for that tenant.
Both steps use the same screens as in a single-tenant deployment and apply only to the tenant selected in the dropdown.
## Optional: Enable Tenant Login
You can give the tenant access to xorlab:
* **End-user** access to the Self-Service Quarantine (SSQ)
* **Analyst** access to the analyst portal, to manage various tasks like releasing emails from quarantine or adding senders to the blacklist
Follow the instructions here: [Enable Tenant Login](/latest/multi-tenancy-authentication).
## Optional: Enable SSQ
You can enable the SSQ for the tenant, such that their end-users can release their own emails from the quarantine.
You can find the full instructions for setting up and customizing the SSQ here: [Set Up the SSQ](/latest/ssq-setup).
For convenience, we summarize here the mandatory steps to enable SSQ for a tenant:
1. Complete the previous chapter, to [Enable Tenant Login](/latest/multi-tenancy-authentication) such that they can login to the SSQ.
2. Enable notifications for that tenant in `guarded_tenants.yml`:
```yaml shared/guarded_tenants.yml highlight={4-6} theme={null}
tenants:
- name: xorlab
quarantine:
notifications:
enabled: true
frequency: DAILY
## - NEVER: Sending of a quarantine notification is disabled for the user.
## - IMMEDIATELY: Sending of a quarantine notification happens immediately if a message for the user is quarantined.
## - DAILY: Sending the quarantine notification every day at the time specified in the dailyCron option.
## - WEEKLY: Sending the quarantine notification once a week at the time specified in the weeklyCron option.
```
3. Click **Publish**. The notification settings become active within about one minute.
4. This is not strictly mandatory, but recommended: Customize the quarantine notifications for that tenant to for example add their logo: [Customize Tenant Notifications](/latest/multi-tenancy-email-templates).
## Optional: Integrate Abuse Mailbox
You can enable the Abuse Mailbox for the tenant, such that their reported emails are managed in xorlab.
1. Follow the integration guide below that matches the tenant setup. You can ignore their *Prerequisites* as they are already covered by this page.
Use the built-in M365 reporting button to send emails to xorlab.
Use a custom reporting button integrated via on-premises Exchange.
2. Follow [Assign Reported Emails to Tenants](/latest/multi-tenancy-reported-emails) to make sure xorlab assigns the reported emails to the correct tenant.