> ## 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.
# Connect a SIEM
> Stream xorlab verdicts, threat intelligence, and audit events to any SIEM over Syslog in JSON or CEF, with pointers into the ingestion documentation of the common platforms.
**Optional**
This is a next step after the [standard integration](/latest/setup-integration-overview). xorlab protects email without a SIEM connected.
xorlab integrates with SIEM and log management platforms over **Syslog**, using either **JSON** or **CEF** as the message payload. Because both sides of that are standards, you need no xorlab-specific app, add-on, or connector. Any platform that can accept Syslog can ingest xorlab events.
Enable Logging via Syslog — the appender configuration, TCP/TLS, and all available parameters.
## What you can send
Logging is event-based: you choose which events to forward, so you can start with verdicts only and expand from there. The categories most relevant to a SIEM:
| What | Events | Why you want it |
| :------------------------------ | :-------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Email verdicts | `trace.msg_verdict`, `trace.msg_analysis.complete` | One record per email with the decision, direction, sender, and recipients — and with the extended JSON format also tags, risk and trust scores, attachment hashes, and extracted URLs. The backbone of email dashboards and correlation. |
| SMTP transactions | `trace.mta.received`, `trace.mta.send`, `trace.msg_delivered` | Accept/relay records with queue IDs, for mail flow tracing and delivery troubleshooting. |
| Threat intelligence | `ti.email`, `ti.ip`, `ti.file`, `ti.domain`, `ti.url` | Indicators extracted from malicious mail in *your* environment. See [Export threat intelligence](#export-threat-intelligence). |
| Analyst and admin audit trail | `audit.*` | Logins, message views and downloads, quarantine releases, list changes, campaign changes, config changes. Needed for compliance evidence and insider-risk monitoring. |
| Quarantine and release workflow | `audit.user.quarantine_release`, `audit.quarantine.release.request.*` | Who requested, approved, or denied a release, and when. |
| Case isolation | `audit.isolate.removed` | Records every email evicted from a mailbox. |
| Platform events | `sys.*` | Startup, shutdown, configuration commits, backup success and failure. |
The full list, with event IDs, severities, and the component each one is emitted by, is in the [Loggers reference](/latest/logging-events).
## Choose a payload format
| Format | Pattern | Use it when |
| :---------------- | :--------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| JSON | `%jsonMsg%n` | Default choice. Works for all events. Best when your SIEM parses JSON natively. |
| JSON extended | `%coreJsonMsg%n` | You want the complete email analysis result — attachments with hashes, extracted URLs, threat intel hits, headers — as a single record. Only valid for `trace.*` events. |
| CEF | `%cef%n` | Your platform expects ArcSight-style CEF, or you use a CEF-based data connector (for example CEF via AMA in Microsoft Sentinel). |
| Single attributes | `%logArg{key}` | You only need a few fields, for example to feed a lookup table. |
Details and worked examples: [Format Converters](/latest/logging-formats).
**Start with the extended JSON verdict event**
For most SIEM projects, forward `trace.msg_analysis.complete` with the `%coreJsonMsg%n` pattern. That gives you the highest value per event: exactly one rich record per email. A copy-ready configuration is in [Logging Examples](/latest/logging-examples).
## Transport and reliability
| Option | Notes |
| :---------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| UDP | Default. Simplest, but lossy, and messages are truncated to 1500 bytes unless you raise `messageSizeLimit`. Fine for low-volume audit events, not for extended JSON. |
| TCP | Recommended. Requires wrapping the Syslog appender in an `AsyncAppender`. |
| TLS (`SSL`) | Recommended when logs leave your network, for example to a cloud-hosted SIEM. Also requires an `AsyncAppender`. |
Both `RFC3164` (default) and `RFC5424` framing are supported through the `format` parameter, and `hostName` sets the log source identifier your SIEM keys on. See [Available attributes](/latest/logging-via-syslog#available-attributes).
For TCP and TLS, adding an `AsyncAppender` is mandatory. Without it, a slow or unreachable SIEM can affect xorlab. See [Use Syslog with TCP or TLS](/latest/logging-via-syslog#use-syslog-with-tcp-or-tls).
## Where to configure it in your SIEM
xorlab appears to your SIEM as a generic Syslog source, so the work on the SIEM side is the platform’s standard “add a Syslog source” procedure. We do not ship per-vendor apps. Use the vendor’s own documentation below, and point the source at the `syslogHost` and `port` you configured in xorlab.
| Platform | Receive xorlab events by | Vendor documentation |
| :------------------------------- | :---------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------- |
| Splunk Enterprise / Splunk Cloud | Splunk Connect for Syslog (SC4S), which Splunk recommends over a raw network input | [Splunk Connect for Syslog](https://splunk.github.io/splunk-connect-for-syslog/main/) |
| Microsoft Sentinel | Syslog via AMA connector, requires you to run a host with AMA | [Ingest syslog and CEF messages to Microsoft Sentinel](https://learn.microsoft.com/en-us/azure/sentinel/connect-cef-syslog-ama) |
| IBM QRadar | A log source with the Syslog protocol type, parsed by a universal DSM or a log source extension | [Adding a log source](https://www.ibm.com/docs/en/dsm?topic=management-adding-log-source) |
| Elastic Security | Elastic Agent with the Custom UDP Logs or Custom TCP Logs integration | [Custom UDP Logs integration](https://www.elastic.co/docs/reference/integrations/udp) |
| Graylog | Syslog TCP input (with optional TLS) or Syslog UDP input | [Syslog Inputs](https://go2docs.graylog.org/current/getting_in_log_data/syslog_inputs.html) |
| Sumo Logic | Syslog source on an installed collector | [Syslog Source](https://www.sumologic.com/help/docs/send-data/installed-collectors/sources/syslog-source/) |
| Cribl Stream | Syslog source, then route to any downstream destination | [Syslog Source](https://docs.cribl.io/stream/sources-syslog/) |
| Wazuh | Remote syslog on the Wazuh server | [Configuring syslog on the Wazuh server](https://documentation.wazuh.com/current/user-manual/capabilities/log-data-collection/syslog.html) |
| Datadog | Syslog source in Observability Pipelines | [Syslog Source](https://docs.datadoghq.com/observability_pipelines/sources/syslog/) |
Not listed here does not mean unsupported. Any platform with a Syslog listener works the same way — look for “syslog input”, “syslog source”, or “log source” in its documentation.
### If your collector prefers files
For on-premises deployments you can also write events to a rolling log file and let an existing agent or log shipper pick them up. This is often the path of least resistance when you already run a forwarder on every host.
Rolling file appender with size and retention policies.
## Export threat intelligence
The `ti.*` events are worth calling out separately. Whenever xorlab identifies a malicious element in an email, it emits the indicator as its own event:
| Event | Indicator |
| :---------- | :------------------------------- |
| `ti.email` | Malicious sender email address |
| `ti.ip` | Malicious sending MTA IP address |
| `ti.file` | Malicious attachment |
| `ti.domain` | Malicious embedded domain |
| `ti.url` | Malicious embedded URL |
Because xorlab derives these from attacks against your own organization, they are usually higher-signal than a generic feed. Common uses are populating a SIEM threat intelligence index, blocking indicators on the proxy or firewall, or hunting retroactively across other log sources.
## Verify the integration
1. Configure the appender and logger as described in [Enable Logging via Syslog](/latest/logging-via-syslog).
2. Generate the event you subscribed to — for verdict events, send a test email through xorlab.
3. Confirm the event arrives in your SIEM. If nothing appears, check in this order:
* Is the event emitted by the component whose `logback-audit.xml` you edited? Each component has its own configuration directory, listed in [Before You Begin](/latest/logging-before-begin).
* Is the chosen pattern valid for the chosen event? `%coreJsonMsg` only works for `trace.*` events.
* Is UDP truncating the payload? Extended JSON records easily exceed 1500 bytes — switch to TCP.
* Is the port reachable from the xorlab MTA and XCC? See the [Network Guide](/latest/network-guide).