Send As Permission in Microsoft 365 Outlook

In today’s digital communication landscape, email management is very important, and Microsoft Outlook stands out as a popular platform. “Send As” permission is a feature that allows users to send emails on behalf of another user or a shared mailbox. The process of setting “Send As” permission in Microsoft 365 environment involves granting specific rights through Exchange admin center, ensuring the delegate has the ability to send emails that appear to come directly from the mailbox itself. Understanding the steps to activate this functionality enables efficient delegation and collaboration within organizations.

Ever wondered how to let someone else send emails pretending to be you? Well, in the world of Microsoft Exchange, it all comes down to email permissions. Think of it as giving someone the keys to your email kingdom—but with clearly defined rules! These permissions are crucial for fostering collaboration, ensuring seamless communication, and streamlining various business processes. Without them, things could quickly turn into a chaotic mess of forwarded emails and missed deadlines.

Enter the “Send As” permission—a true game-changer! This nifty little feature is like a secret agent for your inbox. It allows authorized users to send emails that appear to originate directly from another user’s mailbox, a distribution list, or even a resource mailbox (like a conference room). Imagine the possibilities!

This article is your ultimate guide to mastering the “Send As” permission. We’ll demystify what it is, how it differs from other permissions (like its cousin, “Send on Behalf“), and provide step-by-step instructions on how to manage it effectively. By the end, you’ll be a “Send As” pro, ready to unlock a whole new level of collaboration and efficiency in your Exchange environment. So, buckle up, and let’s dive in!

Contents

Demystifying “Send As”: What It Is and Why It Matters”

Think of “Send As” permission as a digital disguise for your emails. Instead of your name popping up, the email appears to come straight from someone else’s mailbox, a distribution list, or even that trusty resource mailbox you use for meeting rooms! Essentially, it’s like borrowing someone’s email identity for a specific purpose. It’s also about keeping your mailboxes safe and secure.

Common “Send As” Use Cases

Administrative Assistants: Ever wondered how an executive seems to be everywhere at once? Chances are, their amazing administrative assistant is using “Send As” to fire off emails that look like they’re coming directly from the boss. This keeps communication seamless and professional.
Help Desks: Imagine sending a support request and getting a reply directly from “[email protected].” That’s “Send As” in action! It allows help desk teams to respond using a generic email address, ensuring consistency and a unified brand image.
Automated Systems: Whoa! What’s this? When your systems send out notifications (think password resets or order confirmations), they’re often using “Send As.” This way, the emails appear to come from a designated system address (like “[email protected]”) rather than a specific individual.

“Send As” vs. “Send on Behalf”: Knowing the Difference

Okay, picture this: You’re trying to send an email, and you want it to look like it’s coming from someone else. But wait! There are two ways to do it in the wonderful world of Exchange permissions: “Send As” and “Send on Behalf“. What’s the deal? Let’s break it down.

Send As: The Secret Agent

“Send As” is all about secrecy. When you have “Send As” permission, your email magically appears to come directly from the Mailbox, Distribution List, or Resource Mailbox you’re impersonating. The recipient has no idea it was you pulling the strings!

Think of it like this: An administrative assistant, quietly and efficiently, sends emails that look like they came straight from the CEO’s desk. No fuss, no muss, just seamless communication.

Send on Behalf: The Transparent Messenger

Now, “Send on Behalf” is totally different. It’s all about transparency. The email clearly shows who sent it on behalf of someone else. It’s like saying, “Hey, I’m John Doe, and I’m sending this email for Jane Smith“.

Imagine this scenario: A customer service rep responds to a support ticket. The email says, “John Doe on behalf of Support Team.” The recipient knows exactly who’s helping them, even if it’s under the team name.

When to Use Which: A Practical Guide

So, when should you use “Send As” versus “Send on Behalf“?

