Recently I was troubleshooting an issue where a service account was granted the Exchange RBAC ApplicationImpersonation role for another account. The following PowerShell cmdlets were used to configure the impersonation permissions:

New-ManagementScope -Name "Generic Mailboxes" -RecipientRestrictionFilter "DisplayName -like 'Generic*'"

New-ManagementRoleAssignment -Name "Impersonate Generic Mailboxes" -Role "ApplicationImpersonation" -User "ServiceAccount" -CustomRecipientWriteScope "Generic Mailboxes"

After allowing for replication, the Send-MailMessage cmdlet was used to validate that everything was working as expected. Unfortunately the Send-MailMessage cmdlet only worked when the from address was that of the service account failing when setting the from address to the impersonated account.

PS C:\> $Cred = Get-Credential
PS C:\> Send-MailMessage -SmtpServer smtp.office365.com -UseSsl:$True -Port 587 -Credential $Cred -From 'serviceaccount@contoso.com' -Body "Test" -Subject "Test" -To "recipient@contoso.com"
PS C:\>

The above example worked!

PS C:\> $Cred = Get-Credential
PS C:\> Send-MailMessage -SmtpServer smtp.office365.com -UseSsl:$True -Port 587 -Credential $creds -From 'genericmailbox@contoso.com' -Body "Test" -Subject "Test" -To "recipient@contoso.com"
Send-MailMessage : Transaction failed. The server response was: 5.2.0
STOREDRV.Submission.Exception:SendAsDeniedException.MapiExceptionSendAsDenied; Failed to process message due to a
permanent exception with message Cannot submit message. 0.35250:4D1F0000, 1.36674:0A000000, 1.61250:00000000,
1.45378:02000000, 1.44866:751D0000, 1.36674:0E000000, 1.61250:00000000, 1.45378:7A1D0000, 1.44866:3A010000,
16.55847:AE0E0000, 17.43559:0000000024020000000000000000000000000000, 20.52176:140F518C1D00103100000000,
20.50032:140F518C8D17000000000000, 0.35180:140F518C, 255.23226:C31F0000, 255.27962:0A000000, 255.27962:0E000000,
255.31418:F41F0000, 0.35250:0A003881, 1.36674:0A000000, 1.61250:00000000, 1.45378:02000000, 1.44866:18000000,
1.36674:32000000, 1.61250:00000000, 1.45378:1D000000, 1.44866:01000000, 16.55847:84000000,
17.43559:00000000A003000000000000AE00000000000000, 20.52176:140F518C1D00101053000000,
20.50032:140F518C8D1700001E000000, 0.35180:58000000, 255.23226:4800D13D, 255.27962:0A000000, 255.27962:32000000,
255.17082:DC040000, 0.27745:28000000, 4.21921:DC040000, 255.27962...
At line:1 char:1
+ Send-MailMessage -SmtpServer smtp.office365.com -UseSsl:$True -Port 5 ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.Mail.SmtpClient:SmtpClient) [Send-MailMessage], SmtpExcept
   ion
    + FullyQualifiedErrorId : SmtpException,Microsoft.PowerShell.Commands.SendMailMessage

PS C:\>

The above example failed!

Exchange provides different means of granting permissions from Delegation, Folder Permissions and Impersonation.

When the ApplicationImpersonation permission is granted it allows a service account to have full access to the account being impersonated including the ability to Send As that mailbox so you would expect that the above tests would have worked. Unfortunately this is not the case, the Impersonation permission allows an application using EWS to fully impersonate the mailbox. The Send-MailMessage cmdlet doesn't use EWS it uses SMTP which means in order to be able to send mail messages you must also grant the SendAs permission.

In order to test the Impersonation permission and validate that everything is working correctly you need to test using an EWS application. EWSEditor is on such tool that can be used for this purpose. With EWSEditor you can connect to the mailbox using EWS and send an email message by submitting a EWS xml message validating that everything is setup correctly.

In closing since Exchange Impersonation grants EWS permissions if you need to also be ale to send email using SMTP you must also grant SendAs permissions.