Microsoft 365 Email, Teams & Calendar Not Working? How We Fixed What Two Other Technicians Couldn’t

When your business email stops working, every minute counts. When your calendar invites fail to sync, meetings get missed. When Microsoft Teams refuses to let you attach files or even log in, your entire team grinds to a halt. Now imagine all of these problems happening at the same time — across iPhones, MacBooks, and desktops — and two separate IT technicians have already tried to fix things, only to make the situation significantly worse.

 

That is exactly the scenario a Dubai-based business brought to us at IT Tech 4 All. What started as a routine support call turned into a complex, multi-layered troubleshooting operation involving Microsoft 365 licensing conflicts, DNS misconfiguration, consumer account collisions, and the aftermath of a botched email migration. By the end of our service call, every single issue was resolved and the entire team was back online.

 

This article walks through exactly what went wrong, why previous repair attempts failed, and how our systematic diagnostic approach restored full functionality. If your business is experiencing similar Microsoft 365 problems, this case study will help you understand what is really happening behind the scenes and why choosing the right IT support provider matters more than most people realise.

The Client’s Situation: A Perfect Storm of IT Problems

The client, a small business operating in Dubai, had originally been using Microsoft 365 for their company email, calendar, and collaboration needs. At some point, a decision was made to migrate their email and workspace over to Google Workspace. The migration itself was handled by an external IT technician.

 

Unfortunately, that migration did not go smoothly. During the transition from Microsoft 365 to Google Workspace, critical mistakes were made. DNS records were improperly configured, email routing was disrupted, and — most painfully — the client lost access to a significant portion of their earlier emails. The historical email data that had been stored in Microsoft 365 was not properly backed up or migrated before the switchover, and by the time the damage was discovered, it was too late to recover those messages through normal means.

 

After living with Google Workspace for a period, the client realised they needed Microsoft Teams for their day-to-day collaboration. Teams video calls, file sharing, shared calendars, and channel-based communication had become essential for how their team operated. Google Meet and Google Chat simply were not meeting their requirements. The decision was made to switch back to Microsoft 365.

 

A second technician was brought in to handle the reverse migration — moving everything from Google Workspace back to Microsoft 365. Once again, the process was mishandled. DNS records from Google Workspace were left partially in place, conflicting with the new Microsoft 365 configuration. The result was a cascading series of failures that affected nearly every aspect of the client’s digital communication infrastructure.

 

By the time the client reached out to IT Tech 4 All, they were dealing with the following issues simultaneously:

 

Microsoft Teams calendar was not syncing with Outlook, meaning meeting invites sent through Teams were not appearing in users’ calendars and vice versa. Team members were missing scheduled calls and client meetings because their calendars showed different information depending on which application they checked.

 

File attachments in Teams were completely broken. When users tried to attach documents while sending meeting invites or posting in channels, the operation would fail silently or throw an error. This meant that important proposals, contracts, and project files could not be shared through the platform the team relied on.

 

One user was completely unable to send or receive emails. Their mailbox appeared to exist in the Microsoft 365 admin center, and a license was assigned, but mail simply was not flowing in either direction. External contacts sending emails to this user were receiving bounce-back messages, and outgoing mail from this account was failing silently.

 

Another user could not log into the Outlook mobile app on their iPhone. Every time they attempted to authenticate, they received an error message reading: “unauthorized_client: The client does not exist or is not enabled for consumers.” Despite having a valid Microsoft 365 E3 license with all services enabled, the mobile app refused to authenticate their account.

 

The frustration was compounded by the fact that two separate IT professionals had already attempted repairs and failed. The client had lost confidence, lost time, and lost data. They needed someone who could diagnose the root causes systematically rather than applying surface-level fixes that created new problems.

 

Why the Previous Repair Attempts Failed

Before diving into our resolution process, it is worth understanding why the two previous technicians were unable to fix these problems. The answer comes down to a fundamental difference in diagnostic methodology.

 

Many IT support providers approach Microsoft 365 issues reactively. They see that email is not working, so they check the mailbox. They see that Teams is not syncing, so they reinstall Teams. They see a login error, so they reset the password. Each of these actions addresses a symptom, but none of them addresses the underlying cause.

 

In this case, the root causes were buried in the infrastructure layer — specifically in the domain’s DNS configuration and in Microsoft’s identity management system. The DNS records for the client’s domain were in a hybrid state, with some records still pointing to Google Workspace while others had been updated for Microsoft 365. This created a situation where different services were routing to different platforms depending on which DNS record they queried.

 

The first technician who handled the original migration to Google Workspace did not create a complete backup of the Microsoft 365 mailbox data before redirecting the domain’s MX records. Once the MX records pointed to Google, incoming mail went to Google Workspace, but the historical mail in Microsoft 365 was no longer accessible through normal means. When the Microsoft 365 subscription was eventually downgraded or partially deactivated, that historical data was lost.

 

