> ## 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.

# Rule Profiles

> A set of predefined rule parameters, mostly used to switch between monitoring and inline mode.

Rule profiles are used to:

* Switch between Inline and Monitoring mode
* Switch between Toothless and Active protection

The active profiles are configured in the `shared/guarded_tenants.yml` file:

```yaml guarded_tenants.yml theme={null}
tenants:
  - name: example
    ruleProfiles:
      - <profile1>
      - ...
```

You only need to list the additional profiles that you want to apply. The built-in default profiles `default.properties`, `local.properties`, and `ui.properties` are included automatically and must not be configured explicitly. All added rule profiles are added in order between `default.properties` and `local.properties`.

Configured `ruleProfiles` are applied in the specified order between the implicit `default.properties` and the implicit `local.properties` / `ui.properties`. This means that `local.properties` still overwrites the configured profiles, and the configuration that a user sets in UI (`ui.properties`) still has the highest precedence.

<Note>
  Do not add `default.properties`, `local.properties`, or `ui.properties` to `ruleProfiles`. They are applied automatically.
</Note>

The following table lists the available profiles:

| Profile                                             | Description                                                                                                                                                                                                                                                                                  |
| :-------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `default_actions.properties`                        | **Default profile for active inbound email security**<br /><br />It uses subject rewrites for lower confidence decisions and quarantine actions for higher confidence decisions. Subject rewrite text is `[SPAM]`<br /><br />It does not use attachment removal nor quarantine notifications |
| `no_subject_rewrite_no_quarantine.properties`       | **“Toothless” mode**<br /><br />This profile deactivates all quarantine actions and subject rewrites. This profile is usually used for evaluation purposes where xorlab should not perform any actions on the email traffic                                                                  |
| `no_auto_feedback.properties`                       | **Deactivates all automatic feedback and acknowledgment emails for reported emails**<br /><br />If used, users will not get any automatic reply after reporting an email<br /><br />**Note:** this profile does not prevent the sending of manual feedback through the web interface         |
| `default_dana.properties`                           | **Configures the default SaaS Sandbox (DANA) settings**<br /><br />Applies the default Sandbox scope, including the additional coverage for recipients in the *Exposed accounts*, *High-value targets*, and *Recipient dynamic analysis* lists                                               |
| `monitoring_dana_offline_only.properties`           | **Configures the default SaaS Sandbox (DANA) settings for monitoring mode**<br /><br />Same scope as `default_dana.properties`, but scans are performed offline                                                                                                                              |
| `no_dana_except_for_specific_recipients.properties` | Disables the Sandbox except for recipients in the *Recipient dynamic analysis* list                                                                                                                                                                                                          |
| `fp_low.properties`                                 | **Configures the detection to be less aggressive to avoid false positives**<br /><br />This profile should be added per default in all deployments and only removed when a more aggressive detection is required                                                                             |
| `learning_mode.properties`                          | **Can be used for active inbound email security during the learning phase of xorlab Security Platform**<br /><br />Basic defense is active (quarantining and subject rewrites), but advanced filters that depend on the learning are disabled to prevent false positives                     |

Deprecated profiles that will be removed in future releases:

* `fp_sensitive.properties`: It can still be used, but new deployments should instead use `fp_low.properties`.

<Info>
  The duration of the learning phase, and the delivered parameter values behind
  `default_dana.properties`, are documented in
  [Detection Defaults](/latest/detection-defaults#sandbox). Access to that page is restricted.
</Info>

## Common profile configurations

### Standard - inline and active

Standard inbound email security:

```yaml guarded_tenants.yml theme={null}
tenants:
  - name: example
    ruleProfiles:
      - default_dana.properties
      - default_actions.properties
      - fp_low.properties
```

### Toothless

Disable all actions on emails. Can be used as an evaluation mode as well as during learning phase if no actions should be taken:

```yaml guarded_tenants.yml theme={null}
tenants:
  - name: example
    ruleProfiles:
      - default_dana.properties
      - default_actions.properties
      # Disable quarantining and subject rewrites
      - no_subject_rewrite_no_quarantine.properties
      # Disable feedback and acknowledgments for reported emails
      - no_auto_feedback.properties
      - fp_low.properties
```

## Multi-Tenancy

`ruleProfiles` is a per-tenant setting, so in a multi-tenant deployment each tenant can run with a different profile combination. For example, you can keep a newly onboarded tenant in *Toothless* mode while all other tenants run the standard configuration.

* To apply the same profiles to many tenants without repeating them, put `ruleProfiles` into a shared config template, see [Using Tenant Config Templates](/latest/multi-tenancy-configsets).
* To override individual rule parameters for a single tenant instead of switching the whole profile, see [Manage Tenant Rules](/latest/multi-tenancy-rules#tenant-specific-parameters).