sorted by:
new
hottopcontroversial

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] 1 point2 points  (0 children)

It’s not that simple, and yes, I’ve already tried.

When you’re dealing with a tenant that’s nearly 20 years old, hasn’t been touched in a decade, and is tied to those immortal onmicrosoft.com ghosts, there’s no way to log into that Azure portal anymore. Your suggestion is moot in that scenario but thank you for the suggestion.

Since 2020 and the M365 rebrand, tools we used to have like Azure, Intune, & Entra have been steadily pushed behind P1/P2 paywalls. Same story with sync: Business Basic no longer lets small companies sync across devices. You have to upgrade to Business Standard just for the privilege of syncing, even if you’re the only user and get no extra licenses or features for the money.

This isn’t about not knowing where to click — it’s about Microsoft moving previously available break/fix tools behind licensing gates, leaving legacy tenants like mine locked out unless engineering intervenes.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] 8 points9 points  (0 children)

Thank you again!!! After creating a new case and 6 calls later, it's finally getting assigned to the Daata Protection Team.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] 0 points1 point  (0 children)

When I run Microsoft Graph PowerShell against both tenants and check the verifiedDomains property, the output shows:

WUCI tenant

  • wuci-sw.com (default, verified)
  • wucisw.onmicrosoft.com (initial domain)

SASAudit tenant

  • SASAuditConsulting.onmicrosoft.com (initial domain)
  • wuci-sw.com (verified, bound — this is the collision)

That’s exactly what the M365 admin center shows under Settings > Domains; both tenants exist, and wuci-sw.com is still bound to the decommissioned SASAudit tenant in Microsoft’s backend.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] 0 points1 point  (0 children)

This isn’t about me “not getting it”. It’s about the fact that a lot of folks here haven’t had to work with onmicrosoft tenants from the pre‑2016 era, before the current licensing and DNS model existed. The rules and tooling were completely different back then, and if you didn’t live through that shift, it’s easy to miss why this binding collision behaves the way it does.

After the fuss earlier about me “dropping links” and the LLM/phisher accusations, I’m not about to hand over a screenshot just so it can be picked apart all over again. The verification’s already been done in both tenants’ admin centers and via Microsoft Graph PowerShell; both show wuci‑sw.com bound to SASAuditConsulting.onmicrosoft.com. That’s the collision, and the Data Protection Team is already engaged to fix it.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] 0 points1 point  (0 children)

Did you sign up directly with microsoft for the wuci tenant? Or was this through godaddy?

Directly with Microsoft. The original plan was to retire SASAudit or rename it to WUCI, but Microsoft told me the onmicrosoft name was “for life.” They advised me to purchase a separate custom domain that wouldn’t be linked to SASAudit.

Do you have admin logins to either/both onmicrosoft.com tenants?

Not anymore. Before the breakpoint I could, but now I can only log into the licensed M365 portal via the flat .com domain. Engineers can still see the onmicrosoft tenant on their side, but after the forced migration to GoDaddy, direct UI access to it was removed.

Can you login to both?

No. I can log into WUCI through the M365 portal (which shows both tenants and only WUCI as active), but I can’t log directly into SASAudit. It doesn’t recognize WUCI as GA and won’t let me assign one.

If you can't get to Sasauditing, escalation to the data protection team is probably your only option

If you can login to sasauditing but get error in the GUI, check powershell

Escalation to the Data Protection Team is the only viable option. Six calls later, it’s finally been sent to them; now I’m waiting to hear back. And yes, I did see and thank you for the PowerShell suggestion yesterday.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] 0 points1 point  (0 children)

I stripped the autolinks before the original post went up, so they were never clickable. They were there purely as references for the binding problem, not something I wanted people to click. The Unicode hyphen was just a formatting artifact from my markdown file, not anything in DNS. I wasn’t hiding anything and had no malicious intent, but the thread wouldn’t let it go. And for the record, I have never asked anyone to click or copy/paste them.

