Granting Send As Permissions in Microsoft 365

For Introist to send emails from a shared inbox, the Introist service account needs Send As permission on that inbox. This article covers how your IT administrator grants it.

Tip

Forward this page to whoever manages your Microsoft 365 tenant.

Before you start

Fill in these two values:

Service account	introist@<your-domain>
Target inbox	<inbox-to-grant>@<your-domain>

You also need an admin account with Exchange administrator or Global administrator rights.

The permission you need is Send As

Microsoft 365 offers three delegation permissions on a mailbox. Only one of them is correct here:

Permission	Grant it?	What it does
Send as	Yes	Mail is delivered as the inbox itself. This is what Introist needs.
Send on behalf	No	Mail is delivered as “Introist Service Account on behalf of <inbox>”. Recipients see the service account.
Read and manage (Full Access)	No	Grants mailbox read access. Does not allow sending.

Caution

Granting the wrong one is the most common reason this setup fails. Send on Behalf in particular looks like it worked — mail sends without error — but the From address is wrong.

Steps

1. Sign in to the Exchange admin center at https://admin.exchange.microsoft.com
2. In the left menu, go to Recipients → Mailboxes. If the target inbox is a shared mailbox, use Recipients → Shared instead.
3. Find and open the target inbox.
4. Open the Delegation tab.
5. In the Send as section, click Edit.
6. Click Add members, select the Introist service account, and confirm.
7. Click Save.

Repeat for each inbox Introist should send from. Permissions are granted per inbox — access to one does not carry over to another.

Verify

Reopen the target inbox → Delegation tab. The service account must be listed under Send as. If it appears under Send on behalf or Read and manage instead, remove it there and add it under Send as.

Wait for propagation

Note

Permission changes take up to 60 minutes to take effect in Exchange Online, and occasionally up to 24 hours. Do not treat the change as failed before that window has passed.

Once propagated, reconnect the account in Introist for the new sending address to appear.

Still not working

1. Is the target a real mailbox?
   Send As cannot be granted to an alias. If <inbox-to-grant>@<your-domain> is only a proxy address on another mailbox, there is nothing to grant the permission on. It must be its own user or shared mailbox. This is the usual explanation when the same setup works for one address but not another.
2. Was the permission granted to a group?
   Granting Send As to a security group that contains the service account works in principle, but propagates slowly and unreliably. Grant it directly to the service account instead.
3. Is an Application Access Policy restricting mailbox access?
   If your tenant uses application access policies to limit which mailboxes apps can reach, the new inbox must be added to the scoping group. Your administrator can check with Get-ApplicationAccessPolicy in Exchange Online PowerShell.
4. Compare against an inbox that already works
   Open the Delegation tab of an inbox where Introist already sends successfully and compare it side by side with the failing one. Whatever differs is the problem.

If none of the above resolves it, contact Introist support with the inbox address, the service account address, and a screenshot of the Delegation tab.