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 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 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 instead of or 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 and not

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.

Lessons from the Field for Migrating to Office 365

Recently, I’ve talked a bit about how companies can save money in lots of places by moving to the cloud with Office 365, and I’ve also described some of the complexities involved in moving large file shares to SharePoint. Today, I’d like to take a few minutes to talk about some of the lessons learned on some of our Office 365 migration projects over the past several months.

Getting Good Information Up Front is A Challenge
As SharePoint developers, we’re used to working with the IT departments of larger organizations (say 500 to 5000 employees) as we develop solutions. However, with Office 365 customers, many times we’re not working directly with IT folks. The customer may have a managed service provider for desktop support, a part-time IT contractor, and some clients do not even have their own IT staff at all.

Needless to say, planning a move to Office 365 requires us to take stock of a great many technical details. It’s not surprising that folks outside of IT might miss the importance of the myriad trivial details involved.

But getting these facts wrong during the early stages can lead to incorrect estimates and costly mistakes down the road. It’s important to get the discovery right.
Here are some things customers should pay careful attention to when gathering information in the pre-project planning phase.

Basic Planning
Make a User Inventory
Know how many users you plan to have. We’re going to need their contact information, including phone and e-mail, because more than likely this information isn’t up to date in Active Directory. From there we can talk about what plans are best for your users.

Make a Workstation and Mobile Inventory
Know how many desktop PCs, laptops, and mobile devices you’ll be configuring. It’s also important to know what kind of mobile devices will be used and how many of each type.

Make a Server Inventory
Know exactly what servers you have, what operating system and version they run on, and exactly what purposes they serve (file shares, print server, domain controller, e-mail, etc.) If you do not know these things, you should consider paying for a 1 to 3 day evaluation to document all of your systems.

What Will You Turn Off After Migration?
Part of calculating the cost is understanding the benefits you get in return for it. If you’re not sure that a system can be fully disabled after moving to the cloud, that’s something we can help you figure out.

Will You Need Any Servers You Don’t Have?

For example, if you are synching Active Directory users to Office 365, you need a server to run this on - though it needn’t be very powerful. If you have applications running on servers that you otherwise want to decommission, you may need a server in the cloud to replace them. Likewise, if your security needs are high, you’ll want to have a CipherPoint Eclipse or F-5 Big IP running in the cloud in front of Office 365.

Domain Registration
You should verify that all your domain names are still current and that you have access to the DNS registration. We’ve occasionally had customers who have some older DNS names that were being used for e-mail aliases, and they weren’t able to migrate them fully because they’d lost the ability to manage the domain name. Check on these beforehand and avoid unpleasant surprises.

Remote Access
Some companies have VPN; this is ideal. Some do not and have to rely on clunky terminal servers or third-party services such as TeamViewer or LogMeIn. If you’re in the later circumstance or haven’t set anything up at all, we should talk about what is likely to cause issues for the folks doing the migration work, because not all of these services are created equal.

What’s Your Actual Available Bandwidth
Knowing if you have a T-1, cable modem, or DSL is helpful; it’s not the end of the story. We’ll want to perform some bandwidth tests at different times of the day in order to account for the connectivity that your company is already using. In general, migrations that have to be pushed to the evening or weekends will take longer.

Test for Equipment Bottlenecks
It’s also worth pointing out that some older equipment can actually be slower than the Internet connection can handle. Early on, we can do a trial run with a few files or a single mailbox in order to determine if there are going to be unexpected problems due to slow hard drives and outdated or overloaded servers.

E-mail Migration Planning
Know Your E-mail Server
Whether you’re using Exchange, Lotus, or some other server it helps to know what we’re dealing with. We’ll need to know how many users you have, how big are their mailboxes, and what distribution lists you’re using. It’s not unusual to find a few people in a company with mailboxes approaching 20GB (or bigger!). Anything at this size is going to take a lot longer to move than usual and that needs to be taken into account.

Great Firewall of Spam
For the mail server, the above is a good start, but not enough. You need to identify if you have an anti-spam appliance (e.g. Barracuda) or service (e.g. Postini) in front of your mail server. You probably won’t need it after moving to Office 365, but if you want us to make it a part of the move we need to know ahead of time.

E-mail Archives
Most people do not think about this, but Outlook Archives (*.PST) files do not move automatically to the cloud. One of the best approaches we’ve found is to copy their contents up into Exchange Online so that you’ll have access to them everywhere you go. If you’re using archives, it’s important to know this so we can take them into account when looking at mailbox sizes, migration plans, etc.