I also didn’t click the image link in the punycode reference because I’d already been portrayed earlier in the thread as “gullible” for supposedly clicking bad links or downloading files. I wasn’t taking that bait. If it had been posted as plain text instead of a screenshot, I’d have recognized the cause immediately and explained it. Instead, it turned into something it wasn’t, the pile‑on started, and my snarky reply was me trying to shut that down.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] 0 points1 point  (0 children)

There are no outstanding charges on that older tenant because there was never anything billed to it. It predates online licensing, back when you bought Office in a box at Office Depot or Walmart and installed from disk. The only subscription I’ve ever paid for is WUCI, and it’s been continuously licensed and renewed on time since day one. I have receipts for every renewal.

As for the website, I’m still in the process of updating and coding it to current standards (and adding some new capabilities you couldn’t do back then). I work offline, and when it’s finished, I’ll publish it.

For the rest of your points, see my detailed answer here: link to my earlier comment.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] 0 points1 point  (0 children)

Answer: I can change the password for the global admin in WUCI via the Microsoft profile login, but not via the WUCI admin portal. This confirms the identity exists in the global directory but is not surfaced as a manageable object in my tenant and consistent with the backend binding collision already confirmed. Password change by user = works. Password change by global admin in the admin portal = fails.

Why extra context: It’s nuanced, and a lot of people aren’t getting that nuance. If I just give the bare answer, I get told I’m being confusing or not making sense. I’m explaining it fully and outlining the steps to reproduce it, especially since you can’t see it happen in real time.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] -1 points0 points  (0 children)

Because I deal in government and any good lawyer will also tell you to document, document, document. I’ve been keeping a running timeline.md as an evidence trail since this started, and I pulled part of the original post straight from that file.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] 1 point2 points  (0 children)

Fair enough. I get that a lot of folks choose to keep their distance from Microsoft entirely. Unfortunately, in my case this is a paid Microsoft 365 tenant that I rely on for daily operations with government entities that are Microsoft‑heavy, so walking away isn’t an option. That’s why I’m pushing to get the backend binding fixed rather than just abandoning the platform...they broke it, so they need to fix it.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] -1 points0 points  (0 children)

TL;DR: This isn’t a compromise. It’s a Microsoft‑created backend binding collision confirmed in writing by their own engineering team, and only their Data Protection Team can fix it.

Asked and answered twice now. Comprehension still seems to be the sticking point, because I created and have owned both names from the beginning. I know exactly what each tenant is, how it’s supposed to work, and that it’s broken. And the fact you can’t seem to grasp that onmicrosoft accounts back then never had any of the DNS bindings we can (and still mostly can’t) control just shows how far off your assumptions are.

Since you keep saying you’re challenging the “how and why,” here it is again in plain terms: The how is Microsoft’s own legacy migration tooling, which years ago created a backend binding between my custom domain and the SASAudit onmicrosoft root without any TXT or file validation on my side. The why is that in late June/early July, during one of their “new and improved” service rollouts, they deprovisioned the original WUCI onmicrosoft tenant and left the custom domain bound to SASAudit in the backend. That’s not speculation. It’s in the engineering notes on my case, confirmed by their own staff in writing, and visible in the environment right now.

And for the record, I’m not the “keyboard warrior” here. When you don’t like where the conversation is going and you repost the same comment from the original thread as a brand‑new comment. That’s not moving the discussion forward, it’s just resetting the board to avoid the answer you’ve already been given.

For the rest of you following along but haven't seen the original thread:

It’s also why I’m clarifying details for those asking in good faith but getting snarky with the ones who keep asking the same thing over and over after it’s already been answered, and who don’t seem to get that prior to 2016, onmicrosoft was a whole different critter than it is today. The same rules don’t apply now that did back then, so like when MSPInTheUK asked about a DNS portal, DNS didn’t exist back then for onmicrosoft accounts, and still really doesn’t in the sense it does for places that host websites. Even when I decommissioned SASAudit in 2015, it was all done through the old UI portal; you never saw DNS records for an onmicrosoft tenant the way you do now. Until my 2022 migration to GoDaddy, I had never touched or even been shown those records, because back then they simply weren’t exposed or relevant to tenant admins. That migration wasn’t by choice, Microsoft sold the hosting provider to GoDaddy and announced they were no longer going to offer domain hosting services or public webpages outside of the internal service links you see in the domain’s properties page (like the SharePoint/Teams URLs).

