Pros and Cons of Using Distribution Lists vs. Shared Mailboxes in Office 365

Over the years, we've seen a number of clients who make good use of Shared Mailboxes in Exchange Online. But you may find that Microsoft's implementation leaves some room for improvement, and there may be some edge cases where this is not the right choice for your situation. This article hopes to demystify the Shared Mailbox and help you decide if it is the right solution for you.

My assumption in writing this is that you the reader are either the business owner or manager of IT, and that in either case the specific how-to accomplish the proper set up of the Shared Mailbox, Outlook, Mail Flow, or e-Discovery settings in Exchange Online is not as important to you as being able to weigh the pros and cons of different options. My company is like many other Microsoft cloud service providers; we provide the technical services to get things configured correctly once a decision is made, and that's something I am hoping you might reach out to us about it you're looking at or currently using Office 365. (If that isn't the case, these things aren't trade secrets; you can find instructions pretty easily using your favorite search engine.)

Firstly, what's a Shared Mailbox?

If you have an email address that you want several people to receive or reply to, you have a few choices about how to do this.

  • Distribution List / Distribution Group / Mail Enabled Security Group
  • Site Mailbox in SharePoint Online
  • Exchange Online Shared Mailbox
  • New: Office 365 Groups

Maybe in a future article, we'll look at some of the other options. Wouldn't that make a great e-book? For today, let's focus on the Shared Mailbox and how it compares to its closest cousin, the distribution list.

Most folks who've been using email a while are familiar with the distribution list, sometimes referred to as listserv by certain Internet dinosaurs. In simple terms, a distribution list is an email address like info@mycompany.com that will actually send the email to the inbox of multiple people. When you hit Reply All on such a message, everyone on the distribution list will get your message. Multiple copies of the message are sent to each individual, so if I delete my copy, you may still have yours.

Think of a distribution list like a copy machine sitting by the internal office mail sorter. Someone comes along and makes 12 copies, then puts a copy into each person's mail slot.

A Shared Mailbox is similar in that it can still have its own email address like the info@mycompany.com example above, but the mail goes to the shared mailbox. Individuals are given access, but they have to connect to the mailbox to see what's inside. Reply All will go to the sender and the Shared Mailbox. There's only a single copy of the message in that account; if Alara and I have access, if I delete a message from the inbox, it will be gone when Alara signs into the mailbox too.

In this case, no copy machine, but the mailbox itself is a slot in the mail sorter and the mail gets put directly there.

Why would you choose a Shared Mailbox over a distribution list?

A Shared Mailbox can send mail, so that replies come from billing@mycompany.com instead of person1@mycompany.com or person2@mycompany.com. If the goal is to get people to stop sending emails to a single person that need to be accessible to everyone in a department, a Shared Mailbox is one way to help accomplish that. That's because the mail will go to the Shared Mailbox when the recipient hits Reply. Another reason is to reduce clutter.

A third reason would be to conceal the identity of the sender. There are lots of business reasons you might need to do this. However, Office 365 can make this a challenge. There are some specific technical steps that need to performed in order to make sure that billing emails in the above example come from billing@mycompany.com and not companyowner@mycompany.com.

More importantly, by default the mail sent using the Shared Mailbox will still be in the individual's Sent Mail folder. That can make it significantly harder to track down a message, unless you know who actually sent it. There's another technical trick needed to change this behavior. However, doing so makes it harder to tell what user actually sent a message as the shared role. For most companies, this is a reasonable trade off.

If accountability is important, than there are ways to ensure it and still get the benefits of having a Shared Mailbox along with centralized communication. You can combine a Shared Mailbox and a distribution list for a best of both worlds configuration. You can configure mail flow in Exchange to modify the From or Reply To address. You can use e-discovery features available in the Office 365 E3 plan.

So, how to determine which option is right for you? Here's a handy PMI analysis you can use for easy reference. Feel free to apply your own weighting system to determine which choice works best for you based on your own priorities and goals.

  User Mailbox Distribution List Shared Mailbox
Increased Office 365 License Cost  Yes No No
 Can be converted later to User/Shared Mailbox? Yes No Yes
 Can be combined with Distribution List? Yes  N/A Yes
 More clutter in primary mailbox? N/A Yes No
