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

# Advanced SMTP Configurations

> Advanced Postfix SMTP settings in the postfix-custom folder, including next-hop syntax.

All configuration files mentioned here are in the folder `activeguard/mta/startup_cfg/postfix_custom/`.

## Next hop syntax

The following syntax can be used to set the next hop in routing-related configuration, for example in `transport` maps or in the `relayhost` parameter.

| Format     | Example                | Description                                                                                                                                                        |
| :--------- | :--------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Domain`   | `gateway.xorlab.com`   | Look up the destination through DNS MX records of the domain. This provides the most flexibility and automatic fallback if there are multiple MX records specified |
| `[Domain]` | `[gateway.xorlab.com]` | Look up the destination through DNS A records of the domain                                                                                                        |
| `[IP]`     | `[1.2.3.4]`            | Use the IP address directly as the next destination                                                                                                                |

## Sender-based routing

In sender-based routing, the next hop (referred to as `<next-hop>`) for the email is chosen based on the sender’s address (`MAIL FROM`). This configuration is usually only used in conjunction with recipient-based routing to address special cases.

First, we need to enable the sender-dependent transport in the `main.cf` file:

```shell theme={null}
sender_dependent_relayhost_maps = lmdb:/etc/postfix/sender_dependent_transport
```

If the `sender_dependent_transport` file does not exist, you have to create it.

<Note>
  **Routing precedence**

  Please be aware that recipient-based routing has **precedence** over sender-based routing. If a recipient address matches an entry in `transport`, it will overrule any next-hop configurations from a match in `sender_dependent_transport`.
</Note>

Afterward, for every sender that you would like to configure, add one line to the `sender_dependent_transport` file. You can specify sender email addresses as well as sender domains:

```shell theme={null}
# Example for sender domain-based routing
@xorlab.com         <next-hop>
# Example for sender email address-based routing
test1@xorlab.com    <next-hop>
test2@xorlab.com    <next-hop>
```

Afterward, click **Publish**. The new Postfix settings become active within about one minute.

## Subdomain matching

### Subdomains in transport maps

When configuring email routing in `transport`, subdomains are not matched by default. This means that if you want to route emails for both a domain (e.g., xorlab.com) and its subdomains (e.g., sub.xorlab.com), you must either specify them explicitly or use the dot-prefix (.) syntax to apply a wildcard rule.

```shell theme={null}
# Routing for xorlab.com
xorlab.com      smtp:<next-hop>

