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

# Data Flow Overview

> Which components handle your email, which services they call while analyzing it, and what each of those services receives. Applies to on-premises and SaaS alike.

Three components make up the xorlab Security Platform, and this page describes the data that moves between them:

* **xorlab MTA** — the mail transfer agents that receive and forward email, analyze it, and decide the classification of each message. A deployment usually runs several of them.
* **xorlab Control Center (XCC)** — the web interface analysts and administrators work in. It also holds the configuration and the shared state, such as the quarantines. There is one XCC per deployment.
* **External services** — services that the MTAs and the XCC call over the network during analysis instead of doing the work locally. They are described one by one below.

<Note>
  **External** means external to the MTAs and the XCC, not outside xorlab. Every service
  listed below is operated by xorlab, apart from the DNS blocklists. Where a xorlab
  service in turn contacts a third party — a URL shortener, for example — the section
  below says so. Which company hosts each service, and in which country, is listed in
  [List of Data Sub-Processors](/latest/data-third-party-subprocessors).
</Note>

## Who operates which component

| Deployment  | MTAs and XCC                            | External services                                                                                            |
| :---------- | :-------------------------------------- | :----------------------------------------------------------------------------------------------------------- |
| On-premises | You run them on your own infrastructure | Operated by xorlab, except the Sandbox — and Tika, which runs alongside it — which you can also run yourself |
| SaaS        | Operated by xorlab                      | Operated by xorlab                                                                                           |

<Note>
  **In a SaaS deployment there is normally nothing here for you to change.** xorlab
  operates these services and defines their configuration. The options below for turning
  a service on or off describe on-premises deployments. What each service receives, and
  how long it keeps it, is the same either way.
</Note>

<Info>
  The data flow diagram and the order in which an email passes through the processing stages are
  documented in
  [Data Flow Details → Email processing pipeline](/latest/data-flow-details#email-processing-pipeline).
  Access to that page is restricted.
</Info>

## Description of External Services

### xorlab Sandbox

The xorlab Sandbox scans selected email attachments for malicious behavior in a secure, isolated environment. Supported file types include:

* MS Office files: Word (including RTF), Excel (including CSV), PowerPoint, OneNote
* PDF files

These files are transmitted over HTTPS and are only stored temporarily—typically for a few minutes—during the analysis process. After analysis, they are automatically deleted.

You can [configure](/latest/xorlab-sandbox) which file types are submitted for analysis.

Disabling file submission effectively turns off the Sandbox. You may also [disable the xorlab Sandbox entirely](/latest/xorlab-sandbox#disable-the-sandbox-completely), if required.

### xorlab Tika

The [Tika](/latest/xorlab-tika) service is used to improve the URL extraction and text extraction from attachments (for example, through OCR). It processes a defined set of file formats.

Attachments are sent to Tika via HTTPS for processing, then the extracted text is sent back. Files are only kept during processing.

Tika should not be disabled as it is a critical component for email classification.

### xorlab ML

The xorlab ML service uses machine learning based on indicators found in emails to further improve the message classification. The indicators are sent to the ML service over an HTTPS connection. The data does not contain personal or customer-identifying data, nor does it contain the message body data. The data is only kept during processing.

xorlab ML is active by default and cannot be disabled.

### xorlab NLU

The xorlab [NLU](/latest/xorlab-nlu) service uses natural language understanding to enhance the classification accuracy of the xorlab Security Platform by analyzing the semantics and intent of email content.

When enabled, selected content such as the subject line, message body, and extracted attachment text is securely transmitted to the NLU service via HTTPS. This data may include customer-identifying information and is therefore treated as sensitive.

The transmitted data is processed in-memory only and is never persisted or stored after analysis.

For on-premises deployments this service is disabled by default and needs to be [activated manually](/latest/xorlab-nlu#enable-xorlab-nlu-for-on-premises). You can also [limit which traffic it analyzes](/latest/xorlab-nlu#configuration-options).

### xorlab xCloud

xorlab maintains a centralized service for information around IPs, domains and URLs that is queried by the xorlab Security Platform. These queries are sent via HTTPS and contain domain names or IP addresses found in messages analyzed by xorlab Security Platform. You can’t turn them off. In general, the xorlab xCloud does not store the IPs, domains, and URLs beyond the time of processing. It may do so only in case of an error.

For shortened URLs (e.g., `bit.ly/foo`), xorlab xCloud may forward only the shortened URL to the external shortener service in order to resolve it. The resolved destination address is then evaluated like any other URL. xorlab does not open, download, or render the page behind that address, so no request from xorlab ever reaches the destination site itself. The traffic is via HTTPS.

The xorlab xCloud is active by default and cannot be disabled.

### External DNS Blocklists

Customers may enable the integration with third-party DNS TI services such as Abusix or Spamhaus. In such a case, xorlab may send domains, IPs, URLs and hashes to the third party TI service via DNS requests.

This integration is disabled by default and needs to be manually activated.