The second technician who handled the reverse migration back to Microsoft 365 failed to remove all of the Google Workspace DNS records before configuring the Microsoft 365 records. Specifically, the SPF record still contained Google’s SPF include directive alongside Microsoft’s, the DKIM records for Google were still in place, and some of the Google-specific CNAME records for mail and calendar services were still active. This created authentication failures for outbound email (SPF misalignment), confusion in email routing, and problems with autodiscovery — the mechanism that Microsoft 365 uses to automatically configure email clients.

 

Neither technician checked for the presence of a consumer Microsoft account conflict, which turned out to be the root cause of the mobile login failure for one of the users.

 

If your business has been through a similar experience and you need expert help with email and internet issues, the most important thing is to work with a provider who understands the full stack — from DNS and domain configuration all the way through to client-side app behaviour.

 

Our Diagnostic and Repair Process

When we took on this case, we started with a comprehensive audit before making any changes. This is a critical step that many IT support providers skip. Jumping straight into configuration changes without first understanding the complete picture is exactly how problems get compounded rather than solved.

Step 1: Full DNS Audit

The first thing we did was pull up the complete DNS record set for the client’s domain. We examined every MX record, TXT record, CNAME record, and SRV record that was configured at their domain registrar.

 

What we found confirmed our suspicion. The domain’s DNS was in a conflicted state. MX records had been updated to point to Microsoft 365’s mail protection servers, which was correct. However, the SPF TXT record still included Google’s SPF directive alongside Microsoft’s, which meant that the domain’s email authentication was ambiguous. Receiving mail servers could not definitively verify whether an email from this domain was legitimately sent through Microsoft 365, because the SPF record was also claiming that Google’s servers were authorised senders.

 

Additionally, Google’s DKIM CNAME records were still present, and several Google Workspace service CNAMEs for mail and calendar were still active. These leftover records were not only unnecessary — they were actively interfering with Microsoft 365’s autodiscovery and service routing.

 

We systematically removed every Google Workspace DNS record that was no longer needed. This included all five of Google’s MX record entries, the Google SPF include directive, the Google DKIM selector CNAME records, the Google site verification TXT record, and all Google service CNAME records for mail, calendar, and drive.

 

We then verified that the Microsoft 365 DNS records were correctly configured. This included the primary MX record pointing to the tenant’s mail protection address, the autodiscover CNAME record pointing to Microsoft’s autodiscovery service, the SPF TXT record containing only Microsoft’s SPF directive, the SIP and Lyncdiscover CNAME records required for Teams, and the SRV records for SIP federation that enable Teams calling and federation features.

Step 2: Resolving the Teams Calendar Sync Issue

With the DNS foundation corrected, we turned our attention to the Teams calendar synchronisation problem. Teams calendar sync depends on the Exchange Online mailbox being properly provisioned and the user’s Outlook calendar being accessible through Exchange Web Services. If the Exchange Online license is not properly assigned, or if the mailbox is in a deprovisioned state from a previous migration, the calendar sync will fail silently.

 

We verified that each user had a fully provisioned Exchange Online mailbox as part of their Microsoft 365 E3 license. In one case, the mailbox existed but was in a disconnected state — a remnant of the earlier migration that had not been properly cleaned up. We reconnected the mailbox, verified that the Exchange Online service was enabled in the license assignment, and confirmed that calendar sync resumed within Teams.

Step 3: Fixing File Attachment Failures in Teams

The file attachment issue in Teams was related to SharePoint Online and OneDrive for Business provisioning. When users attach files in Teams meetings or channel conversations, those files are stored in SharePoint Online (for team channels) or OneDrive for Business (for one-on-one chats). If these services are not properly provisioned or if the user does not have the correct license components enabled, file operations will fail.

 

We checked the SharePoint Online and OneDrive for Business service status for each user and found that OneDrive provisioning had not completed for several accounts. This is a common issue when accounts are created or migrated in bulk — the OneDrive personal site provisioning can take up to 24 hours and sometimes needs to be manually triggered. We initiated the provisioning process through the SharePoint admin center and confirmed that file attachments began working in Teams once the storage backends were active.

Step 4: Restoring Email Flow for the Affected User

One user was completely unable to send or receive email. We began by checking the basics: license assignment, mailbox status, and mail flow rules. The license was correctly assigned with Exchange Online enabled. The mailbox existed and was in an active state.

 

The problem turned out to be in the email address configuration. During the back-and-forth migration between Microsoft 365 and Google Workspace, the user’s primary SMTP address had become misaligned. The mailbox existed, but the primary email address associated with it was the tenant’s onmicrosoft.com address rather than the custom domain address. Incoming mail sent to the custom domain address was being rejected because the Exchange Online routing could not match it to an active mailbox.

 

We corrected the primary SMTP address assignment, ensured that the custom domain email address was set as the primary reply address, and verified mail flow in both directions. The user began receiving queued emails within minutes.