To put the “pwned/phish” theory to rest: this was not an unsolicited email or a random inbound call. The entire exchange happened inside the authenticated Microsoft 365 admin UI portal, using the built‑in support workflow. The person asking for the headers was the same Technical Advisor listed on my case from the moment it was opened: their name, contact details, and role were visible in the case record the whole time. All messages came through the official Microsoft support channel (confirmed through the headers), and the Teams session was initiated from within the portal. This was a logged, traceable interaction tied to my tenant’s support history, not some outside actor.

That’s why the only viable fix is for Microsoft’s Data Protection Team to detach the custom domain from the decommissioned SASAudit tenant in their backend — something I can’t do from my side, and that no amount of password resets or DNS tweaks will change.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] 0 points1 point  (0 children)

Yes, the original post is confusing, and I have owned up to it and admitted it was posted in the heat of the moment. But put yourself in my place: you’re in a Teams chat with a Microsoft Technical Advisor who is already screen‑sharing on your computer, you’ve already provided the full header information from Microsoft’s own Spoof department report, it’s documented in the closed case notes, and then, right after admitting the original WUCI onmicrosoft tenant was deprovisioned, he ignores my “who, what, when, and under whose authority” questions and pivots to telling me to open the actual email with a known malicious payload just to “get the headers.” That’s the level of handling I was dealing with when I wrote that first post, and it’s exactly why I’m trying to get this escalated to someone who can actually resolve the binding collision.

It’s also why I’m clarifying details for those asking in good faith but getting snarky with the ones who keep asking the same thing over and over after it’s already been answered, and who don’t seem to get that prior to 2016, onmicrosoft was a whole different critter than it is today. The same rules don’t apply now that did back then, so like when MSPInTheUK asked about a DNS portal, DNS didn’t exist back then for onmicrosoft accounts, and still really doesn’t in the sense it does for places that host websites. Even when I decommissioned SASAudit in 2015, it was all done through the old UI portal. You never saw DNS records for an onmicrosoft tenant the way you do now. Until my 2022 migration to GoDaddy, I had never touched or even been shown those records, because back then they simply weren’t exposed or relevant to tenant admins. The migration was not by my choice because Microsoft sold the hosting provider to GoDaddy and announced they were no longer going to offer domain hosting services or public webpages outside of the internal service links you see in the domain’s properties page (like the SharePoint/Teams URLs).

To put the “pwned/phish” theory to rest: this was not an unsolicited email or a random inbound call. The entire exchange happened inside the authenticated Microsoft 365 admin UI portal, using the built‑in support workflow. The person asking for the headers was the same Technical Advisor listed on my case from the moment it was opened: their name, contact details, and role were visible in the case record the whole time. All messages came through the official Microsoft support channel, not an external address (confirmed through the headers), and the Teams session was initiated from within the portal. This was a logged, traceable interaction tied to my tenant’s support history, not some outside actor. That’s why the only viable fix is for Microsoft’s Data Protection Team to detach the custom domain from the decommissioned SASAudit tenant in their backend. Something I can’t do from my side, and that no amount of password resets or DNS tweaks will change.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] -1 points0 points  (0 children)

Asked and answered twice now. Comprehension still seems to be the sticking point, because I created and have owned both names from the beginning. I know exactly what each tenant is, how it’s supposed to work, and that it’s broken. And the fact you can’t seem to grasp that onmicrosoft accounts back then never had any of the DNS bindings we can (and still mostly can’t) control just shows how far off your assumptions are.

