> ## 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.
# Choose What to Log
> Work out which events, which payload format, and which component's configuration file you need, before you touch any file.
Nothing is forwarded off the platform until you name the events you want. Decide that first: the event determines which configuration file you edit.
## Start from a goal
Each row is a complete answer: the events, the format, and the component whose `logback-audit.xml` you edit. The directories behind the container names are in [How Logging Works](/latest/logging-concept#one-configuration-file-per-component).
| Goal | Events | Format | Container |
| :---------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------- | :------------ | :-------- |
| One rich record per email: verdict, sender, recipients, tags, scores, attachment hashes, extracted URLs | `trace.msg_analysis.complete` | JSON extended | `Core` |
| Every verdict decision, including a verdict that changes later because a Sandbox scan finished out of band | `trace.msg_verdict` | JSON extended | `Core` |
| SMTP mail flow tracing: what was accepted, what was relayed, with queue IDs | `trace.mta.received`, `trace.mta.send` | JSON | `Mta` |
| Correlate an SMTP queue ID with the email's GGRID | `trace.msg_delivered` | JSON | `Core` |
| Full analyst and admin audit trail: message views, downloads, releases, list and campaign changes, config changes | `audit` | JSON | `Backend` |
| Successful and failed logins | `audit.access` | JSON | `Auth` |
| Quarantine release workflow: who requested, approved, or denied | `audit.quarantine.release.request` | JSON | `Backend` |
| Emails evicted from a mailbox by case isolation | `audit.isolate.removed` | JSON | `Backend` |
| Threat intelligence extracted from your own mail | `ti.email`, `ti.ip`, `ti.file`, `ti.domain`, `ti.url` | JSON | `Backend` |
| Backup success and failure | `sys.backup` | JSON | `Backend` |
| Platform lifecycle: startup, shutdown, configuration commits | `sys` | JSON | any |
**The most common starting point**
Forward `trace.msg_analysis.complete` with the extended JSON format. That is one record per email carrying the full analysis result, which is what most email dashboards and correlation rules are built on. The complete file is in [Configuration Examples](/latest/logging-examples#log-detailed-email-results).
The full catalog, with event IDs, severities, and the container that emits each one, is [Log Events](/latest/logging-events). Names are prefixes, so `audit` in the table above means every `audit.*` event. See [Names are prefixes](/latest/logging-concept#names-are-prefixes).
## Choose a payload format
The format is a `pattern` inside the appender, so you can use any of these with any channel. No action is needed yet; you fill it into the appender in the channel guide.
Default. Works for every event, and records that event's own attributes.
```xml theme={null}
%jsonMsg%n
```
The complete result of the email analysis as a single record.
```xml theme={null}
%coreJsonMsg%n
```
Message-tracing (`trace.*`) events only.
ArcSight-style Common Event Format. Works for every event. Pick it when your platform expects CEF.
```xml theme={null}
%cef%n
```
A few named fields instead of the whole record, for a lookup table or a compact alert.
```xml theme={null}
%logArg{item} %logArg{listName}%n
```
## Next step
Pick the channel that carries the events you chose.
A SIEM, a log collector, or any Syslog listener.
A mail per event, for rare events.
A rolling file on the xorlab host. On-premises only.