Step 5: Resolving the Mobile App Login Error

The most technically interesting issue was the one affecting a user who could not log into the Outlook mobile app on their iPhone. The error message — “unauthorized_client: The client does not exist or is not enabled for consumers” — was misleading because it suggested an application registration problem in Azure, which would typically be an issue for developers, not end users.

 

After confirming that the user’s Microsoft 365 E3 license was fully assigned with all services enabled, we investigated whether a consumer Microsoft account existed using the same email address. This is a surprisingly common problem. If someone at any point in the past used their work email address to sign up for a personal Microsoft service — such as Skype, Xbox Live, a personal OneDrive account, or even a free Outlook.com account — Microsoft’s identity system creates a consumer account tied to that email address.

 

When a Microsoft 365 admin later adds the same domain to a business tenant and creates a work account with that email address, a collision occurs. The Outlook mobile app attempts to authenticate the user, discovers both a consumer account and a work account associated with the same email address, and fails with the unauthorized_client error because it cannot resolve the ambiguity.

 

The fix involved accessing the personal Microsoft account through account.live.com, adding an alternative email address as a new alias, promoting that alternative address to the primary alias, and then removing the work email address from the personal account entirely. After allowing time for Microsoft’s identity systems to propagate the change, the user was able to log into the Outlook mobile app on their iPhone without any further errors.

 

Lessons for Businesses Considering Email Migration

This case illustrates several important lessons that any business should keep in mind when migrating between email platforms.

 

The first and most critical lesson is to always create a complete backup before migrating. Every email, every calendar entry, every contact should be exported and stored independently before any DNS changes are made. Email migration is not the kind of operation where you can afford to figure things out as you go. Once MX records are changed and the old platform is decommissioned, historical data can become permanently inaccessible.

 

The second lesson is that DNS changes must be clean and complete. A half-migrated DNS configuration is worse than no migration at all. When switching from Google Workspace to Microsoft 365 or vice versa, every DNS record belonging to the old platform must be identified and removed before the new platform’s records are put in place. Leaving old SPF, DKIM, or CNAME records in place does not just create clutter — it actively breaks email authentication, service discovery, and client autoconfiguration.

 

The third lesson is to always check for consumer Microsoft account conflicts before adding a custom domain to a Microsoft 365 tenant. If any of your users have ever used their work email address for personal Microsoft services, those consumer accounts need to be cleaned up before the business account is created. Failing to do this will result in authentication failures that are extremely difficult to diagnose without specific knowledge of how Microsoft’s identity resolution works.

 

If your company is setting up new computers and configuring Microsoft 365 for the first time, getting the initial configuration right from day one will save you from exactly these kinds of problems down the road. A clean setup with proper DNS, licensing, and account provisioning is the foundation that everything else depends on.

 

Why Choosing the Right IT Support Provider Matters

The client in this case spent time and money on two separate technicians before reaching out to IT Tech 4 All. Both of those technicians had the opportunity to resolve these issues but lacked the systematic diagnostic approach needed to identify and address the root causes.

The difference between effective IT support and ineffective IT support is not about knowing more commands or having fancier tools. It is about methodology. When we approach a problem, we start by understanding the complete environment before we touch a single setting. We audit DNS records, license assignments, mailbox configurations, identity conflicts, and service provisioning status. Only after we have a complete picture do we begin making targeted changes, and we verify each change before moving on to the next.

 

This case required expertise spanning DNS management, Microsoft 365 administration, Exchange Online configuration, Azure Active Directory identity resolution, SharePoint Online provisioning, and mobile client troubleshooting. It required understanding how all of these systems interact with each other and how a misconfiguration in one layer can create symptoms that appear in a completely different layer.

 

The client walked away from our service call with every issue resolved: Teams calendar syncing correctly across all devices, file attachments working in Teams meetings and channels, full email send and receive capability restored for the affected user, and successful Outlook mobile app authentication on the user’s iPhone.

 

Is Your Business Experiencing Microsoft 365 Issues?

If your company is dealing with Microsoft 365 problems — whether it is email delivery failures, Teams not working properly, calendar sync issues, or login errors on mobile devices — do not let unqualified technicians make things worse. These problems have specific technical causes, and they require specific technical solutions.

 

IT Tech 4 All provides remote IT support across Dubai for businesses of all sizes. Whether you need help with a complex migration recovery like the case described in this article, or you simply need someone to properly configure Microsoft 365 for your team, we bring the diagnostic rigour and technical depth that gets problems solved right the first time.

 

Call us today at 055-3774571 or WhatsApp us anytime for a consultation. We will diagnose your issue, explain what is happening in plain language, and fix it properly — so you never have to deal with the same problem twice.

 

IT Tech 4 All — Tech Passionate. Customer Driven. Based in Deira, Dubai. Serving businesses across the UAE with onsite and remote IT support since 2009.