Additional action needed from user to check for new mail? No No Yes (unless combined with distribution list or using separate logins on mobile devices) 
Can you login separately from primary account? N/A  No Yes, but not easily; caveats apply 
Impact on mailbox storage limits  N/A Negatively affects storage for all accounts on list  Comes with its own mailbox storage limit, separate from other accounts
Experience in Outlook It just works No additional configuration required  Shared account appears in list below primary account without additional configuration; additional configuration is needed to keep messages in Shared account Sent Mail folder.
Experience in Outlook Web Access It just works No additional configuration required Can easily switch to Shared account or display as a Shared Folder in your main mailbox; sent mail stays in Shared account's Sent mail folder if connected as such, but may need additional steps to do so when sending from the Shared Folder.
Experience in OWA Mobile App Authentication is not connected to the OS, but appears to persist for some time; notifications do appear in Android; Contacts and Calendar do not appear to sync with OS / other mobile apps. No additional configuration required Shared folders have to be set up in OWA on a PC to show up in OWA on mobile; special steps are required to send mail as the Shared Mailbox.
 Experience in Outlook Mobile App It just works No additional configuration required Ability to connect is not clearly proven or defined
 Experience in Native Apps
(Android / iOS)
Connect via ActiveSync/IMAP/POP  No additional configuration required Complex configuration needed, but possible; sent items stay in Shared account's Sent Mail folder.

I hope you found this analysis useful. If you did, leave us a comment. Perhaps later I will extend this to include other options for Office 365 mailbox that I mentioned above.

Outrageous Claims: Where Office 365 Leads, SharePoint Will Follow

Principal Architect Thomas Carpe shares his thoughts and opinions on the state of the art in SharePoint security, including predictions about things to come. This blog post is part of a continuing series leading up to and following the official launch of Liquid Mercury Solutions' new product Beowulf Identity Server.

 

 

Well, okay maybe that's not such an outrageous claim, since that's been Microsoft's strategy all along, right? What I mean here is that most improvements to SharePoint security have been coming out of changes driven by Office 365.  

So, for example, in 2013 we now have application and server based trust through OAuth type authentication. These are new; in 2010 land we could federate two farms through the mutual exchange of certificates, but there wasn't a really good story to tell around authorizing an individual application.

For folks who run on-premises environments, this means that there will be systems that have to be stood up and maintained alongside SharePoint that didn't exist before. For instance, admins now have to consider will they configure the app host services along with the rest of the basic SharePoint feature set. Or, will you do traditional Windows authentication or use a trusted login provider instead?

Living in a cloud first world also means that security measures we sometimes take for granted in Office 365 - like multi-factor authentication - aren't readily available to us in an on-premises farm. Yes, you could circumvent this by making your sites authenticate against ADFS 3.0 or WAAD/Azure ACS, but doing so is a complex exercise. If you're going to go that far, you'll have some very important decisions you'll want to make about what software package to use and how much you want to rely on either cloud-based or on-prem technology to manage something so important. Always keep in mind that if the authentication provider isn't available for any reason, nobody will be using SharePoint.

What we see happening in the industry now is that more and more products are switching from traditional Windows based authentication to claims based authentication. This change is no doubt fueled by the need to integrate in some respect with cloud platforms like Office 365. However, in the rush to support any possible type of authentication scenario, those same products are making trade-offs against single-sign-on.

Take SharePoint Online for example, where providing a windows-based SSO experience to the user requires running an IIS site specifically to redirect the user from a vanity URL to an Office 365 / ADFS sign-on page where the user's domain is already known. This trick lets us just ask for the user's Windows account and make the trip back to SharePoint without a login form, but this is something of a hack.

Another example comes from a third party product that supports many types of claims authentication including Windows, WAAD, and Office 365. Though the product is quite flexible, customers see issues with having to provide a forms based login when browsing between SharePoint sites and the product's web pages. Configuring things so that they are seamless from an authentication perspective takes significant work.

What we hope to see in the near future are improvements to the way these systems work together, both online and behind the company firewall, so that there's a better sign-on experience overall for the user. Seems like just a few years ago people were saying that federated authentication would mean not having to remember so many credentials, but there seem to be more systems today than there were at that time. Certainly, this one of the reasons why we built Beowulf, and we hope that Microsoft and other vendors will continue to open up new possibilities in this area too.