Exchange allows users to assign delegate access to other people to send messages on their behalf. In an on-premises deployment you can use the Exchange Management Console (EMC) or run the Add-AdPermission cmdlet in the Exchange Management Shell (EMS) to set up the necessary permission. For example, we could run the following command to allow Tony Redmond to send messages on behalf of Deirdre Redmond: Add-AdPermission –Identity "’Deirdre Redmond’ –User ‘Tony Redmond’ –ExtendedRights ‘Send As’ Of course, you might have guessed that Add-AdPermission adds Active Directory permissions to an account, which is what you’d expect as Exchange uses Active Directory permissions behind the scenes to ensure that users can do what they should. But Office 365 doesn’t use Active Directory permissions and therefore a different approach is necessary, which is why Microsoft provides the Add-RecipientPermission cmdlet instead. To delegate SendAs permission for a mailbox we need to run PowerShell, connect to Office 365, and run a slightly different command. Add-RecipientPermission –Identity '’Deirdre Redmond’ –AccessRights SendAs –Trustee ‘Tony Redmond’ So good so far… but then you might just have noticed that my PowerShell screen shot reveals that I also ran the Add-MailboxPermission cmdlet to assign full access to the mailbox (the Add-MailboxPermission cmdlet is available for both on-premises Exchange and Office 365). This is because having the delegated access to send messages on behalf of another user doesn’t provide any ability to access that user’s mailbox. Exchange quite rightly separates the two abilities so as to provide granular control over the access that someone might be assigned to a mailbox. However, in practical terms it’s often necessary for someone such as a administrative assistant to have full access to another person’s mailbox and as we’ll see, that ability also affects where “sent as” messages end up. If you make a mistake and need to remove full access,