> ## 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.
# List of Verdicts
> The full classification scale and the action each level triggers, including how confidence modifies the outcome.
xorlab classifies every email with a final verdict. Verdicts range from benign to malicious and—along with their confidence—are the basis of the actions taken as a part of filtering out malicious emails. Verdicts are also used by analysts to classify reported emails as a part of the [Abuse Mailbox](/latest/abuse-mailbox).
You can search for the verdicts listed here with the `verdict:` keyword as described in [*Search*](/latest/search).
Some search keywords are **aliases** that match several verdicts at once — for example `verdict:policy` matches both Policy and Blacklist. See [Search aliases](#search-aliases).
## Malicious verdicts
The following table shows all malicious verdicts.
| Verdict | Search keyword | Description |
| ------------- | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Malware | `malware` | Email containing malware |
| Spam | `spam` | Spam email |
| Phishing | `phishing` | Phishing email |
| Policy | `filter` | Email that violates a built-in or custom security policy. For example, a file type is not allowed
xorlab Security Platform has many built-in policies that can be activated if needed. Policies are usually not trust-based and hold for all emails |
| Blacklist | `blacklist` | Sender, domain, link, or file is on one of your maintained [blacklists](/latest/blacklists) |
| Impersonation | `impersonation` | General impersonation emails. For example, the attacker uses your organization’s domain as sender domain |
| VIP Fraud | `vipfraud` | Special case of impersonation where the attacker impersonates a VIP (e.g., a CEO) |
| Extortion | `extortion` | Extortion emails, for example, monetary claims based on cryptocurrencies |
| BEC | `bec` | Business Email Compromise. For example, the sender being a compromised partner |
| Encrypted | `encrypted` | Email with an encrypted attachment that was held by [Attachment Airlock](/latest/ssq-attachment-airlock). Only assigned when Attachment Airlock is enabled |
**Policy and Blacklist**
Policy and Blacklist are two separate verdicts, but they are closely related and both are quarantined into the **Filter** quarantine.
* `verdict:policy` matches **both** Policy and Blacklist.
* `verdict:filter` matches **only** Policy.
### Additional verdicts for reported emails
The following additional verdicts can be used when resolving reported emails:
| Verdict | Search keyword | Description |
| --------- | -------------- | ----------------------- |
| Malicious | `malicious` | Generic malicious email |
## Benign verdicts
A benign verdict does not necessarily mean that the email is 100% benign. Benign verdicts are applied when no malicious verdict could be derived. Based on the positive indicators in the email (e.g., trust), a more significant (trustworthy) benign verdict is chosen.
### Reputation and trust-based verdicts
Verdicts that are based on reputation or trust are usually the most trustworthy benign verdicts.
| Verdict | Description |
| ----------- | -------------------------------------------------- |
| `reputable` | Sender has no trust but a reputable domain |
| `trusted` | Sender has a little trust |
| `business` | Sender has a good trust on organization level |
| `partner` | Sender has the highest trust on organization level |
| `personal` | Sender has a good trust on personal level |
### Others
All other benign verdicts are based on certain indicators found in the email, but do not necessarily mean that the email is benign.
| Verdict | Description |
| --------------- | ------------------------------------------------------------------------------------------------------------------------- |
| `external` | Most generic verdict. No other verdict could be applied |
| `popular` | Sender is a popular service |
| `cloudstorage` | Sender is a cloud storage service |
| `crm` | Sender is a CRM service |
| `bulk` | Sender is a bulk email service |
| `freemail` | Sender is a freemail service |
| `internal` | Internal email |
| `marketing` | Sender is a marketing service |
| `newsletter` | Email is a newsletter |
| `poll` | Sender is a poll service |
| `simulation` | Email from a phishing simulation service, as configured in [Phishing Simulation Tools](/latest/phishing-simulation-tools) |
| `socialnetwork` | Sender is a social network |
| `survey` | Email is a survey |
### Additional verdicts for reported emails
The following additional verdicts can be used when resolving reported emails:
| Verdict | Description |
| ----------- | ---------------------------------------------------------------------------------------------------- |
| `benign` | Generic benign email |
| `forwarded` | Used when a reported email has been inline forwarded, and therefore header information has been lost |
## Attachment verdicts
Attachments are classified separately from the email that carries them. These verdicts appear on the analyzed file, and are also what [File Analysis](/latest/file-analysis) reports.
| Verdict | Description |
| ---------------------------- | ---------------------------------------------------------------- |
| `malware` | Malware detected in the attachment |
| `office_activex` | Office document containing an ActiveX control |
| `office_dangerous_vbascript` | Office document containing a VBA script with high-risk functions |
| `office_vbascript` | Office document containing a VBA script |
| `office_dde` | Office document using Dynamic Data Exchange |
| `office_external_object` | Office document referencing an external object |
| `rtf_embedded_object` | RTF document with an embedded object |
| `executable` | Executable file |
| `script` | Script file |
| `shortcut` | Shortcut file |
| `flash` | Flash file |
| `encrypted` | Encrypted file whose contents could not be inspected |
| `archive` | Archive file |
| `legacy_archive` | Archive in a legacy format |
| `document` | Document file |
| `file` | Generic file. No other verdict could be applied |
## Search aliases
In addition to the verdict names above, the `verdict:` keyword accepts the following aliases. Each alias matches every verdict listed next to it.
| Alias | Matches |
| ----------- | ------------------------------------------------------------------------------------- |
| `malicious` | all malicious verdicts |
| `benign` | all benign verdicts **except** Simulation — search for that with `verdict:simulation` |
| `policy` | Policy **and** Blacklist |
| `vbascript` | `office_vbascript`, `office_dangerous_vbascript` |
| `activex` | `office_activex` |
| `dde` | `office_dde` |
| `extobject` | `office_external_object` |
| `embobject` | `rtf_embedded_object` |
| `legacy` | `legacy_archive` |
## Verdict precedence
After analysis, xorlab assigns a single final verdict to each email. This verdict is determined first based on its confidence (high, medium, or low), and then on its specificity. The final verdict controls which action (e.g., deliver with a subject rewrite or quarantine the email) is taken on the email.
**Confidence**: All high-confidence verdicts and verdicts without confidence have priority over all medium-confidence verdicts. And all medium-confidence verdicts have priority over all low-confidence verdicts.
**Specificity**: More specific verdicts have priority over more generic verdicts. The decision rules are evaluated in this order:
Simulation > Whitelist > Blacklist > Policy > Encrypted > Malware > BEC > Extortion > VIP Fraud > Impersonation > Phishing > Spam
**Whitelist** is a step in this order but is not a verdict. It assigns no verdict at all: it stops further evaluation, so the email keeps the benign verdict it would otherwise have received.
For example, if an email is determined to be Spam with high confidence, but also as Phishing with high confidence, the final verdict will be high-confidence Phishing. This is due to Phishing being a more specific verdict than Spam. If instead the email is only considered Phishing with medium confidence, then the final verdict would be high-confidence Spam because higher-confidence verdicts have precedence over lower-confidence verdicts.
### Rule priorities
The rules that determine the final verdict and decision are evaluated in a fixed priority order.
The order applies to emails and reported emails, as well as for all email directions.
The priority values of the built-in decision rules are documented in
[Detection Defaults → Rule priorities](/latest/detection-defaults#rule-priorities).
Access to that page is restricted.