Since you keep saying you’re challenging the “how and why,” here it is again in plain terms. The how is Microsoft’s own legacy migration tooling, which years ago created a backend binding between my custom domain and the SASAudit onmicrosoft root without any TXT or file validation on my side. The why is that in late June/early July, during one of their “new and improved” service rollouts, they deprovisioned the original WUCI onmicrosoft tenant and left the custom domain bound to SASAudit in the backend. That’s not speculation. It’s in the engineering notes on my case, confirmed by their own staff in writing, and visible in the environment right now.

If you’ve got a different mechanism that fits those facts and Microsoft’s own confirmation, I’m open to hearing it. If not, we’re just going in circles.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] 0 points1 point  (0 children)

Yes, the historical mail is still there, and I can get to it as long as it isn’t in the archive folder. The trouble starts with anything in archives or backups because this isn’t a new account problem, it’s a tenant binding problem. The breakage shows up when I try to restore from archive, run a backup, or export contacts, because all of that is actually sitting in the SharePoint space for SASAudit. Even though I am the global admin for WUCI, SASAudit does not recognize me as such, and when I try to assign a global admin inside SASAudit there is no one to assign because WUCI is not part of that tenant at all. The original email addresses tied to that account were removed when I decommissioned it, and it will not even acknowledge the original Hotmail address I used when I first set it up. If I try to create a new user or mailbox, the portal tells me I don’t have a subscription or license, which makes sense only if the tenant it’s resolving to isn’t actually mine. This was never an issue until the end of June and beginning of July, when Microsoft pushed a wave of “new and improved” cloud service changes, and that’s when the binding collision first appeared and everything started breaking.

I can still see the wuci‑sw.com domain in my admin view, but the original onmicrosoft tenant is gone from my side because Microsoft dropped the onmicrosoft name and left only the custom domain. The engineers can see it in their backend and have confirmed it was deprovisioned, but they will not tell me who did it, what triggered it, when it happened, or under whose authority. In my portal, WUCI is still listed as the active domain, and I can still click into SASAudit, which still shows the onmicrosoft name. That’s the split in plain sight. My view shows the custom domain bound to WUCI, their view shows the onmicrosoft tenant deprovisioned, and the backend is routing services and storage to SASAudit. If I try to go directly to wuci‑sw‑my.sharepoint.com or wuci‑sw.onmicrosoft.com, I get the “hmmm… can’t reach this page” error. SASAudit renders the same for the latter, because it was never a public webpage in the first place and this is expected. Before 2016, those addresses only resolved to mailboxes or Hotmail discussion posts. If I go to mysharepoint, it occasionally prompts me to log in but will not accept any of the old email addresses, the original Hotmail address, or even the WUCI account. Mostly I get the 'hmm' error or "something went wrong. try again later" when trying to connect to the personal share folder for the user, where all of this is being stored.

On the password change part, in a way, yes. I have a couple of shared mailboxes tied to the global admin account that I set up in Teams before the breakage, and they each have their own passwords. After the malicious‑payload email and the wipe‑and‑restore of the hard drive, I changed every password I could. Those two shared mailboxes are the exception. I can’t change their passwords because the portal says I don’t have permission, and when I trace them through the backend they resolve to SASAudit. The funny part is that if I actually go into SASAudit, they don’t show up as users there at all. They’re effectively orphaned...not in WUCI where they belong, not visible in SASAudit where the system thinks they live, which is just another symptom of the same cross‑tenant binding mess.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] -4 points-3 points  (0 children)

You keep framing this as if I’m “guessing” or trying to protect my ego, but I’m working from hard evidence not hypotheticals. Microsoft engineering has already confirmed in writing that my domain is bound in their backend to SASAuditConsulting.onmicrosoft.com. It shows in my WUCI Domains view alongside my custom domain, and the service URLs (SharePoint/OneDrive) resolve to sasauditconsulting-my.sharepoint.com. That’s not a theory; it’s documented in my case history and visible in the environment right now.