Send As: Use this when you want a seamless, uninterrupted flow of communication. The recipient should only see one sender, no questions asked.
- For instance: A help desk sending responses from a general support email address. You want it to look like the support team itself is answering, not an individual.
Send on Behalf: Choose this when transparency is key. It’s important for the recipient to know who is actually taking action, even if it’s on behalf of someone else.
- For example: When someone is covering for a colleague on vacation and needs to send emails from their inbox. It’s important to show who is actually sending the message.

“Send As” – Your Digital Doppelganger? It’s All About Delegation!

So, we’ve established that “Send As” lets you masquerade as someone else, digitally speaking. But let’s zoom out a bit and see the bigger picture. Think of it like this: the “Send As” permission is just one tool in a larger kit, called Delegation.

Imagine you’re a busy executive who is up to their eyeballs in meetings. You delegate tasks to your assistant. They handle your schedule (calendar delegation), manage your contacts, and, yep, even send emails as you (“Send As”). It’s all about entrusting someone else to act on your behalf.

The important part here is that “Send As” is specifically about email. Other forms of delegation can include:

Calendar Delegation: Allowing someone to manage your calendar, schedule meetings, and respond to invitations.
Contact Delegation: Granting access to your contacts list.
Task Delegation: Assigning tasks to others and tracking their progress.

Essentially, Delegation is the umbrella, and “Send As” is one specific, email-focused application. It lets your designated delegate step into your digital shoes and communicate on your behalf.

Under the Hood: How “Send As” Works in Exchange Server

Alright, let’s peek under the hood and see how Exchange Server makes the “Send As” magic happen. It’s not quite pulling rabbits out of hats, but it’s still pretty slick!

Permission Validation: Picture this: someone hits “send,” masquerading as another user. Exchange Server is like a bouncer at a very exclusive club, checking IDs. It looks at the email and asks, “Does this sender really have the “Send As” permission for this mailbox?”. The Exchange Server then verifies if the user has the correct “Send As” permission to use the specific mailbox. If not, the email gets rejected faster than a bad joke at a stand-up night.

Authentication in Action

Authentication Process: Now, authentication isn’t just about having the right key; it’s about proving it’s your key. When a user sends an email with “Send As” permission, Exchange doesn’t just take their word for it. The authentication process starts when the user authenticates into their own mailbox. This usually involves entering their username and password, or using multi-factor authentication if enabled. Then, when the user attempts to send an email “as” another user, the Exchange Server checks against its records to ensure the authenticated user indeed has been granted permission to “Send As” that other user.

Access Control Lists (ACLs): The Gatekeepers

Role of Access Control Lists (ACLs): The real heroes behind the scenes are Access Control Lists, or ACLs. Think of ACLs as the detailed guest lists for our exclusive email club. They’re attached to each mailbox, distribution list, or resource mailbox, and specify exactly who has which permissions, including “Send As“. When you grant someone “Send As” permission, you’re essentially adding their name to the ACL for that mailbox. So, when Exchange Server does its permission check, it’s really just consulting these lists. It’s critical that the ACLs are accurate and up-to-date for the “Send As” feature to function correctly.

Granting and Revoking: Managing “Send As” Permissions

So, you’re ready to become a “Send As” permission guru? Awesome! Think of this section as your ultimate “Send As” permission control panel. We’re going to explore the two main ways you can hand out (and take back!) these powerful permissions. It’s like being a digital Santa, but instead of presents, you’re giving the gift of masquerading as another mailbox. Just try not to let that power go to your head, okay?

We’ll cover both the graphical, point-and-click method using the Exchange Admin Center (EAC), and the command-line, keyboard-ninja style with PowerShell. Choose your weapon! Whether you are a graphical user or a command-line advocate, this guide is here to help you.

Using Exchange Admin Center (EAC)

The EAC is your friend when you prefer clicking buttons over typing code (no judgement here!). It’s like using a microwave instead of cooking over a campfire.

Step-by-Step Instructions: We will provide a detailed walkthrough (with pictures!) that show you how to grant “Send As” permissions through the EAC.
It’s so easy, even your grandma could do it (assuming she’s an Exchange admin, of course).
Finding the Right Spot: The EAC can sometimes feel like a digital maze. We’ll clearly show you exactly where to click to find the “Send As” settings. No more endless searching!

