So, I’m looking into changing up my email infrastructure. Currently, I’m using ProtonMail (paid) with my own domain for my personal E-Mails. In parallel to this, I use Mailbox.org (also paid) to host all my “other” emails, like, e.g., for my blogs (like this one) and other projects, using my own domains. I’m also using Cloudflare’s E-Mail forwarding service (free) to be able to at least receive on even more addresses than would otherwise be possible (but I can’t send from them).
However, I’m starting to reach some limitations with ProtonMail, Mailbox.org and Cloudflare that are becoming too cumbersome to deal with, which are probably better put into a dedicated article. It’s also becoming too fractured and messy to maintain.
Since there don’t seem to be any consumer-grade solutions on this planet which come anywhere close to what I need, I decided to look into business solutions.
One of those solutions, is Microsoft 365 Business. So, I started a trial yesterday. And it’s nothing but pain since. Nothing “just works”, and I have to constantly work around or against Microsoft’s strange decisions.
So, let’s get started with recounting the issues…
The painless beginning
I started by signing up for the trial, of course, using my real name (this is an important detail for later), everything worked fine, and I got to the admin panel.
The first thing I set up, is my primary “business domain”, let’s go for example.com here. This was straightforward, I added a TXT record to example.com to verify the ownership, then proceeded to create a CNAME record for autoconfiguration, an MX record to receive email and a TXT (SPF) record against spoofing. The setup was overall painless.
Then, I created my first email address, [email protected] (nice to meet you too) and set it as primary. So now that’s the email address I sign in with, and where email is sent from.
Then I set up a second domain, example.net for one of my websites, created an email alias for [email protected], and now I can receive to [email protected] on [email protected], perfect!
The pain begins: Aliases
OK, but now here’s where problems begin: E-Mails will always be sent out from my primary email address, [email protected] even if I receive on [email protected].
So, I figured, I’ll enable the “from” field, and specify the alias there. But no, Microsoft rewrites the name and email every time. I can receive on an alias, but not send from one.
So, I checked online: You have to sign in to a separate Exchange admin panel, and enable sending from an alias. Great!
But it doesn’t work. Or rather, it does not work over the web version. That Exchange admin panel seems to really only have an effect when using a native E-Mail client that is using Exchange. OK, fine: I set up Exchange on Apple Mail (natively supported), then I define the alias in the E-Mail client and it works! It sends from that alias without rewriting!
But, here’s where problems start again: If I add sindastra.de to my account, then create an alias and redo that setup: I notice it rewrites the name from Sindastra, to my full legal name.
So, sending from an e-mail alias works, but only through Exchange, but not with a different name. Microsoft always rewrites the outgoing name to your full legal name. Well, my name isn’t exactly secret, but I don’t necessarily want to plaster it everywhere, either. Besides, people would be confused if they email me on this blog here, and get an email from some random Natalie.
It seems, to this day, sending from an alias is a feature on Microsoft’s TODO list, there’s a public preview one can try, but it’s full of known issues.
The Alias Workaround: Shared Inbox
OK, so a sysadmin friend who uses Microsoft 365 for work told me of this workaround: Shared inboxes. You create a shared inbox in the admin panel, give it a name and an email address. So, for example, I could set the name “Sindastra”, together with an email using sindastra.de. This means it will always send with the name “Sindastra” and the chosen email address with my domain.
I then define members of the shared inbox (in this case I add myself, [email protected]), who can then access this inbox. I add this shared inbox to Outlook on the web, and now I can actually send from that name/email address!
But here’s where this falls short: I cannot actually access this shared inbox from Exchange using [email protected], and instead it creates a separate virtual account which I have to set up in the email client. While this works and gives me nice separation, it isn’t exactly convenient, and I’m starting to get into messy and cumbersome territory again if I have to manage a separate account for every identity.
Shared Inbox: The Messy Setup
OK, but before I get to the messy workaround I just described, I have to go through the messy setup, right? Here’s where things got weird.
So, say I want to create info at sindastra dot you know what domain. I will get an error message that [email protected] is already taken. OK, that’s… odd. I’m not asking for example.com, I’m asking for sindastra.de, so I figured, let me delete the alias from the main account. Now I can set up that info@ address for this domain here.
But now the shared inbox has taken over [email protected], and it’s there as alias, so I can’t have it on my primary account anymore. So, you’d think you can just delete the alias from the Sindastra account, right? Except it comes right back.
At first, it seemed like the username in front of the domain had to be unique. But that’s not actually the case.
What happens is, that every shared inbox creates a user account, and by default, it creates it under the primary domain. So that means [email protected] has to be free when creating any email address with info@, no matter the domain. So, the solution is to go to the user settings, find that Sindastra user, and change the primary email to the one I actually created the inbox for in the first place. Now that this is done, I can delete the alias.
Now, while this all makes sense and is easy to do once you figure it out, it still doesn’t make sense is that you cannot specify the user name when setting up the shared inbox. Because this means that if [email protected] is ever used anywhere, you’re in deadlock when wanting to create a shared inbox for info@ any domain.
Microsoft 365 and iPhone
OK, now that I set everything up, and it works on the desktop, through Apple Mail (Exchange) and Thunderbird (IMAP), let’s proceed to setting up the iPhone, right?
When using an IMAP account, Apple Mail allows you to specify pairs of names and email addresses to send from (aliases). So, I figured I’ll set up IMAP for my account.
Except, for some reason, Apple Mail on iPhone cannot connect to Microsoft 365 through IMAP. It claims it cannot connect over SSL (they mean TLS). This is strange, as it works on Thunderbird.
So, I look into adding an Exchange account instead, but I didn’t like the idea because this would allow Microsoft to remotely control or erase my device. Of course, the idea would be that I could initiate this remote erasure, but what if my account or Microsoft gets hacked?
So, I figure, let’s try setting it up through the “Outlook” option. It opens outlook.com, but it says the account does not exist. But it works fine on the desktop. My guess is: Microsoft blocks the sign-in through the “Outlook” option, to force you to use the Exchange option on iPhone.
Fine, I thought. I bite the bullet. I set up Exchange. Then I go to the advanced options, but… no way to set aliases? Ugh. It seems that’s not possible for Exchange accounts on iPhone.
The Outlook App on iPhone and S/MIME
OK, so maybe the Outlook App on iPhone could be a workaround? This way Microsoft has no control over my device, and maybe I can make use of all the features, right?
But, since I now have the partial workaround with the shared inbox, I didn’t even proceed to testing the alias feature (I’ll still have to, though) and went straight for the S/MIME instead (which, mind you, works natively and without fuss when using Apple Mail).
So, things get even weirder and more cumbersome. I have my S/MIME certificate/key installed on my iPhone. For security reasons, iOS installs this into the system keychain which third-party apps cannot access.
Naturally, I have to install the certificate/key into the Outlook app. How do you do that? Well… you have to email it to yourself. I’m not kidding, that’s what the documentation says.
OK, so, I thought, it’s a PKCS12 file (.pfx), which, if I’m not mistaken, is encrypted (and if I’m not mistaken, that’s what the “import password” is for, which you enter when importing, to decrypt it).
Alright… fine… since it’s supposed to be encrypted anyway, I send it to myself. I tap on the attachment, and look at that! It asks if I want to import it, I say yes, I provide the password, and now I have the S/MIME cert/key in the Outlook app on my iPhone!
So, I go to the settings, enable S/MIME, then flick the switch to enable automatic signing and… “You can’t do this right now. There’s a problem with one of your S/MIME signing certificates. Contact your IT help desk for more info”.
OK, I will look into this issue, and try to solve it, but simply because I’m curious. I’m pretty close to drawing the line, and my gut tells me that Microsoft 365 Business is not where I’ll be happy, since I seem to have “advanced” requirements where … I have to constantly work against Microsoft to get things running the way I want them.
MFA/2FA YubiKey
On another note, setting up MFA (2FA) was really strange, and is perhaps a rant for another time, but I don’t seem to have an option to use a hardware token (WebAuthn). My sysadmin friend said he has that option where I was looking, but I don’t have it at that location. My guess is that they want you to be on the higher price plan to use those? I don’t know. They only allow Authenticator, SMS and E-Mail on my end.
But yes, I’m not happy.
Conclusion
The only good thing Microsoft 365 does, is allowing the creation of subaccounts for free, to get separate mailboxes. I don’t know any other provider that does this for free. But they fall short when it becomes a must because sending from an alias isn’t possible.
So, Microsoft 365 is not a nice experience, and if I decide not to stick with them, there are two options left: Google Workspace, or self-hosting e-mail.
And I can already hear the cries that I shouldn’t self-host email, but I have years of experience, and the myths about the inability to email to Google or Microsoft were never true for me. I even just set up a postfix server days ago to test this: It worked fine. E-Mails arrived at Google and Microsoft servers on the first try.
If you’re wondering why I just don’t self-host then, well, if I self-host I still have to pay either way (servers aren’t free), and on top of that, I’ll have the maintenance work, backups, and all the fun stuff that comes with properly running a service. So, I’d rather find a solution that just works and saves me the time and work.
I don’t like the idea of using one of these big American tech giants, due to privacy issues, but unfortunately, all the small ones just don’t quite do it for me anymore. Although to be fair, neither does Microsoft. :D
Edit@2023-09-10 00:44: I added an explanation as to why the Outlook app cannot access the S/MIME certificate installed in iOS.
@[email protected] @[email protected] maybe Migadu (https://migadu.com) is what you’re looking for?i’ve personally used it and it has a lot of postmaster feature stuffs (what email provider lets you enable greylisting per domain?). they charge on usage and not per email address created.i do suggest evaluate it first, looking at the cons list (https://www.migadu.com/procon/) and trying it out within the trial period. there probably won’t be shared inbox stuff, but it could be made up with the potential for aliases (or identities).
If you can’t see the example email addresses: That’s because email addresses get protected automatically and require JavaScript to be seen. Unfortunately, there’s nothing I can do about that without disabling this protection entirely.