File Migration Planning
Make a File Inventory
Know where your files are, how big they are, what you will move, and what you might leave behind. Professionals have tools that can help to analyze your files and better determine the cost to migrate. However, these tools are only helpful if we have the opportunity to run them against all the files that will be moved.

Public Folders
If you use Exchange Public Folders, you will need to have those files copied down into a regular file share so they can be moved into SharePoint. Exchange Online does not support public folders, which have been phased out in recent versions of Exchange. When we determine the size of the file stores you’ll be moving, these files need to be included.

How Will the Migration Team Access Files?
Depending on the remote access method and the speed of your Internet connection, in some cases it may actually be faster to copy your files to a portable drive and FedEx them to us rather than have us try to copy them from your office. This also provides the fringe benefit of being able to split the migration up across multiple sites, which can make everything go faster.

Dealing with the Unexpected
Obvious, there’s no such thing as a crystal ball, and that’s even more true for IT. Aside from the things I talk about above that, little things can go awry during the project. It’s important to remember that migrating to Office 365 is a big change from the way companies used to work back in the 90s. Be ready to expect and deal with the unexpected.
Here are some things we’ve seen happen in the middle of a project that can really get things out of whack.

Sometimes it just takes longer to move files or e-mail than it seems like it should. It really helps to know exactly what we’re moving in the first place, but if your estimate and schedule were written sight unseen before we had access to the servers, then probably there are baked in assumptions that may prove to be wrong.

Even if we did a 1 day triage visit at the start of the project, sometimes the technology can make fools of us all. I had one customer where most mail moved over fine, but then one user’s mail dragged on and on weeks on end simply because their outdated server would not provide it any faster.

Needless to say, schedule creep can be very disruptive. As a result, we’ve learned to base our schedules on being 95% complete – anything more can be managed as ongoing support and needn’t cause everything else to back up waiting for it.

Limits of File Migration Tools
To move files into SharePoint is not a drag and drop operation. Fortunately, there are many good products on the market, and the state of the art is constantly changing. But, these products are not what I’d call mature - partly because Microsoft keeps changing the Office 365 platform itself. Over the years, we’ve seen file migration tools for SharePoint Online that don’t copy the date stamps on your documents, tools with poor or quirky support for Document Sets, and tools with draconian restrictions on the size of files that can be copied.

If we are copying a large volume of files, it is not uncommon that we may need to do a test run and then start over. We try to account for this in our estimates, but it’s not a perfect science. Tools are great, but if a tool or product does not get the results we want, we may have to switch tactics. This is not a sign of the coming apocalypse. Be prepared for this to be a part of the process.

Limits of E-mail Migration Tools
If you are migrating from Exchange 2007 or better, Microsoft has some great built in tools to make this possible. There are good third-party solutions for other platforms. Each of these has its own limitations. For example, Microsoft tools may not do well on extremely large mailboxes. Third party tools may be more robust, but they will take almost twice as long because they have to copy from the source and then copy to Office 365, whereas Microsoft has the benefit of running their tool in the same local network.

Limits of SharePoint
SharePoint is like any complex software product; it has boundaries. There are limits on the amount of storage you can have in a Site Collection, and limits on the number of items you can effectively put in a List or Library. Our job as consultants is to come up with plans and designs that avoid as many of these as possible. Still, it’s important to understand that Microsoft is constantly changing Office 365 – usually for the better. There have been times that we tried out a particular approach for organizing content and then had to change tactics because one of our assumptions proved to be incorrect.

Here are some examples of fiddly details that have sometimes pushed us around:

  • Flat views don’t work in large libraries (> 5000 items) even though you’d think they should be limited to the current folder.
  • In large libraries, indexes must be created before items > 5000.
  • Document Sets can only have one view inside the Document Set itself.
  • Nesting folders within Documents Sets is quirky.
    You cannot easily change the look and feel of the “my-sites” part of SharePoint.
  • And many more…

Shifting Requirements
Migrating to Office 365 is a big change. Training and discovery are a part of the process, and so you might learn something about the platform that you did not know at the beginning.

Likewise, we may learn something about your business that was not clear at the start and this could cause us to change our recommendations. Stay nimble and flexible; these moments can be opportunities to improve rather than a cause of stress.