Using PowerShell

Ready to unleash your inner PowerShell wizard? This method is perfect for those who love automation and managing things in bulk. Think of it as having a superpower to manage hundreds of mailboxes with a single command!

Why PowerShell is Awesome: We’ll explain why PowerShell is your best friend for managing “Send As” permissions on a large scale. It’s all about efficiency and getting things done quickly.
PowerShell Command Examples:
- Granting Permissions: Here’s the secret sauce! We’ll give you the PowerShell command to grant “Send As” permissions. It’s like giving someone the key to your digital kingdom (but only for sending emails!).
- Revoking Permissions: Oops, made a mistake? No problem! We’ll show you how to revoke “Send As” permissions just as easily. Consider it the “undo” button for email permissions.
- Listing Permissions: Need to see who has “Send As” permissions on a mailbox? We’ve got you covered with the PowerShell command to list them all. It’s like having a digital detective at your fingertips.
Important Notes: Remember, with great power comes great responsibility (and the right PowerShell modules).
We’ll tell you what you need to have installed and what permissions you need to execute these commands. No one wants a “PowerShell permission denied” error, right?

The Active Directory (AD) Connection: Where Users Meet Permissions

Explain how Active Directory (AD) integrates with Exchange Server to manage user accounts and Permissions.

Think of Active Directory as the master directory, the big rolodex in the sky, for your entire organization. It’s where all your users, computers, and other network resources live. Exchange Server doesn’t operate in a vacuum; it leans heavily on AD for user authentication and Permissions management. When you create a user in AD, Exchange can then utilize that account and assign “Send As” Permissions. It’s a beautiful, symbiotic relationship… most of the time.
Discuss how changes in AD (e.g., disabling a user account) affect “Send As” Permissions.

What happens when someone leaves the company, wins the lottery, or gets abducted by aliens (okay, maybe not the last one)? Their AD account gets disabled, right? Well, guess what? If that user had “Send As” Permissions, those Permissions go bye-bye too! It’s like pulling the rug out from under their email privileges. AD is the source of truth; when it speaks, Exchange listens. So, disabling an account effectively revokes any associated “Send As” Permissions.
Mention the importance of keeping AD synchronized with Exchange Server.

Imagine this: you grant “Send As” Permission to a user, but Exchange hasn’t gotten the memo from AD yet. Awkward! This is why keeping AD and Exchange Server synchronized is crucial. Think of it as making sure both the left hand and the right hand know what each other are doing. Synchronization ensures that Permissions changes in AD are promptly reflected in Exchange, preventing potential email mishaps and security holes. Regular synchronization jobs are your friend. Treat them well!

“Send As” in the Cloud: Microsoft 365/Office 365

“Send As” Permissions in the Cloud: A Bird’s-Eye View
- Transitioning to the cloud with Microsoft 365 or Office 365? Great choice! Let’s see how “Send As” works up there in the digital stratosphere.
- In Exchange Online, “Send As” permissions retain their core functionality: allowing a user to send emails that appear to come from another mailbox, distribution list, or resource. Think of it as digital disguise, but for email!
The Cloud Twist: Key Differences to Watch Out For
- While the concept remains the same, the how can differ slightly. Managing “Send As” permissions in Exchange Online has some unique nuances compared to on-premises Exchange Server.
- One major point? The Exchange Admin Center (EAC) gets a facelift in the cloud. The interface might look a little different, so be prepared to navigate slightly altered menus and options. Don’t worry, it’s still intuitive, just a bit…cloudier!
- PowerShell pros, take note! While PowerShell remains a powerful tool for bulk management, some cmdlets might have different names or parameters in Exchange Online. Always double-check the Microsoft documentation to ensure you’re using the correct syntax. It’s like speaking a slightly different dialect of PowerShell!
Navigating the Cloud EAC: A Quick Guide
- While a detailed walkthrough comes later, here’s a teaser: In the Microsoft 365 EAC, you’ll typically find “Send As” permission settings within the properties of a mailbox or group. Think of it as finding the secret sauce within each object’s configuration.
PowerShell in the Cloud: Embrace the Cmdlets
- For those who love automation, PowerShell is still your best friend in the cloud. Get-Mailbox, Add-RecipientPermission, and Remove-RecipientPermission are your go-to cmdlets for granting and revoking “Send As” rights. Just remember to connect to Exchange Online first!
Authentication Evolution:
- The Cloud adds an element of modern authentication! Make sure your scripts and PowerShell sessions use the latest authentication methods for seamless and secure permission management.
Hybrid Environments: Bridging On-Premises and the Cloud:
- If you’re in a hybrid environment with both On-Premises Exchange and Exchange Online, pay special attention to synchronization. Use the appropriate tools to sync the object between the two environments.

