> ## 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. # What Integrating xorlab Involves > For the mail, infrastructure and security admins who have to operate it: the deployment choice, the settings an integration adds, and what stays on your plate afterward. Putting a security product into a mail flow is normally a project. The integration of xorlab is a set of configuration changes in your own admin portal — visible to you afterward, and reversible in minutes. Hosted by xorlab, or on your own virtual infrastructure. Same detection either way. Three steps. Inline or monitoring is the one decision that shapes the rest. Connectors and mail flow rules. No MX change, nothing installed, no mailbox moved. Upgrades, certificates, backups and monitoring, split by SaaS and on-premises. ## Where it runs **Two deployment options, with the same detection either way.** * **xorlab SaaS** — hosted and operated by xorlab. There is nothing to provision, and the platform itself is kept up to date for you. * **On-premises** — you run the xorlab Control Center (XCC) and one or more xorlab MTAs on your own virtual infrastructure, so processing and storage stay with you. Install and configure the VMs first, following the [VM Setup Guide](/latest/vm-setup-guide); the [Sizing Guide](/latest/sizing-guide) says what to provision and the [Network Guide](/latest/network-guide) says which connections to open. Only start the integration once the VMs are running. Hybrid setups are supported in both directions. Which integration path you follow depends on where email enters and leaves your organization, not on where the mailboxes live. If you protect several organizations from a single instance, onboard each of them as a tenant rather than repeating the integration: see [Multi-Tenancy Overview](/latest/multi-tenancy-overview). ## What the integration involves **Three steps, in this order.** | Step | What happens | | :------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------- | | [Before You Begin](/latest/before-begin-integration) | Declare the domains xorlab protects, set the data retention, and choose between inline and monitoring mode. | | [M365 Overview](/latest/m365-integration-overview) or [On-prem Overview](/latest/on-prem-integration-overview) | Connect the mail flow, user login and reporting, plus the optional Microsoft 365 features. | | [What to Configure Next](/latest/integration-next-steps) | Quarantine, notifications, detection and logging. | **Inline or monitoring is the decision that shapes the rest.** In monitoring mode xorlab receives a copy of every email and drops it after the analysis, so your mail flow is untouched and nothing can be blocked. In inline mode email passes through xorlab and is forwarded on, which is what active protection requires. You can go inline in [Toothless Mode](/latest/before-begin-integration#configure-inline-mode) first, where every email is still delivered and you review what would have been quarantined. See [Switch Between Inline and Monitoring Mode](/latest/inline-and-monitoring-mode). Most admin changes are made in the [Expert Editor](/latest/expert-editor), the configuration editor built into XCC. It is worth getting familiar with it early. ## What changes in your environment The integration is made of settings in your own admin portal: * **Microsoft 365** — two connectors with TLS enforced, two mail flow rules, and one enterprise application in Entra ID. Microsoft Graph permissions, a reporting mailbox and moving the Microsoft quarantine into xorlab are separate, optional steps. * **On-premises** — the scope of your receive connector and a send connector on Exchange, or BCC rules for monitoring mode; firewall rules for SMTP between your mail servers and the xorlab MTAs; and your own mail servers registered inside xorlab as trusted infrastructure, which is a setting in xorlab rather than in your environment ([Add Your Trusted Infrastructure](/latest/on-prem-add-trusted-mtas)). What stays as it is: | Unchanged | Why | | :--------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Your MX records** | On Microsoft 365, email keeps arriving at Microsoft, which hands it to xorlab and takes it back for delivery. On-premises they change only if xorlab replaces your existing gateway. | | **Your outbound sending identity** | Outgoing email still leaves through Microsoft, so your public sending IPs, your SPF record and your DKIM signatures are unchanged. On-premises it changes only if xorlab replaces your existing gateway. | | **Exchange Online Protection and Defender** | If you use M365, Microsoft’s own filtering keeps running, and xorlab is layered on top of it. | | **Mailboxes, addresses, licenses and clients** | Nothing is migrated and no add-in is rolled out. Reporting uses the button your users already have. | Undoing it is the same size as doing it. Disabling the two mail flow rules puts email back on its previous path within minutes, with no DNS change and no cutover window. The full table for each path: which setting goes where, whether it is mandatory, what your users notice, and how to roll it back. ## What your users notice * **In monitoring mode, nothing at all.** No email is modified, delayed or blocked. * **In inline mode, with the delivered defaults**, email with a malicious verdict is quarantined instead of delivered, and some verdicts are delivered with a subject prefix such as `[SPAM]`. Both are adjustable in [Review Default Actions](/latest/detection-actions). * **Only if you enable them**, users get the [Self-Service Quarantine](/latest/ssq-overview) and the notifications that go with it, or [Contextual Banners](/latest/detection-contextual-banners) inside the message body. Both are off until you turn them on. ## What you maintain afterward **How much of the platform you operate depends on where it runs.** The security configuration — guarded domains, detection tuning, lists, users and roles — stays with you in both cases. | Task | xorlab SaaS | On-premises | Where it is documented | | :--------------------------------------- | :---------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Platform upgrades | Instances are updated automatically | You upgrade, within the support window of your major version | [Upgrading to a Patch Release](/latest/patch-upgrade), [Release Lifecycle Support](/latest/release-lifecycle-support) | | TLS certificates | Handled by xorlab | You renew and install them on the MTAs and on XCC | [Replace MTA SMTP Certificate](/latest/tls-certificates-for-mta-smtp), [Replace MTA GUI Certificate](/latest/tls-certificates-for-mta-proxy), [Replace XCC Certificate](/latest/tls-certificates-for-xcc) | | Backups | Operated by xorlab | Off by default, because the VM is usually covered by your hypervisor. If you switch them on, xorlab writes the backup files to a directory on the XCC and moving them somewhere durable is yours | [Backup & Recovery](/latest/backup-recovery) | | Monitoring and alerting | Operated by xorlab | Dashboards and a set of alert rules ship with the platform. You decide where alerts are delivered — email, webhook, Slack or your own systems | [Set Up Monitoring](/latest/monitoring-guide), [Enable Alerts](/latest/monitoring-alerts) | | Data retention values | Managed by xorlab on request | You configure them | [Data Retention Overview](/latest/data-retention-overview) | | Guarded domains, detection tuning, lists | Yours | Yours | [Detection Overview](/latest/detection-overview) | | Users, roles and single sign-on | Yours | Yours | [Authentication Overview](/latest/authentication-overview) | Releases are rolled out to SaaS customers first and monitored before they are announced for on-premises upgrades, so an on-premises upgrade is applied to a release that has already been running elsewhere. ## Where to start The complete integration in three steps, with the Microsoft 365 and on-premises paths side by side. The questions your mail, network and security teams ask before the project starts, answered per path. How a trial runs on live traffic without blocking anything, and how long each phase takes. Whether the rest of your stack is covered: SIEM, SOAR, identity, Microsoft Graph, threat intelligence.