> ## 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. # Whitelists Whitelists—accessible by selecting **Settings → Lists → Whitelists** in XCC—allow you to accept emails based on specific indicators. **Subdomains** When you add a root (top-level) domain, e.g., `example.com`, to the list, all its subdomains will also be whitelisted. When you add a particular subdomain, e.g., `site.example.com`, only this subdomain will be allowed; any lower-level ones such as `other.site.example.com` won’t be affected. ## Safe senders Customize any of the lists below to ensure that emails of certain individuals, organizations, or top-level domains are delivered even if your applied risk policy would indicate otherwise. | List name | Description | Accepted entries | | :--------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------ | | **Registered domains** | Any domain names that are controlled by your organization and sound similar to the domains of guarded tenants | Domain name as `String`, e.g., `springfield-nuclear-newsletter.com` | | **Sender address whitelist (requires auth)** | Use this list to whitelist senders if their [5322.From](https://tools.ietf.org/html/rfc5322) identity can be verified | `mail-from` address as `String` | | **Sender address whitelist (no auth)** | Use this list to whitelist senders for which you don’t require authentication.
:warning: Use with care. Emails from senders in this list bypass threat analysis. This increases your attack surface to sender impersonation | Email address as `String` | | **Sender address airlock whitelist (requires auth)** | Use this list to whitelist senders whose emails will never be put into the airlock quarantine | Email address as `String` | | **Sender domain whitelist (requires auth)** | Use this list to whitelist organizations if their [5322.From](https://tools.ietf.org/html/rfc5322) identity can be verified | `mail-from` domain as `String` | | **Sender domain whitelist (no auth)** | Use this list to whitelist entire organizations for which you don’t require sender authentication.
:warning: Use with care. Emails from senders in this list bypass threat analysis. This increases your attack surface to sender impersonation | Domain name as `String` | ### Safe SMTP Senders | List name | Description | Accepted entries | | :------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------- | | **1. Envelope FROM sender whitelist (requires auth)
2. Envelope FROM sender whitelist (requires auth) (regex)** | Use this list to whitelist SMTP senders if their [5321.From](https://tools.ietf.org/html/rfc5321) identity can be verified. | 1. `envelope-from` address as `String`
2. `envelope-from` address as `Regex`, e.g., `bob\d*@whitelisted\.org` | | **Envelope FROM sender whitelist (no SPF)** | Use this list to whitelist SMTP senders for which you don’t require authentication.
:warning: Use with care. Emails from senders in this list bypass threat analysis | SMTP sender address as `String` | | **Envelope FROM domain whitelist (requires auth)** | Use this list to whitelist organizations if their [5321.From](https://tools.ietf.org/html/rfc5321) identity can be verified | `envelope-from` domain as `String` | | **Envelope FROM domain whitelist (no SPF)** | Use this list to whitelist entire organizations for which you don’t require SMTP sender authentication.
:warning: Use with care. Emails from senders in this list bypass threat analysis. This increases your attack surface to sender impersonation | SMTP domain name as `String` | ### Safe infrastructure | List name | Description | Accepted entries | | :------------------------------------------------------------------- | :--------------------------------------------- | :------------------------------------------------ | | **1. MTA EHLO whitelist (regex)
2. MTA RDNS whitelist (regex)** | Use this list to whitelist SMTP sender domains | Domain name as `Regex`, e.g., `mta\.partner\.org` | | **MTA IP whitelist (regex)** | Use this list to whitelist SMTP sender IPs | IP address as `Regex`, e.g., `192\.168\.1\..` | ## Safe recipients Customize any of the lists below to ensure that emails to certain email addresses are delivered even if your applied risk policy would indicate otherwise. Note that emails that also go to other recipients in your organization are not affected by these whitelists. | List name | Description | Accepted entries | | :-------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :-------------------------------------------------------------- | | **Recipient address whitelist (regex)** | Use this list to whitelist emails to these (guarded) recipients. Emails addressed to these and no other guarded recipients not on this list will always get through | Email addresses as `Regex`, e.g. `dmarc-reports.*@guarded.com$` | ## Accepted links Customize any of the lists below to exclude certain links from risk analysis. | List name | Description | Accepted entries | | :------------------------ | :------------------------------------------------------------------------------------------------ | :--------------------------------------------------- | | **Link domain whitelist** | Use this list to whitelist accepted link domains. Accepted links will not increase the risk score | Domain name as `Regex`, e.g., `businesscritical.com` | ## Accepted files Customize any of the lists below to exclude certain files from risk analysis. | List name | Description | Accepted entries | | :----------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------- | | **File extension whitelist (regex)** | Use this list to exclude files with a given extension from risk analysis | File extension as `Regex`, e.g., `\.txt$` | | **File output whitelist (regex)** | Use this list to exclude files with a given type from risk analysis.
The file type is based on the output of the `file` command | Pattern as `Regex`, e.g., `ASCII text` | | **File extension expected (regex)** | Use this list to indicate files with a given extension which are considered as expected in communication and shouldn’t increase risk when present | File extension as `Regex`, e.g., `\.txt$` | | **File output expected (regex)** | Use this list to indicate files with a given extension which are considered as expected in communication and shouldn’t increase risk when present.
The file type is based on the output of the `file` command | Pattern as `Regex`, e.g., `ASCII text` | | **Macro file whitelist (hash)** | Use this list to not consider as dangerous files with Microsoft Office macros.
To whitelist a macro file within an Office document, add its file hash to this list.
You can either whitelist the whole file or all the dangerous OLE-nested subfiles inside.
In order to understand which nested files should be whitelisted, you can check the drop-down list under **Attachments** in xorlab Control Center (if there is no email message with a file as attachment, it could be uploaded directly with the **File upload** feature).
For the nested files that have some macro keywords under their **Office analysis** tab, whitelist them by adding their `sha256` hashes to the list | `sha256` hash of the file | ## Accepted file behavior Customize any of the lists below to exclude files from risk analysis that exhibit a specific behavior during dynamic analysis. | List name | Description | Accepted entries | | :-------------------------------- | :-------------------------------------------------------------------- | :------------------------------------------- | | **Dynamic DNS request whitelist** | Use this list to whitelist domains in the context of dynamic analysis | Domain name as `String`, e.g., `backend.com` | ## Spam blacklist exclusion If some senders your organization communicates with have landed on a spam blacklist, you can circumvent this here. | List name | Description | Accepted Entries | | :--------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------ | | **SPAM sender exclusion from external blacklist** | Emails with sender's domain (`From` and `EnvFrom`) found in this list will not be affected by the external SPAM blacklists. This helps when certain free webmail provider MTAs land on SPAM blacklists and you want to ignore this. | Domain name as `String`, e.g., `bluewin.ch` | | **SPAM recipient exclusion from external blacklist** | Emails with recipient's address (`To`, `ReceivedFor`, `CC`, `EnvelopeRecipient`) found in this list will not be affected by the external SPAM blacklists. This helps when certain free webmail provider MTAs land on SPAM blacklists and you want to ignore this. | Email address as `String`, e.g., `user@xorlab.ch` | ## Contextual banners Configure which senders or recipients should not get a [contextual banner](/9.0/contextual-banners) on their emails. | List name | Description | Accepted Entries | | :------------------------------------------------- | :--------------------------------------------------------------------------------------------------- | :------------------------------------------------ | | **Contextual banners recipient address exclusion** | Use this list to exclude recipient email addresses within your organization from displaying banners. | Email address as `String`, e.g., `user@xorlab.ch` | | **Contextual banners sender address exclusion** | Use this list to exclude sender email addresses from displaying banners. | Email address as `String`, e.g., `user@xorlab.ch` |