> ## 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.
# Verdicts
xorlab Security Platform 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 the [Inbound Email Security](/9.0/inbound-email-defense). Verdicts are also used by analysts to classify reported emails as a part of the [Abuse Mailbox Automation](/9.0/abuse-mailbox-automation).
This page lists and describes all available verdicts in xorlab Security Platform.
**Verdict search**
You can search for the verdicts listed here with the `verdict:` keyword as described in *[Search](/9.0/search)*.
## Malicious verdicts
The following table shows all malicious verdicts.
| Verdict | Description |
| --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `malware` | Generic malware email. Statically detected malware is shown with `(S)` and dynamically detected malware with `(D)` |
| `spam` | Spam email |
| `phishing` | Phishing email |
| `policy` | Emails that match a certain policy (filter). For example, the sender is on your maintained blacklist or a file type is blacklisted
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 |
| `impersonation` | General impersonation emails. For example, the attacker uses your organization’s domain as sender domain |
| `vipfraud` | Special case of impersonation where the attacker impersonates a VIP (e.g., a CEO) |
| `extortion` | Extortion emails, for example, monetary claims based on cryptocurrencies |
| `exploit` | Exploit attachment. Either detected statically or during dynamic analysis |
| `bec` | Business Email Compromise. For example, the sender being a compromised partner |
### Additional verdicts for reported emails
The following additional verdicts can be used when resolving reported emails:
| Verdict | Description |
| ----------- | ----------------------- |
| `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 |
| `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 |
## Verdict precedence
After analysis, XSP 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. Concretely, this is the now-enforced list of verdicts in order of precedence: Simulation > Whitelist > Blacklist > Filter > Airlock > Exploit > Malware > BEC > Extortion > VIP Fraud > Impersonation > Phishing > Spam.
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](/9.0/detection-defaults#rule-priorities).
Password required.