# Routing for xorlab.com and all subdomains
xorlab.com      smtp:<next-hop>
.xorlab.com     smtp:<next-hop>
```

If you want subdomain matching to be applied automatically for all entries in your transport file, you can enable it globally. To do this, add the following line to `main.cf`:

```shell theme={null}
# Enable subdomain matching for all transport entries
parent_domain_matches_subdomains = transport_maps
```

Afterward, click **Publish**. The new Postfix settings become active within about one minute.

### Subdomains in client access

In contrast, subdomain matching behaves differently for `client_access` and `relay_domains` configurations. For these settings, subdomains are automatically matched without requiring explicit entries. This is because Postfix performs a reverse DNS lookup on the EHLO IP address, which allows it to match both the domain and its subdomains seamlessly.

For example:

* In `client_access`, you only need to list the top-level domain (xorlab.com), and subdomains will be matched automatically.
* Similarly, listing the main domains as `relay_domains` in `main.cf` is sufficient for subdomain matching.

## Sender and recipient restrictions

This section explains how to impose generic restrictions on either a sending MTA or on a recipient address or domain.

<Note>
  **SMTP restrictions**

  The restrictions described in this section refer to the SMTP connection only. Emails rejected during the SMTP connection will not appear in the XCC web interface.
</Note>

### Reject clients

To reject emails from certain sender IPs or hostnames during the SMTP connection, list them in the `client_access` file with `reject`:

```shell theme={null}
# Reject SMTP connection based on IP or hostname (EHLO)
1.2.3.4           reject
1.3               reject
ehlo.example.com  reject
```

Afterward, click **Publish**. The new Postfix settings become active within about one minute.

### Reject recipients

To reject all emails to certain recipients, add these recipients to the file `recipient_access`:

```shell theme={null}
# Reject certain recipients or recipient domains
recipient@xorlab.com    reject
xorlab.net              reject
```

Afterward, click **Publish**. The new Postfix settings become active within about one minute.

## TLS configuration

TLS policies can be defined for xorlab Security Platform when acting as a client as well as when acting as a server. The policies are set in `main.cf`:

```shell theme={null}
# TLS policy as client
smtp_tls_security_level = may
# TLS policy as server
smtpd_tls_security_level = may
```

Supported values include:

* `none`: Disable TLS.
* `may` (default): Opportunistic TLS. Use TLS if the client, respectively the server, supports TLS.
* `encrypt`: Enforce TLS. Do not send or receive emails without TLS. No valid certificate required.
* `verify`: Enforce TLS and successful certificate verification. Only supported for `smtp_tls_security_level`.

All values and additional information can be found in the Postfix documentation for the [`smtp_tls_security_level`](http://www.postfix.org/postconf.5.html#smtp_tls_security_level) as well as [`smtpd_tls_security_level`](http://www.postfix.org/postconf.5.html#smtpd_tls_security_level).

After changing the TLS policy, click **Publish**. The new Postfix settings become active within about one minute.

## SMTP auth for specific email addresses

If you want emails sent from specific addresses to be routed through an SMTP server requiring authentication, you can follow this configuration. For example, you can authenticate xorlab Security Platform when sending reported email feedback from the `threatanalyst@example.com` address:

1. Set the desired sender address for feedback emails as described in [Feedback emails](/latest/email-template-sender-addresses#feedback-emails). We will use `threatanalyst@example.com` here. For any other email addresses, just skip this step.

2. Configure [sender-dependent transport](#sender-based-routing) in the `main.cf` file by enabling (uncommenting) this line:

   ```
   sender_dependent_relayhost_maps = lmdb:/etc/postfix/sender_dependent_transport
   ```

3. If the `sender_dependent_transport` file does not exist, create it and add this entry:

   ```
   threatanalyst@example.com [smtp.example.com]:2525
   ```

4. In the same folder, create two files: `sasl_passwd.lmdb` and an `sasl_passwd` file. Leave the former empty, while in the latter add this line:

   ```
   [smtp.example.com]:2525 username:password
   ```

5. Finally, go back to the `main.cf`file and add the following block under the line you enabled in step #2:

   ```
   sender_dependent_relayhost_maps = lmdb:/etc/postfix/sender_dependent_transport
   # Auth for sender_dependent
   smtp_sasl_password_maps = lmdb:/etc/postfix/sasl_passwd
   smtp_sender_dependent_authentication = yes
   smtp_sasl_auth_enable = yes
   smtp_sasl_mechanism_filter = plain
   smtp_sasl_security_options = noanonymous
   ```

6. Click **Publish**. The new Postfix settings become active within about one minute.

## Message size limit

The maximum message size that xorlab Security Platform will accept during an SMTP connection can be defined in `main.cf` and `postfix_custom/master.cf`:

```shell main.cf theme={null}
# Max accepted mail size in bytes, the limit can be increased if absolutely necessary
message_size_limit = 52428800
```

```shell master.cf theme={null}
mta.activeguard.xor:10026 inet  n       -       n       -       20      smtpd
  -o message_size_limit=57671680
