> For the complete documentation index, see [llms.txt](https://docs.sendman.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sendman.com/admin-portal/sendman/authorization-policies.md).
# Authorization Policies
Define who may send mail through Sendman, from which addresses and to whom
## Overview
**Authorization policies** decide which sender and recipient addresses a client may use. Every message needs a matching policy:
{% hint style="warning" %}
Without policies, Sendman rejects every message, even from clients that have signed in successfully.
{% endhint %}
The table shows for each policy its **Priority**, whom it **Applies to**, the **Allowed senders** and **Allowed receivers**, and whether **Anonymous** sending is allowed.
## When does a policy apply?
A policy applies to a **username**, an **IP range**, or **both**:
| Applies to | The policy is used for |
| ------------------- | ----------------------------------------------------------------------------------------------------- |
| Username | Clients that signed in with exactly this username at the selected identity provider, from any address |
| IP range | All clients connecting from an address in this range, signed in or not |
| Username + IP range | Clients that signed in with this username **and** connect from an address in this range |
{% hint style="info" %}
Usernames are compared exactly, including upper and lower case. Use the same spelling as in the [SMTP credential](/admin-portal/sendman/smtp-credentials.md) or as the user principal name in Entra ID.
{% endhint %}
## Priority
Several policies can apply to the same client. Sendman then only uses the applicable policies with the **lowest priority value**. Policies with a higher value are ignored for this client.
If several applicable policies share the lowest priority value, they are combined. A message is accepted if **one** of these policies allows the sender and **all** recipients of the message.
{% hint style="info" %}
**Example:** Policy 1 (priority `10`) applies to the username `scanner-hq` and allows the sender `scanner@contoso.com`. Policy 2 (priority `100`) applies to the IP range of the office and allows the sender `info@contoso.com`. When `scanner-hq` signs in from the office, only policy 1 is used, so the scanner can only send as `scanner@contoso.com`, not as `info@contoso.com`.
{% endhint %}
## Add
Click **Add policy** and fill in the dialog.
### Priority
A whole number of `0` or higher. The default is `100`. Lower values are evaluated first, see [Priority](#priority).
### Applies to
| Field | Description |
| ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Identity provider** | `Sendman` for [SMTP credentials](/admin-portal/sendman/smtp-credentials.md), `EntraId` for Microsoft Entra ID accounts, or `None (address range only)` for a policy that only applies to an IP range. |
| **Username** | For `Sendman`, select one of your SMTP credentials. For `EntraId`, enter the user principal name, e.g. `scanner@contoso.com` (up to 100 characters). |
| **Start address**, **End address** | Optional IPv4 range the client must connect from. Both addresses are required to specify a range. |
At least a username or an IP range is required.
### Permissions
| Field | Description |
| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Allowed senders** | The envelope sender addresses (`MAIL FROM`) the client may use. One mail address per line, at most 100. Upper and lower case are ignored. |
| **Allow any recipient** | Allows sending to any recipient address. |
| **Allowed receivers** | If **Allow any recipient** is off: the envelope recipient addresses (`RCPT TO`) the client may send to. One pattern per line, at most 100. **Leaving this field empty blocks all recipients.** |
| **Allow anonymous sending** | Allows clients from the IP range to send without signing in, see [Anonymous sending](#anonymous-sending). |
| **Description** | Optional, up to 255 characters. |
#### Receiver patterns
Each line under **Allowed receivers** is a [regular expression](https://learn.microsoft.com/en-us/dotnet/standard/base-types/regular-expression-language-quick-reference) that must match the **whole** recipient address. Upper and lower case are ignored. Escape dots with a backslash.
| Pattern | Matches |
| ----------------------------- | ------------------------------------------------- |
| `helpdesk@contoso\.com` | Exactly `helpdesk@contoso.com` |
| `.*@contoso\.com` | Every address of the domain `contoso.com` |
| `.*@(contoso\|fabrikam)\.com` | Every address of `contoso.com` and `fabrikam.com` |
{% hint style="warning" %}
Every recipient of a message must be allowed. If a single recipient does not match, Sendman rejects this recipient with `550 5.7.1 Recipient not authorized`.
{% endhint %}
### Anonymous sending
Devices that cannot sign in can send anonymously if a policy allows it. Such a policy must:
* have **no username** (identity provider `None (address range only)`),
* have an IP range of at most 16,384 addresses, and
* have **Allow anonymous sending** switched on.
Clients that do not sign in can only send through policies with **Allow anonymous sending**. Keep the IP range and the allowed senders and receivers of such policies as narrow as possible. See also [Printers & Scanners](/configuration/get-started/scenario-based-guides/printers-and-scanners.md#devices-without-authentication).
## Edit
Click the edit icon of a policy to change it. Changes apply to new connections immediately.
## Delete
Click the delete icon of a policy and confirm. Senders that were allowed only by this policy are rejected from now on.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.sendman.com/admin-portal/sendman/authorization-policies.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