Security Best Practices: Protecting Your Organization

Granting “Send As” permissions is like giving someone the keys to your car – you want to be really, really sure they’re trustworthy! Emphasize that _”Send As”_ is a powerful capability and must be handled with care to avoid misuse. Over-permissioning is a slippery slope to security incidents.
Think of it this way: every “Send As” permission you grant is a potential avenue for phishing attacks or internal data leaks. Remind readers of the _”Principle of Least Privilege”_ – grant only the minimum necessary permissions to perform a task.
Dive into the necessity of implementing robust auditing mechanisms to keep a close eye on “Send As” permission usage. It’s like having a security camera pointed at your email system. Consider these key areas:
- Regular Audits
  : Setting up regular reports on who is sending as whom. This provides insights into how the feature is actually being used.
- Alerts on Anomalies
  : Implementing alerts to notify admins if someone sends an email as someone they usually don’t, or if unusual volumes of emails are sent.
- User Training
  : Educating users about the appropriate use of “Send As” and how to recognize phishing attempts where someone might be impersonating a colleague or executive.
Recommend regularly reviewing “Send As” permissions. Things change, people change roles, and systems evolve. What was necessary six months ago might be a gaping security hole today. Add some points to cover:
- Quarterly Reviews
  : Schedule quarterly reviews of all “Send As” permissions to make sure they’re still necessary and appropriate.
- Offboarding Processes
  : Ensuring “Send As” permissions are revoked when an employee leaves the organization.
- Documentation
  : Keeping meticulous records of who has “Send As” permissions for what mailboxes, distribution lists, or resource mailboxes and the justification behind it.
- A well-managed “Send As” environment is a secure “Send As” environment. Don’t let complacency turn a useful feature into a security liability. By being proactive and attentive, admins can ensure that “Send As” enhances collaboration without compromising security.

Navigating “Send As” in Outlook: A User’s-Eye View

Okay, so you’ve got “Send As” permissions – awesome! But how does that translate into your everyday Outlook life? Let’s break down how this superpower actually works when you’re staring down that blank email canvas. It’s actually simpler than you might think, and once you get the hang of it, you’ll be “Send As“-ing like a pro.

First off, know that nothing changes until you decide to use it. When you open a new email, you’ll see the familiar “From” field with your own email address. The magic happens when you click on that “From” field. If you have “Send As” permissions for other mailboxes, distribution lists, or resource mailboxes, you’ll see them listed as options in a dropdown menu or address book.

Here’s where the fun begins! To send an email as someone else, simply choose the desired “From” address from the list. Type in your message like usual, and hit send. The recipient will only see the selected “From” address, never knowing it was actually you pulling the strings behind the scenes. Kinda James Bond-ish, right?

Where’s the “From” Button Hiding? (Outlook Screenshots Included!)

Now, for the million-dollar question: “Where is this mystical ‘From’ field anyway?” Great question! By default, Outlook sometimes hides the “From” field. Sneaky, I know! But fear not; here’s how to unearth it.

For Outlook on Windows:

Start composing a new email.
Click on the “Options” tab in the ribbon at the top.
Look for the “Show From” button and click it!
Now that “From” Button is visible, click on From and then “Other E-mail Address…” Now a new window called “Select an Email Address” appears to select the address you want to send the email as.