```

<Tip>
  Note that the value of the `message_size_limit` setting in `master.cf` has to be 1.1x higher than in `main.cf`.
</Tip>

The default message size is 50 MB. This limit can be increased if necessary. However, consider the following points:

* Many major email providers don’t accept message sizes over 35 MB.
* The xorlab Security Platform file size limit for attachments sent to the Sandbox is 50 MB.
* Aggressively increasing the message size limit can slow down email processing times.

After changing the message size limit, click **Publish**. The new Postfix settings become active within about one minute.

## Additional configuration

xorlab Security Platform exposes the internal Postfix configuration files and thereby allows you to use the entire SMTP configuration that Postfix offers. This includes, for example:

* Address rewrites
* Header rewrites
* SMTP connection configuration (limit, rate, delay, etc.)

Please refer to the [Postfix documentation](http://www.postfix.org/documentation.html) if you want to configure one of those things.

Afterward, you can configure it directly in the Postfix configuration files that are exposed in XCC. Below you can find all built-in Postfix files. You can also add additional files in [Expert Editor](/latest/expert-editor).

<Note>
  **Postfix lookup tables**

  xorlab supports [Postmap](http://www.postfix.org/postmap.1.html) lookup tables in `lmdb:` format ([Lookup tables](http://www.postfix.org/DATABASE_README.html)).

  The following files are automatically postmapped: `client_access`,`client_access_tenant`,`recipient_access`,`sender_access`,`transport`,`sender_dependent_transport` and `postmap_*`.

  If you use a different file name, you need to either:

  a) Prefix your file `postmap_`.

  b) Create an empty file with the same name and `.lmbd` suffix. E.g., for `custom_transport`, you need to create an empty file called `custom_transport.lmdb` in the same folder.
</Note>

| Name                              | Postfix Resource                                                                                                                 | Description                                                                            |
| :-------------------------------- | :------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------- |
| `client_access`                   | [http://www.postfix.org/postconf.5.html#check\_client\_access](http://www.postfix.org/postconf.5.html#check_client_access)       | Restrictions based on the client hostname or IP during SMTP connection                 |
| `header_checks`                   | [http://www.postfix.org/header\_checks.5.html](http://www.postfix.org/header_checks.5.html)                                      | Is not active by default. You have to configure it first in `main.cf`                  |
| `main.cf` (or `main.cf.vmx.<id>`) | [http://www.postfix.org/postconf.5.html](http://www.postfix.org/postconf.5.html)                                                 | Main configuration                                                                     |
| `master.cf`                       | [http://www.postfix.org/master.5.html](http://www.postfix.org/master.5.html)                                                     | Normally, it should not be changed. Can break email routing easily                     |
| `recipient_access`                | [http://www.postfix.org/postconf.5.html#check\_recipient\_access](http://www.postfix.org/postconf.5.html#check_recipient_access) | Restrictions based on the RCPT TO during SMTP connection                               |
| `sender_access`                   | [http://www.postfix.org/postconf.5.html#check\_sender\_access](http://www.postfix.org/postconf.5.html#check_sender_access)       | Restrictions during SMTP connection based on the sender                                |
| `sender_access_add_header`        | N/A                                                                                                                              | Used only internally. Adds the `envelope from` into a new header `x-xor-envelope-from` |

## Reserved configuration

The following Postfix features are reserved for internal use and must not be configured:

* [`mynetworks`](http://www.postfix.org/postconf.5.html#mynetworks): Use the `client_access` file instead to allow certain IPs to relay emails through xorlab Security Platform
* [`content_filter`](http://www.postfix.org/postconf.5.html#content_filter)

## Multi-Tenancy

In a multi-tenant deployment, routing is configured with the same Postfix files described on this page, but they have to line up with the tenants declared in `shared/guarded_tenants.yml`:

* `transport` needs a next hop per guarded domain.
* `client_access` needs to permit the SMTP clients of every tenant.
* `client_access_tenant` prepends the header that xorlab uses to identify the tenant, matching the `tenantSelector` of that tenant.

Do not assemble this by hand from this page. [Configure Tenant Domains and Routing](/latest/multi-tenancy-domain-and-routing) contains the complete, consistent configuration for each supported topology (Default Chain, M365, Star, Front MTA and Full Chain).