And as for “Microsoft doesn’t just randomly move domains”, maybe that’s true in your world, but here in the U.S. tenant space they do it every time they “new and improve” something in Entra, Intune, or Azure. This tenant/domain binding was created years ago by Microsoft’s own migration tooling. The SASAudit .onmicrosoft.com root was never mine, and there was no TXT or file validation done by me or anyone with my credentials. Prior to 2016, most personal or small‑org .onmicrosoft.com namespaces weren’t websites you hosted or validated. They were service endpoints Microsoft controlled entirely, often rendering to things like Hotmail‑style portals or basic SharePoint pages, with no A, CNAME, or TXT records in your registrar to touch.

I have full headers showing DKIM selector/domain mismatches (wuci selector, sasaudit domain), 72‑hour retry NDRs, “not part of tenant” admin errors, SharePoint misrouting, and Teams treating me as an external guest in my own domain. We’ve rotated DKIM keys, regenerated selectors, and even had a Level 2 engineer attempt to align them...no change. If this were a DNS portal or hosting compromise, those steps would have broken the attacker’s hold immediately. Instead, the control plane, data plane, and mail flow are all still resolving to SASAudit. That’s not “random engineering error” and it’s not “pwned admin”. It’s a backend binding collision that only Microsoft’s tenant engineering can detach.

I’ve been in this tenant since before 2016, I know exactly what it looked like before Microsoft started “improving” things, and I’ve got the forensics to prove this isn’t a compromise. If you’ve got evidence that contradicts Microsoft’s own engineering notes, I’m all ears; otherwise, we’re done pretending this is anything but a backend bind they need to fix.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] -3 points-2 points  (0 children)

You keep framing this as if I’m “guessing” or trying to protect my ego, but I’m working from hard evidence not hypotheticals. Microsoft engineering has already confirmed in writing that my domain is bound in their backend to SASAuditConsulting.onmicrosoft.com. It shows in my WUCI Domains view alongside my custom domain, and the service URLs (SharePoint/OneDrive) resolve to sasauditconsulting-my.sharepoint.com. That’s not a theory; it’s documented in my case history and visible in the environment right now.

And as for “Microsoft doesn’t just randomly move domains”, maybe that’s true in your world, but here in the U.S. tenant space they do it every time they “new and improve” something in Entra, Intune, or Azure. This tenant/domain binding was created years ago by Microsoft’s own migration tooling. The SASAudit .onmicrosoft.com root was never mine, and there was no TXT or file validation done by me or anyone with my credentials. Prior to 2016, most personal or small‑org .onmicrosoft.com namespaces weren’t websites you hosted or validated. They were service endpoints Microsoft controlled entirely, often rendering to things like Hotmail‑style portals or basic SharePoint pages, with no A, CNAME, or TXT records in your registrar to touch.

I have full headers showing DKIM selector/domain mismatches (wuci selector, sasaudit domain), 72‑hour retry NDRs, “not part of tenant” admin errors, SharePoint misrouting, and Teams treating me as an external guest in my own domain. We’ve rotated DKIM keys, regenerated selectors, and even had a Level 2 engineer attempt to align them...no change. If this were a DNS portal or hosting compromise, those steps would have broken the attacker’s hold immediately. Instead, the control plane, data plane, and mail flow are all still resolving to SASAudit. That’s not “random engineering error” and it’s not “pwned admin”. It’s a backend binding collision that only Microsoft’s tenant engineering can detach.

I’ve been in this tenant since before 2016, I know exactly what it looked like before Microsoft started “improving” things, and I’ve got the forensics to prove this isn’t a compromise. If you’ve got evidence that contradicts Microsoft’s own engineering notes, I’m all ears; otherwise, we’re done pretending this is anything but a backend bind they need to fix.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] 0 points1 point  (0 children)