For Outlook on Mac:

Start composing a new email.
Go to “Options” and make sure From is checked! If not please check this to show the from button on your new email and reply emails.
Now that “From” Button is visible, click on From and then “Other E-mail Address…” Now a new window called “Select an Email Address” appears to select the address you want to send the email as.

Once you’ve revealed the “From” field, you’ll find it right next to the “To” field in your email composition window.

[Insert Screenshot of Outlook (Windows) Showing the “Options” Tab and “Show From” Button]

[Insert Screenshot of Outlook (Windows) Email Composition Window with the “From” Field Highlighted]

[Insert Screenshot of Outlook (Mac) Showing the “Options” Tab and “From” Dropdown checked.]

[Insert Screenshot of Outlook (Mac) Email Composition Window with the “From” Field Highlighted]

Tip: Once you’ve made the “From” field visible, Outlook usually remembers your preference, so you won’t have to repeat these steps every time.

Compliance and Governance Considerations

Navigating the Legal and Policy Maze
- Let’s face it, nobody loves compliance, but it’s like eating your vegetables—necessary for long-term health! When you hand out “Send As” permissions like candy, you’re potentially stepping into a minefield of internal policies, industry regulations (think GDPR, HIPAA, and more!), and even legal requirements. It’s not just about making sure emails get sent; it’s about ensuring you’re not accidentally leaking sensitive information or running afoul of some obscure regulation.
- Think of it this way: giving someone “Send As” permission is like giving them the keys to the kingdom (or at least the mailbox). You need to be absolutely sure they know how to drive responsibly and won’t take the organization on a joyride that ends in a legal ditch. For example, GDPR requires you to protect personal data, and that includes how emails are sent and who appears to be the sender. Imagine if someone misused “Send As” to impersonate an executive and leak customer data – ouch!
Documenting the “Why”: Rationale is Your Friend
- Here’s a tip: always, always, always document why you’re granting a particular “Send As” permission. This isn’t just bureaucratic busywork; it’s your get-out-of-jail-free card if things ever go sideways. Keep a record that clearly states:
  - Who is getting the permission.
  - What mailbox/distribution list/resource mailbox they can send as.
  - Why they need the permission (the specific business justification).
  - When the permission was granted.
  - Who approved the permission.
- This documentation acts as a paper trail that shows you considered the implications and had a legitimate reason for the permission. It’s much easier to explain a decision when you can point to a documented rationale than to try to remember the details months or years later.
Regular Audits
- Implementing regular audits of your “Send As” permissions to make sure all requirements are met.

Streamlining Administration with Security Groups

Okay, picture this: You’re the hero of your IT department, but lately, you’ve been feeling more like a permission-granting machine. Every other day, someone needs “Send As” permission for some mailbox or another. It’s all getting a bit… much, right?

That’s where our trusty sidekick, the Security Group, swoops in to save the day! Forget granting permissions to each individual user, a method guaranteed to introduce headaches and potential errors. Managing “Send As” Permissions with Security Groups is a game changer.

Security Groups are like digital containers. You throw your users into these groups, and then grant the permissions to the group, not the individual. Think of it like giving a master key to the entire cleaning crew instead of making individual keys for each cleaner. Much easier, right?

Why Security Groups are Awesome

Let’s break down why this method is far superior:

Simplified Administration: Adding or removing users? Just add or remove them from the Security Group. The permissions stay put, consistently applied.
Reduced Errors: No more accidentally skipping someone or mistyping a username. Set it and forget it (almost!).
Improved Manageability: Need to review who has “Send As” permissions? Check the group membership, not countless individual user settings.
Scalability: As your organization grows, scaling up is a breeze. Add new users to the group, and they instantly inherit the permissions.

How to Create and Use Security Groups for “Send As” Permissions

Here is an overview of how to implement this magic in your environment (You will need to refer to the relevant Microsoft documentation for precise steps based on your setup):

