I use several different domains for my side businesses. With that, I end up configuring email for each of these different domains which can be a bit of a pain to manage. There are different sets of usernames and passwords I have to track, 3rd party apps, etc. It can be a massive hassle. Additionally, when it comes time to actually use those email addresses, I end up bouncing between different browsers or clients. Let’s tackle M365 shared mailbox configuration for one of these non-primary domains.
M365 actually has a solution if you have licensed users. For scomurr.com, we actually use the Microsoft 365 Business Standard license.
I was actually put onto this path of using Shared Mailboxes by my buddy Jay Atkins: Jay Atkins | LinkedIn
Key Point: this blog post was created on 2/6/2024 – MS likes to change the look at feel of the portals all the time for no better reason than ‘cuz’. It’s pretty awful to try and track all of the changes across the 13 different portals they give you.
That’s why I am documenting this process as of today – if I have to add another one of these in the future, hopefully there will still be some reusable nuggets.
- I am going to be adding [email protected] as a shared mailbox within M365 so that I can access and send email without having to log into a 3rd party app.
- I currently use Zoho, so we’re going to have to swing over the MX records,
- make sure SPF is there,
- configure DKIM,
- and DMARC,
- then create the mailbox,
- ensure delegation is in place,
- disable sign in for the mailbox,
- and then configure Outlook,
- and test,
- and fix Sent Items,
- and take a victory lap!
Let’s get to it!
Add the Domain to M365
Log into https://portal.office.com, navigate to the admin portal, and then navigate to Domains -> Add Domain:
Once here, add the domain into the text box and then hit the “Use this domain” button at the bottom of the screen.
Now, we need to verify the domain. My domain is hosted on GoDaddy – M365 has line of sight to TONS of different registrars and it can help automate this Verify step. For me, all I have to do is hit verify and then log into my GoDaddy account. Once I do that, Microsoft does the rest for verification. Oddly, it does seem like I have to hit the Verify button twice, but this could be just because the portal gives no visual feedback that it is doing anything and I am not patient. I expect feedback when I click a button – so, 2x clicks it is.
Once the domain is verified, I click continue so that MS can add in the DNS records. It wants to add the MX, SPF (TXT), and autodiscover records. Sure. This seems like a good starting point, so I click the “Add DNS records” button at the bottom of the screen, give MS permissions to GoDaddy again, and it does the work. Now, click “Done”.
Great! This was fairly painless.
Adding in DKIM
This is especially important since DKIM is a requirement starting in Feb of 2024 per changes to Gmail, Yahoo, and other email providers.
Finding DKIM in the UI is a pain and possibly not possible. I believe this used to be under Threat Policies in the Security Center (one of the other portals), but it seems to have moved. After doing some digging on https://learn.microsoft.com, I found that the DKIM config can be managed at https://security.microsoft.com/dkimv2. It’s still in the Security portal, but how to organically navigate to it – no idea. Maybe I missed it – maybe if it wasn’t obvious that isn’t on me, the user. Maybe the portal should have intuitive navigation?
Now that we have the hidden portal for DKIM I can see thebamboobumble.com.
Check the box next to the domain you want, and then a flyout appears from the right.
Here, we click Create DKIM keys. This just takes a few seconds, and then a popup will appear with the DNS records we need to add to DNS.
Notice these are just CNAMEs that point at DKIM for the tenant. This makes it pretty easy for us as the users/consumers of the tenant as the keys are abstracted away a bit.
Now that we have the keys, it’s time to log into the DNS provider and add in the records. One of the things that is missing here is the TTL for the record – recommendation is 1 hour (3600 seconds). MS should put that on the screen here for ease.
Another quick note – if you do not copy the DNS records off the screen here, I am not sure how to get the page to redisplay them. The good news is that the follow a standard format which can be repro’d very easily.
Now that we have the DKIM DNS records, we can see in the MS portal that there is a slider button to enable DKIM.
But, this button does not work as of yet. If you hit it, you will get an error. We need to manually insert the DNS records into our DNS provider (GoDaddy again in my case).
Hit Save, and now we wait. At this point, everyone’s docs say it can take 24-48 hours for DNS to propagate. With that being said, it tends to take only a few minutes as my DNS is in the US and my M365 tenant is in the US as well.
So, the records are in place and DKIM is enabled. Now, we should be good to go.
Next Up: DMARC
Now, that DKIM is in place, it’s time to enable DMARC for The Bamboo Bumble domain. I’m not sure if the MS portal will help with this or not, but there are plenty of docs online on configuring DMARC. Here’s how I am going to do it – another DNS record in GoDaddy with the following config:
- Type: TXT
- Name: _dmarc (that’s an underscore in front)
- Value: v=DMARC1; p=none; rua=mailto:[email protected]
- TTL: 3600
Since I am configuring this for an initial pass, I am not going to configure the policy (p=) to do anything at this point. I will circle back on this later.
Good to go. Now, we have the domain and DNS fully configured.
Create the Shared Mailbox
Ok, back to the admin portal for M365. Shared Mailbox creation has moved right into the portal here. It used to be in EAC, I think it made a stop somewhere else even, and now its in the admin portal -> Teams & groups -> Shared mailboxes.
Now, we click “Add a shared mailbox” and fill in the details.
Save changes, and we now have a shared mailbox. From here, the portal does give you a link to add members to the shared mailbox.
Clicking here, I can add in myself as a member. My primary is [email protected], so I add this here and I now have the ability to use the shared mailbox as myself.
With that being said, we need to validate the permissions. First, we need to have the ability to see the mailbox. Second, we need the ‘Send As’ permission.
Key Note – I am not looking for send on behalf. If you grant this when you send the name on the mailbox will be ‘Scott on behalf of [email protected]’. Not what I am looking for – I want to be able to send as actual [email protected] – this is the ‘Send As’ perm.
To validate the perms, we head over to the Exchange Admin Center (EAC) -> Recipients -> Mailboxes -> [email protected] -> Delegation.
And here are the perms:
Clicking into each, I can see [email protected] is assigned both. Good to go!
Disable Sign On for the Shared Mailbox
This is just a best practice for the shared mailbox. When the mailbox is created, a user account is actually created within M365. The good news is that this is an unlicensed user. The bad news is that the unlicensed user can still log in. What is the password? It’s randomly generated behind the scenes. Will anyone ever guess it? Probably not. Any reason to give them the chance? Nope.
Back in the M365 admin portal, go to Users -> Active Users. Here, you should see a user account for the shared mailbox.
All we have to do is click on the account for the shared mailbox and then click the Block sign-in button.
That’s it. Now, we can still use the shared mailbox via the delegated permissions, but now no one can log into the shared mailbox directly. More secure.
Time to Test the Shared Mailbox
It’s time to add the shared mailbox to my Outlook client. It’s important to note that I use the PWA for Outlook – I don’t bother with the thick client, the “New Outlook” toggle, the lost address books, etc. I gave up on the Outlook thick client years ago, and just resigned myself to use the web client. However, you can easily create a short cut that looks just like Outlook itself following my instructions on this post:
Within the Outlook PWA (I am just going to say Outlook going forward), right mouse click on Folders and go to ‘Add shared folder on mailbox’
And just like that -we have our shared mailbox! Now, does it work?
First, let’s try to send. New Mail.
I can’t tell from which account I am going to send. I can only assume primary which is not what I want. I need control.
Outlook -> Options (up top) -> Show From
Now, in the new mail I can see the from box, but I do not automatically see [email protected] as an option.
Hit Other email address…and this is where the UI….sucks. It really doesn’t show you what to do here – what you need to do is type above where “Suggested contacts” shows up. Enter in the email address – as long as its the one tied to the shared mailbox this will all work.
Let’s send a test message and see if it works!
And here it is!
Sending emails both as a response as well as just straight to the shared mailbox works! We must be done, right?
Well, there’s a problem. Checking ‘Sent Items’ I don’t see any of the emails sent from the shared mailbox.
Where are they?
Obviously, we would want the sent items from the shared mailbox to land in the primary inbox’s sent items…right? I mean, what is this. Oy vey.
Anyway, let’s fix it.
Fixing Sent Items for the Shared Mailbox
This must just be a check box in the UI somewhere, right?
Time to break out PowerShell! It’s really not that bad, but this probably should just be the default and configurable via the UI.
Did it work?
I mean…no errors…but no feedback at all. <insert eyeroll and disappointed head shake here>
I guess we have to test it via just sending an email.
Success. We have successfully configured a shared mailbox and wired it up such that it is usable via Outlook. Piece of cake!