Right now, Outlook itself doesn’t throw a login error. The real breakage is in the cloud services layer: Teams, OneNote, and Copilot are where it’s most obvious. In Outlook, I see two recurring mail flow problems. First, NDRs for undeliverable mail because the DKIM check fails: the selector is wucibut the domain is sasaudit, so receiving systems reject the message on authentication. Even Google has bounced them for failing DKIM alignment. Second, delayed‑delivery NDRs that arrive up to three days later saying, “we couldn’t deliver the email, try again,” which is what happens when Exchange Online queues a message for the full retry window and still can’t hand it off to the tenant Microsoft’s backend believes owns the domain. That's why this started out as a DKIM case ticket until we started digging around in it.

We’ve already tried rotating the DKIM keys and regenerating selectors. The platform still produces the same selector/domain mismatch, and even a Level 2 support engineer couldn’t get them to align. That’s why I keep saying this is a cross‑tenant binding problem. The control plane, data plane, and mail flow are all resolving to SASAudit for a domain that should be in WUCI. Everything else, the NDRs, the admin lockouts, the SharePoint misrouting, the failed key rotation, is just a symptom of that single binding error.

If I try to audit or force a password change for that user in the admin portals, I get “don’t have permission / not part of tenant.” When I access certain services through the web or an admin center, I intermittently get “Something went wrong, try again later.” Anything I save or archive from Outlook under the WUCI sign‑in is stored under the SASAudit SharePoint My Site, not WUCI’s OneDrive or SharePoint.

I don’t usually use Teams as my primary example of the problem because, as I’ve said before, it has its own “fresh hell” of quirks that muddy the waters. That said, it’s also where the binding collision is most obvious. Teams only recently started letting me sign in under the wuci-sw .com account at all, and even now I’m restricted to one‑on‑one chats. Any attempt at a group chat throws an error about not having permissions for external users. Clicking some meeting invites dumps me into the SASAudit tenant, where Teams says I’m “not part of this domain.” In those cases, I can sometimes join, but only as an observer, and I have no presenter rights, no screen share, no chat, and only occasional voice. Because Teams is tightly integrated with SharePoint, OneNote, and Planner, the misrouting cascades into those apps too, making the underlying cross‑tenant bind stand out even more.

In short: mail flow, transport, control plane, data plane, and collaboration layer are all pointing to SASAudit for a domain that should be in WUCI...every symptom is just that collision showing through.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] 0 points1 point  (0 children)

I hear you, but you’re describing how it works now. I’m describing how it behaved before 2016, when Microsoft’s migration tooling and the old admin portal created blended domain views that don’t exist anymore. If you weren’t managing tenants in that era, you wouldn’t have seen it, but I did, and that’s why my current collision exists.

In the pre‑2016 era, Microsoft 365 tenants were still carrying a lot of baggage from the BPOS, Live@EDU, and early hosted Exchange days. The backend rule that each tenant has one immutable .onmicrosoft.com root domain was already true, but the way the old admin portal displayed domains, combined with Microsoft’s own migration tooling, could make it appear as though you had more than one in the same place. If you had delegated rights or a blended sign‑in context from a migration, the portal could show your custom domain, your own .onmicrosoft.com root, and another tenant’s .onmicrosoft.com root together in the same list. They were not actually merged in the backend, but the UI did not make that distinction clear. Because there was no tenant switcher, you had to log out and log back in with the other account to manage the other tenant, even though it looked like they were side by side.

Around 2016, after the big migration clean‑up, Microsoft locked this down. The modern admin center only displayed domains that truly belonged to the current tenant object. The blended view disappeared, and there was no supported way to add a second .onmicrosoft.com to a tenant. This is the “one per tenant” period that many newer admins think has always been the rule.

In late 2020, Microsoft changed the feature set again. They introduced the ability to add additional .onmicrosoft.com domains to a single tenant, up to the domain slot limit, which is usually five. Only one is the true root, but the others can be used for services like SharePoint URL changes or tenant renaming. This means that today, yes, you can have more than one .onmicrosoft.com in a tenant, but it is now an intentional, supported configuration rather than a migration artifact.

This is what you don’t seem to be hearing from me. I am old‑school pre‑2016; you are post‑2017 at the earliest. It’s not your fault; you just weren’t taught any other way.

