This week, I ran into a frustrating issue on a client’s Microsoft 365 tenant that took longer to solve than it should have. The symptoms? Either delayed email delivery or messages not arriving at all, without any bounce backs, which made troubleshooting much harder.

Troubleshooting with Ionos

We started with Ionos support, since they’re the provider and unfortunately, that turned into a dead end. The first tech said everything looked fine and claimed there was nothing to fix. The second tried to help, but didn’t seem to understand the difference between POP/IMAP and Exchange Online. They kept pointing to mail settings and saying things like, “Hmm, looks good to me” and “I don’t see a problem.” The third support agent finally recognized it was an M365 issue, but told us to contact Microsoft directly.

Here’s the problem: because the client’s M365 tenant is managed through Ionos, Microsoft won’t accept support requests from us. Every attempt just got auto-routed back to Ionos, we were officially stuck with no help from Ionos and Microsoft wouldn’t (couldn’t with the tenant agreement) help us with the issue either.

Looks Like We Are On Our Own

We ruled out a few things early on, blacklists, M365-to-M365 sender issues, spam filters. But as the issue dragged on for nearly two weeks, we started seeing something we hadn’t expected: even emails sent internally between users in the same tenant, on the same domain weren’t being delivered. No bounce backs, no errors, nothing.

I’m a sys admin for a living and I’ve worked with M365 and Exchange Online, but I certainly am not an Exchange expert in any form. I went into message traces and could see the emails that were “missing.” The traces showed them as successfully delivered to the users’ inboxes, but the users never saw them.

We tried disabling cached mode and restarting Outlook, no change. We checked Outlook on the web (via Office.com) and the messages didn’t show there either. I was hoping maybe it was a client-side issue we could fix with an Office reinstall, but the emails weren’t showing up anywhere.

We did notice some emails were getting routed to the Junk folder, which made sense, their Junk folders have been working fine for years. But the ones we were looking for weren’t in the Junk folder.  This is a tech savvy client and they had all looked in the Junk folder as soon as they realized something was up.

Progress!

The real clue came when users were able to search for the missing messages and open them. They were definitely in the mailbox somewhere, they just weren’t visible.

That’s when I started thinking about Outlook rules. Could the accounts have been compromised? Could someone have created a hidden forwarding rule? Sure enough, the first account we checked had no rules in the Outlook desktop client. We logged into Outlook on the web, and boom, there it was. A rule had been set to look for certain keywords in the subject or body, mark the message as read, and move it to the RSS Feeds folder.  None of the accounts with rules in them displayed the rules in Outlook.  They were somehow completely hidden from the desktop client and I didn’t dig into that at all.

It was actually a pretty clever trick. The mail delivered successfully, so there was no bounce back. it was marked as read, so it didn’t show up under the “Unread” favorites folder either. And let’s be honest, no one ever looks in the RSS Feeds folder in Outlook. Ever.  Did you even know Outlook had a folder for RSS Feeds?

Once we found the rule, everything made sense. We removed it, checked other users for similar rules, changed passwords, enforced MFA (it had been set to enabled prior) and began tightening security.

Takeaways From This Debacle

• If mail traces show successful delivery but the message isn’t visible, check obscure folders like RSS Feeds.
• Run the through messages that are quarantined or blocked in the spam logs.
• A compromised mailbox can use rules to hide email in surprisingly effective ways.
• Working with a third-party tenant provider like Ionos can complicate support, especially when escalation to Microsoft is needed.  I have been very happy with Ionos as their tenant host thus far.  But I’m incredibly disappointed in there lack of technical depth with it comes to M365 tenants.  To the point that perhaps they need a special team for M365 support or to just migrate those clients back to Microsoft entirely.
• Keep digging, when support is worthless (and Ionos was!) just keep digging.  I learned a fair amount about M365 tenants and mail delivery during all of this.

What to Watch For

• Rules that appear in OWA but not the client.
• Make sure passwords are strong!
• If MFA was disabled,  or only set to enabled, set it to enforced!  That would have saved this from happening in the beginning.
• MFA will cause some grumbles with less technical staff, but in reality they are the ones that need the protection the  most.
• Make sure the users know what phishing emails will look like and make sure the fully EXPECT to get phishing emails!

So What Happened?

Two weeks prior a user’s account was compromised.  This particular user had rights to other inboxes due to a previous employee leaving and a shared email type situation. This allowed the intruder to set rules on other mailboxes and generally cause havoc.  In this case the rules were very targeted, they were looking for words like invoice, deposit, payment, quote, remittance, etc in the subject and body of the email.  Which makes sense, the intruder needs money too! The rule marked the message as read and moved it to the RSS Feeds folder.  This was very effective in convincing users and myself that the mail was never getting delivered.  The tipping point for me was realizing that the mail was delivered (message trace!) and was somewhere in the mailbox if they could search for and find it.  That is single thing that made me go looking for rules.

One of the mailboxes had two rules, and the second rule was really weird.  It was written so any message from “pret819372 AT gmail.com” was delivered to the conversation history folder and marked as read.  I’m still stumped at this rule, clearly the threat actor was looking for incoming mail from that user and wanted it hidden.  I don’t know if that address points out who the threat actor is or not, but a Google search of the address turned up nothing.

This was a weird one. It took time, patience, experience and a little bit of instinct to figure it out. But it was also a solid reminder: just because email isn’t showing up doesn’t mean it’s not there, it might just be buried somewhere no one’s looking.

In short, if you need an M365 tenant, go straight to Microsoft… I would not recommend Ionos unless you know 100% that you can take care of the tenant on your own and will never need any support. https://www.microsoft.com/en-us/microsoft-365/buy/compare-all-microsoft-365-products?tab=1&OCID=cmmruikv4ct