> ## 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.
# Review What Changes in Your Environment
> See which settings an integration adds to Microsoft 365 or to your on-premises mail flow, what it leaves untouched — including your MX records — and how to undo it.
xorlab integrates through configuration only. Every step in the integration guides is a setting you make in your own admin portal, every setting is visible to you afterward, and every setting can be switched off again. No software is installed on your servers, your clients or your endpoints, and no mailbox is moved.
Use this page to answer the questions your mail, network and security teams ask before the project starts.
## Quick answers
| Question | Answer |
| :------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Do our MX records change? | With M365, **no** — they keep pointing at Microsoft. On premises, only if xorlab replaces your existing gateway. |
| Do we install software anywhere? | No. The integration consists of connectors, mail flow rules and an app registration in your own tenant, plus configuration inside xorlab. |
| Do users need an add-in or a new button? | No. Reporting uses the button your users already have — the built-in M365 one, or your existing third-party button. |
| Does Microsoft's own filtering stop working? | No. Exchange Online Protection and Defender keep running, and xorlab is layered on top of them. |
| Do our outgoing emails get new sending IPs? | With M365, no — outgoing email still leaves through Microsoft, so SPF and DKIM stay as they are. On premises, only if xorlab becomes your outbound gateway. |
| Do we need a DNS change or a cutover window? | Not for M365. The change is made by enabling two mail flow rules, it takes effect within minutes, and it is undone the same way. |
| Can we start without blocking anything? | Yes. Run in [Monitoring mode](/latest/inline-and-monitoring-mode), which never touches the mail flow, or go inline in [Toothless Mode](/latest/before-begin-integration#configure-inline-mode), where every email is still delivered. |
## Microsoft 365
### What the integration adds
| Change | Where you make it | Required? |
| :------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------- |
| Two connectors, `Microsoft365Toxorlab` and `xorlabToMicrosoft365`, both with TLS enforced | Exchange admin center → **Connectors** | Mandatory — [Enable M365 Inline Mode](/latest/m365-inline-mode). [Enable M365 Monitoring Mode](/latest/m365-monitoring-mode) needs only the first one. |
| Two mail flow rules that redirect incoming and outgoing email to xorlab, or blind-copy it in Monitoring mode | Exchange admin center → **Mail flow** → **Rules** | Mandatory — [Enable M365 Inline Mode](/latest/m365-inline-mode) or [Enable M365 Monitoring Mode](/latest/m365-monitoring-mode) |
| One enterprise application named `xorlab`, with app roles, and the users or groups who sign in to XCC assigned to it | Entra ID | Mandatory — [Create Entra ID App](/latest/m365-entra-id-app) and [Enable Entra ID SAML Login](/latest/m365-saml-entra-authentication) |
| Microsoft Graph application permissions (`Mail.ReadWrite` or `Mail.Read`, and `User.Read.All`) with admin consent, and a client secret | Entra ID → the `xorlab` app | Optional — only for [Activate Case Isolation](/latest/m365-case-isolation) and [Import Past M365 Emails](/latest/m365-retrospective-email-scanning) |
| The spam actions of the default inbound anti-spam policy set to **Add X-header** | Microsoft Defender portal | Optional — [Move M365 Quarantine to xorlab](/latest/m365-move-quarantine) |
| A reporting mailbox and one more mail flow rule, `xorlabReportingIntegration` | Microsoft Defender portal → **User reported settings**, and Exchange admin center | Optional — [Integrate M365 Abuse Mailbox](/latest/m365-reporting-integration) |
### What stays as it is
* **Your MX records.** Email keeps arriving at M365 first. A mail flow rule hands it to xorlab over the connector, and xorlab hands it back to M365 for delivery. There is nothing to change at your DNS provider, no TTL to plan around and no cutover moment.
* **Your outbound sending identity.** Outgoing email also returns to M365 for final delivery, so your public sending IPs, your SPF record and your DKIM signatures are unchanged.
* **Exchange Online Protection and Defender.** Microsoft's own filtering keeps running. The only policy xorlab touches is optional: [Move M365 Quarantine to xorlab](/latest/m365-move-quarantine) changes the spam actions so that users have a single quarantine instead of two.
* **Mailboxes, addresses and licenses.** Nothing is migrated and no mailbox is created for your users. The only new mailbox is the optional reporting mailbox.
* **Accepted domains, SPF and the connection filter.** A standard integration does not touch them. The three adjustments under [troubleshooting](/latest/m365-inline-mode#troubleshooting) are needed only if you run into deliverability issues.
* **Your clients.** No add-in is rolled out. Users report suspicious email with the button M365 already provides.
**Hybrid setups**
Follow the M365 path whenever you receive and send email through M365, even if mailboxes also exist on premises. If email enters and leaves through your own infrastructure, follow [On-premises](#on-premises) instead.
### How to undo it
Disable the two mail flow rules in the Exchange admin center. Email returns to its previous path within minutes, without a DNS change. The connectors and the Entra ID app can then be removed at your own pace.
## On-premises
How much changes depends on where xorlab sits in your mail flow. You choose that in [Set Up Email Routing in xorlab](/latest/on-prem-smtp).
| Target setup | Mail path | MX records |
| :-------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Inline add-on** (default) | Your gateway forwards incoming email to xorlab instead of directly to Exchange, and xorlab delivers it to Exchange. Outgoing email goes Exchange → xorlab → gateway. | Unchanged. Your existing gateway keeps the MX. |
| **Inline gateway** | xorlab receives email from the internet and delivers it to Exchange. It also delivers outgoing email to the external recipient. | Changed. They point at the xorlab MTAs. Also open inbound SMTP to the MTAs, add them to your SPF record, and set up [DKIM signing](/latest/dkim-and-dmarc-setup) on xorlab. |
| **Monitoring** | Unchanged. xorlab receives a copy of every email and discards it after the analysis. | Unchanged. |
### What the integration adds
| Change | Where you make it | Required? |
| :------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| The scope of the default receive connector extended with the IP addresses of the xorlab MTAs | Exchange admin center → **Mail Flow** → **receive connectors** | Inline — [Enable Exchange Inline](/latest/on-prem-exchange-inline) |
| A send connector that routes outgoing email through the xorlab MTAs as smart hosts | Exchange admin center → **Mail Flow** → **send connectors** | Inline — [Enable Exchange Inline](/latest/on-prem-exchange-inline) |
| Two mail flow rules that blind-copy email to xorlab, or a message filter, bounce profile and destination control on a Cisco ESA | Exchange admin center, or the ESA | Monitoring — [Enable Exchange Monitoring with BCC](/latest/on-prem-exchange-monitoring-mode) or [Enable ESA Monitoring with BCC](/latest/on-prem-esa-monitoring-mode) |
| Firewall rules for SMTP between your email servers and the xorlab MTAs, and for the outbound connections of the platform | Your firewall | Mandatory — [Network Guide](/latest/network-guide) |
| Your own email servers registered as trusted infrastructure. This is a setting inside xorlab, not in your environment | Expert Editor | Mandatory — [Add Your Trusted Infrastructure](/latest/on-prem-add-trusted-mtas) |
| A SAML application or an LDAP service account for signing in to XCC | Your identity provider | Optional — [Enable SAML or LDAP Login](/latest/on-prem-saml-ldap-authentication) |
| Forwarding of reported email to `suspicious@` on xorlab | Exchange, or your reporting button | Optional — [Integrate On-prem Abuse Mailbox](/latest/on-prem-reporting-integration) |
### What stays as it is
* **Your existing gateway or filter**, unless you deliberately replace it. In the default inline add-on setup, xorlab is added next to what you already run.
* **Mailboxes, addresses and clients.** Nothing is migrated and nothing is installed on Exchange or on the endpoints.
* **The mail flow itself, in Monitoring mode.** xorlab only receives a copy and never modifies, delays or blocks an email.
**Monitoring mode and availability**
The copies are ordinary emails, so if all xorlab MTAs are unreachable, they can queue up on the system that sends them. If that happens, disable the BCC rules temporarily.
### How to undo it
In Monitoring mode, disable the BCC mail flow rules or the ESA message filter. In Inline mode, set the next hop of the system in front of xorlab back to its previous destination and disable the send connector that points at xorlab.
## What your users notice
* **In Monitoring mode, nothing.** No email is modified, delayed or blocked.
* **In Inline mode, with the delivered defaults:**
* Emails with a malicious verdict are quarantined instead of delivered. Which verdict and confidence leads to which action is visible, and adjustable, in [Review Default Actions](/latest/detection-actions).
* Some verdicts are delivered with a subject prefix such as `[SPAM]`, configured on the same screen.
* Nothing else is added to the message. [Enable Contextual Banners](/latest/detection-contextual-banners) and [Add Result Header to Email](/latest/detection-analysis-result-header) are separate, optional steps and are off by default.
* **Only if you enable it:** the [Self-Service Quarantine (SSQ)](/latest/ssq-overview) lets users see and release their own quarantined emails, and quarantine notifications are sent to them.
During the first weeks you can go inline in [Toothless Mode](/latest/before-begin-integration#configure-inline-mode). xorlab then delivers every email, including the ones it would have quarantined, and you review those in XCC by searching for `#quarantine` before switching protection on.
## Next steps
Configure your guarded domains, set the data retention, and choose between Inline and Monitoring mode.