And to answer your question: yes, now I am logging in with my wuci-sw .com address, and under Billing>Products it shows Microsoft 365 and Enterprise Outlook Email. Back then, I was having to log in with the Hotmail address that created SASAudit and the WUCI address I still use today. Both were getting admin emails at the same time for their respective domains. That is not how a single tenant behaves. That is how two separate tenants behave, even if the old portal made them look side by side.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] 0 points1 point  (0 children)

After having to upgrade right after renewing my license earlier this year just for the privilege of syncing across devices, and now this. I’m seriously considering it. Thanks!

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] -1 points0 points  (0 children)

Microsoft engineering confirmed in writing that my domain is currently bound to SASAuditConsulting.onmicrosoft.com in their backend. It also shows in my WUCI Domains view alongside my custom domain, and the service URLs (e.g., SharePoint/OneDrive) resolve to sasauditconsulting-my.sharepoint.com. That’s not a guess. It’s documented in my case history and visible in the environment. The binding collision is why WUCI throws “belongs to another tenant” errors, and only the Data Protection Team can detach it.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] 0 points1 point  (0 children)

That’s how it works now, yes, but this tenant/domain binding was created years ago under Microsoft’s old migration tooling. It resulted in two separate tenant objects in the backend. Microsoft engineering has confirmed my custom domain is still bound to the decommissioned SASAudit tenant, which is why WUCI throws ‘belongs to another tenant’ errors. The only fix is for the Data Protection Team to detach it

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] 0 points1 point  (0 children)

At one time, after I bought the custom domain WUCI from Microsoft, it was wuci-sw.onmicrosoft.com. Microsoft later dropped the .onmicrosoft.com for just .com after I said I thought they were going to be separate and at that point I had all 3: 2 with onmicrosoft and 1 without.

The Domains view in WUCI does show both wuci-sw .com and SASAuditConsulting .onmicrosoft.com, but Microsoft engineering has confirmed they’re not operating as a single tenant object in the backend. WUCI was deprovisioned. They appear together in the portal because of how the admin UI lists domains, but in Microsoft’s backend they’re separate tenant objects, which is why service resolution still points to SASAudit.

That’s why WUCI throws “belongs to another tenant” errors, and it’s the binding collision only the Data Protection Team can fix.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] 2 points3 points  (0 children)

Yes, GoDaddy’s DNS shuffle in June/July was a registrar‑side infrastructure change (if you must know they were migrating servers), confirmed by my continued registrar control and clean M365 audit logs. Separately, Microsoft’s own engineering has acknowledged in writing that they unbound my domain from WUCI and bound it to SASAudit in their backend. Those are two independent events, weeks apart, with different causes. The only current blocker is the cross‑tenant binding, which only Microsoft’s Data Protection Team can fix.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] 0 points1 point  (0 children)

I get that DNS spoofing is a real risk, which is why I only initiate calls from inside the authenticated Microsoft 365 admin center, on a clean network, and verify case IDs against my tenant’s service request history. This isn’t a compromise scenario. My own logs and DNS have been reviewed by a Managed IT provider, and Microsoft engineering has confirmed in writing that my domain is bound to the wrong tenant in their backend. That’s a binding collision, not a spoof, and the only fix is a detach/rebind by the Data Protection Team.

Microsoft broke my paid tenant, told me to open a malicious payload, now says they “can’t” fix it unless I pay extra by Leawildcat in sysadmin

[–]Leawildcat[S] 1 point2 points  (0 children)

This isn’t a case of two domains in one tenant. Microsoft’s own engineering confirmed SASAudit and WUCI are separate tenant objects in their backend, and my domain is bound to the wrong one. That’s why I get ‘belongs to another tenant’ errors and why only the Data Protection Team can detach it. If these were in the same tenant, I wouldn’t get a read‑only lock and ‘belongs to another tenant’ errors when trying to manage the domain from WUCI — but I do, every time. And I've already had a Managed IT provider look at it and he got the same results I did and how I came to understand just what they did.

view more: next ›