> 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/configuration/get-started/scenario-based-guides/exchange-online.md). # Exchange Online Use Microsoft Exchange Online as the SMTP backend of Sendman This guide shows how to deliver mail relayed by Sendman through Microsoft Exchange Online, and how your clients can sign in to Sendman with their Microsoft Entra ID accounts. ## Choose how Sendman connects to Exchange Online Exchange Online accepts relayed mail in two ways. Choose one of them: | Option | Sendman identifies itself by | Senders | Typical use | | ----------------------------------------------------------------- | ----------------------------------------------- | --------------------------------------------------------------------- | -------------------------------------------- | | [A: Connector](#option-a-exchange-online-connector) (recommended) | Client certificate or fixed egress IP addresses | Any address in one of your accepted domains | Many devices with different sender addresses | | [B: SMTP AUTH](#option-b-smtp-auth-with-a-mailbox) | Username and password of a licensed mailbox | The mailbox's own address, plus addresses it has *Send As* rights for | Few devices that share one sender address | {% hint style="warning" %} Microsoft is retiring Basic authentication for SMTP AUTH (client submission) in Exchange Online. Sendman authenticates at the backend with username and password (AUTH LOGIN), so option B depends on SMTP AUTH with Basic authentication staying enabled for your tenant and mailbox. Check Microsoft's current timeline before choosing option B. For new setups we recommend option A. {% endhint %} ## Option A: Exchange Online connector With an inbound connector, Exchange Online recognises Sendman as one of your organization's mail servers. Sendman then delivers to your tenant's MX endpoint without signing in to a mailbox. ### Identify Sendman by certificate 1. Obtain a certificate from a public certificate authority whose subject name (CN or SAN) is a domain or subdomain that is an [accepted domain](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains) in your tenant, e.g. `relay.contoso.com`. Export it including its private key and the intermediate CA as a PFX file. 2. In the Exchange admin center, create a connector **from** *Your organization's email server* **to** *Office 365*, and choose **By verifying that the subject name on the certificate that the sending server uses to authenticate with Office 365 matches this domain name**. Enter the subject name of your certificate. See Microsoft's guide [Configure a connector to send mail using Microsoft 365 or Office 365](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365). 3. In the Sendman Admin Portal, go to **Settings → SMTP Backend**: * **Server address:** your tenant's MX endpoint, e.g. `contoso-com.mail.protection.outlook.com`. You find it in the Microsoft 365 admin center under **Settings → Domains → your domain → DNS records** (MX record). * **Port:** `25` * Switch **Authenticate at the backend with these credentials** off. * Click **Save backend settings**. 4. Under **Client certificate**, upload the PFX file with its password, then switch on **Use the client certificate for mutual TLS**. ### Identify Sendman by IP address If your Sendman instance offers [dedicated egress gateways](/admin-portal/settings/network-connections.md#sendman-egress), you can identify Sendman by its fixed IP addresses instead: 1. In **Settings → Network Connections**, switch on **Deliver through the dedicated egress gateways** and note the listed **Gateway addresses**. 2. Create the connector as described above, but choose **By verifying that the IP address of the sending server matches one of these IP addresses** and enter all gateway addresses. 3. Configure the SMTP backend as described above (MX endpoint, port 25, backend authentication off). No client certificate is needed. ## Option B: SMTP AUTH with a mailbox 1. Create or choose a licensed mailbox for Sendman, e.g. `sendman@contoso.com`, and make sure [SMTP AUTH is enabled](https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/authenticated-client-smtp-submission) for it. Security defaults and Conditional Access policies that block legacy authentication must allow this mailbox to sign in. 2. In the Sendman Admin Portal, go to **Settings → SMTP Backend**: * **Server address:** `smtp.office365.com` * **Port:** `587` * **Username** and **Password** of the mailbox * Leave **Authenticate at the backend with these credentials** switched on. * Click **Save backend settings**. 3. In your [authorization policies](/admin-portal/sendman/authorization-policies.md), allow only the mailbox's own address and addresses the mailbox has *Send As* permissions for as **Allowed senders**. Exchange Online rejects all other sender addresses. ## Clients signing in with Entra ID accounts Independently of the backend option, your clients can sign in to Sendman with the username and password of a Microsoft Entra ID account instead of a [Sendman credential](/admin-portal/sendman/smtp-credentials.md): * Create an [authorization policy](/admin-portal/sendman/authorization-policies.md) with **Identity provider** `EntraId` and the account's user principal name as **Username**, e.g. `scanner@contoso.com`. * The client uses the UPN and the account's password. In hybrid environments, the client can also sign in with `DOMAIN\user` or just `user`; Sendman resolves it to the UPN. * The client must use AUTH LOGIN or AUTH PLAIN. AUTH NTLM only works with Sendman credentials. {% hint style="info" %} Sendman validates the password directly with Microsoft Entra ID. The account must be able to sign in with username and password alone: multi-factor authentication or Conditional Access policies that require more than a password cause the sign-in to fail. Use dedicated service accounts for devices. {% endhint %} --- # 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/configuration/get-started/scenario-based-guides/exchange-online.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.