Create a Security Group: Use the Active Directory Users and Computers or the Microsoft 365 Admin Center (if you’re in the cloud) to create a new Security Group. Give it a descriptive name like “SendAs_HelpdeskMailbox“.
Add Users to the Group: Add all the users who need “Send As” permission for a specific mailbox (e.g., the help desk mailbox) to this newly created group.
Grant “Send As” Permission to the Group: Using either Exchange Admin Center (EAC) or PowerShell, grant the “Send As” permission to the Security Group for the target mailbox.

Example (PowerShell):
```
Add-RecipientPermission -Identity "Helpdesk" -Trustee "SendAs_HelpdeskMailbox" -AccessRights SendAs
```
(Replace "Helpdesk" with the identity of your mailbox and "SendAs_HelpdeskMailbox" with the name of your Security Group).
Repeat as Needed: Create additional Security Groups for other mailboxes or resources as required, and assign the appropriate users.

By leveraging Security Groups, you transform yourself from a busy permissions-granting machine to a strategic IT wizard. Embrace the power of groups, and watch your “Send As” administration woes melt away!

Troubleshooting Common “Send As” Issues: When Things Go Wrong (and How to Fix Them!)

Emails Not Being Sent: Houston, We Have a Problem!
- Incorrect or Missing Permissions: This is the usual suspect! Did you double-check that the user actually has “Send As” permission for the intended mailbox, distribution list, or resource? Triple-check! Sometimes a typo or a forgotten click can cause all sorts of headaches.
  - Troubleshooting: Verify permissions in EAC or via PowerShell (Get-Recipient | Get-MailboxPermission | Where-Object {$_.AccessRights -like “*SendAs*”}).
- Caching Problems in Outlook or Exchange Server: Oh, the dreaded cache! Sometimes, Outlook stubbornly holds onto old information. And occasionally, Exchange Server has a brain fart and needs a little nudge.
  - Troubleshooting:
    - For Outlook: Try restarting Outlook, clearing the Outlook cache, or recreating the Outlook profile.
    - For Exchange Server: Restart the Microsoft Exchange Information Store service. (But do this during off-peak hours, folks!).
- Exchange Server Configuration Errors: This is the deep end of the pool. Perhaps something is misconfigured with mail flow rules, connectors, or transport settings. This might require some advanced digging.
  - Troubleshooting: Review Exchange Server event logs for errors. Check your mail flow rules and connectors to ensure they’re not blocking the “Send As” functionality.
Permission Conflicts: When Permissions Collide!
- Sometimes, you’ve granted too many permissions, and they start fighting each other! “Send As” can sometimes clash with “Send on Behalf,” especially if the permissions are applied inconsistently. Think of it like two superheroes with conflicting powers – it doesn’t end well!
  - Identifying Conflicts: Carefully review all permissions assigned to the user and the target mailbox/DL/Resource. Use PowerShell to get a comprehensive view.
  - Prioritizing Permissions: Decide which permission type is truly needed and remove the conflicting one. If both “Send As” and “Send on Behalf” are assigned, consider if “Send As” fulfills the requirements.
- Pro Tip: Always document why specific permissions are assigned. You’ll thank yourself later when troubleshooting!
Auditing and Reporting: Who’s Sending What (and From Where?)
- You’ve granted “Send As” permissions – now how do you make sure they aren’t being abused? Auditing is your friend! Tracking “Send As” usage helps you spot potential security breaches or compliance violations.
  - Auditing: Enable mailbox auditing in Exchange Server to track when users send messages using “Send As.” The events can be viewed in Exchange Admin Center or exported via PowerShell.
  - Reporting: Use PowerShell scripts or third-party tools to generate reports on “Send As” permissions and usage. These reports can help you identify stale permissions or suspicious activity.
- Security Tip: Set up alerts for unusual “Send As” activity. For example, get notified if a user suddenly starts sending emails from a mailbox they haven’t used before.

And that’s all there is to it! Now you can send emails from different addresses without juggling multiple accounts. Pretty neat, huh? Go ahead and give it a try, and see how much easier managing your email can be!

Send As Permission In Microsoft 365 Outlook