554 5.2.0 SendAsDenied on Exchange Server: fixing Send As and Send on Behalf errors

A delegate picks a shared mailbox in the From field, clicks Send, and gets an NDR saying they can't send on behalf of this user. Exchange checked the sender's permissions when the message was submitted and found none it could use. This post explains the difference between Send As and Send on Behalf and shows how to grant and check each in Exchange Server SE and 2019. It also covers the replication, caching and Outlook issues that make a correct permission look broken.

Symptoms#

The NDR's text for the user starts with the first line below. Its diagnostic information for administrators contains the second:

You can't send a message on behalf of this user unless you have permission to do so.

554 5.2.0 STOREDRV.Submission.Exception:SendAsDeniedException.MapiExceptionSendAsDenied; Failed to process message due to a permanent exception with message Cannot submit message.

• Applications that authenticate to SMTP as one account but send from another address are rejected with Client does not have permissions to send as this sender. The status code in front of that text varies.
• Sending works from Outlook on the web but fails from Outlook.
• Send As worked for up to an hour after you granted it, then stopped.
• The message is delivered, but it shows "Jane on behalf of Sales" when it should appear to come from Sales.

Why it happens#

Microsoft adds two rules. If a user has both permissions, Send As is always used, and Send on Behalf doesn't work for a mailbox that's hidden from address lists. The usual causes are:

• The wrong permission. Full Access only, or Send on Behalf when the message should come from the shared mailbox itself.
• The permission hasn't taken effect yet. The change has to replicate to the domain controllers Exchange uses, and Exchange also caches mailbox permissions. Admins commonly report waits of up to two hours.
• Outlook used a stale address. Auto-Complete or an out-of-date offline address book can supply an address that no longer matches the mailbox, so sending fails in Outlook but works in Outlook on the web. Microsoft documents this for Microsoft 365, and it works the same way on-premises.
• A protected account. If the mailbox's AD account is in a protected group such as Domain Admins, the SDProp process reapplies the AdminSDHolder permissions every 60 minutes by default, which removes your Send As entry.
• An explicit Deny for Send As on the account. It overrides the Allow.

How to fix it#

1. Check what's actually granted#

$m = Get-Mailbox -Identity sales@contoso.com
$m | Get-ADPermission | Where-Object { $_.ExtendedRights -like "*Send-As*" } |
  Format-Table User, Deny, IsInherited -AutoSize
$m | Format-List GrantSendOnBehalfTo, HiddenFromAddressListsEnabled
Get-MailboxPermission -Identity $m.Identity | Where-Object { -not $_.IsInherited } |
  Format-Table User, AccessRights -AutoSize

What good looks like:

• The delegate, or a group they belong to, has Send-As with Deny False, or is listed in GrantSendOnBehalfTo.
• No Deny entries exist for Send As.
• HiddenFromAddressListsEnabled is False.

2. Grant the permission they actually need#

# Send As: the message appears to come from the shared mailbox
Get-Mailbox -Identity sales@contoso.com |
  Add-ADPermission -User "CONTOSO\jane" -AccessRights ExtendedRight -ExtendedRights "Send As"

# Send on Behalf: the message shows "Jane on behalf of Sales"
Set-Mailbox -Identity sales@contoso.com -GrantSendOnBehalfTo @{Add="jane@contoso.com"}

# Groups: Send As uses Add-ADPermission on the group; Send on Behalf is a group property
Set-DistributionGroup -Identity "Sales Team" -GrantSendOnBehalfTo @{Add="jane@contoso.com"}

In the EAC, the same settings are under Recipients › Mailboxes: edit the mailbox and open Mailbox delegation. Granting to a security group instead of individual users keeps this manageable.

3. Make sure it has replicated and taken effect#

Exchange reads permissions from domain controllers in its own AD site. Check against one of those, not the DC you happened to write to:

Get-Mailbox -Identity sales@contoso.com | Get-ADPermission -DomainController dc02.contoso.com |
  Where-Object { $_.ExtendedRights -like "*Send-As*" } | Format-Table User, Deny -AutoSize

If the entry isn't there yet, wait for replication or push it with repadmin /syncall /AdeP. Then give Exchange's permission cache time to refresh. Restarting the Microsoft Exchange Information Store service on the server hosting the delegate's mailbox applies the change at once, but it disconnects every mailbox on that server, so do it out of hours.

4. Fix the Outlook side#

1. Try sending from Outlook on the web first. If that works, the permission is fine and the problem is in Outlook.
2. In Outlook, delete the old Auto-Complete suggestion for the shared mailbox by pointing at it and clicking the X.
3. Choose From › Other E-mail Address › From... and pick the mailbox from the global address list rather than typing it.
4. In Cached Exchange Mode, a new mailbox may not be in the user's offline address book yet. Force an OAB download (see OAB not downloading).

5. Protected accounts and Deny entries#

# Requires the ActiveDirectory module (RSAT)
Get-ADUser -Identity sales -Properties adminCount, memberOf | Format-List Name, adminCount, memberOf

# Remove an explicit Deny
Get-Mailbox -Identity sales@contoso.com |
  Remove-ADPermission -User "CONTOSO\jane" -Deny -AccessRights ExtendedRight -ExtendedRights "Send As"

If adminCount is 1 because the account is in a protected group, remove it from that group (a shared mailbox account has no reason to be an admin). SDProp then stops overwriting its permissions. Re-enable permission inheritance and clear adminCount so the account gets its normal inherited permissions back.

6. Applications and hybrid#

For authenticated SMTP submission (the Client Frontend connector on port 587), the sign-in account needs Send As on every address it puts in From, or the From address must be its own. In hybrid, Send As and Send on Behalf across premises have their own rules. See cross-premises permissions in Exchange hybrid.

Verify the fix#

• The checks in step 1 show the intended permission when run against a domain controller in Exchange's site.
• A test message from Outlook on the web and from Outlook arrives without an NDR.
• Send As messages show only the shared mailbox in From. Send on Behalf messages show "Jane on behalf of Sales". In both cases, replies go to the shared mailbox.
• For a protected account, the Send As entry is still there an hour later.

Prevent it next time#

• Decide which From line each shared mailbox needs and grant only that permission, plus Full Access if delegates must read it.
• Grant through security groups and record each shared mailbox's owner.
• Keep shared and service mailbox accounts out of privileged groups.
• Tell users that new permissions can take a while to work, and that they should pick the From address from the address book.

References#

• Manage permissions for recipients in Exchange Server (Microsoft Learn)