I recently moved a small nonprofit from a reseller-provisioned Microsoft 365 tenant to their own nonprofit tenant. Same domain, same email addresses, same people — a different tenant underneath.
The mailbox migration was straightforward. What consumed the time was identity: because the same email addresses reappeared in a new tenant, every device that had previously connected fought me.
A note on certainty. Some of what follows is observed — I saw the error, made the change, watched it work. Some is my best explanation for behaviour I couldn’t fully account for. I’ve marked the difference, because a plausible-sounding theory that’s wrong is worse than no theory at all.
The setup
A domain registered at one registrar with DNS there too, website at a separate host, and email in a Microsoft 365 tenant the registrar had provisioned as a reseller. Three user mailboxes plus two role addresses. One mailbox at roughly 48 GB and 200,000 items across a deeply nested folder structure. An Amazon SES configuration for the newsletter. Users on Windows desktops and iPads.
The core problem: reusing addresses in a new tenant
Everything else here is a footnote to this.
When you release a domain from one tenant and verify it in another, the addresses stay the same — that’s the point. But clients that previously authenticated against those addresses have cached something: tokens, credentials, a mapping of address to tenant. When the same address comes back backed by a different tenant, those clients don’t recover on their own.
Observed symptoms:
AADSTS50020: User account ... from identity provider ... does not exist in tenant, where the identity provider GUID in the message was the tenant it claimed the user didn’t exist in- iPads hanging indefinitely on “Verifying,” no error
- Sign-in dialogs flashing “trying to sign you in,” then asking for the password again, repeatedly
- Outlook autodiscover failing with “an encrypted connection to your mail server is not available”
What I verified was fine: domain verified, Managed authentication, set as default, Email in supported services, a single user object with the correct UPN, no guest or duplicate directory records, mailbox healthy, mail flowing both directions.
I opened a Microsoft support ticket for the AADSTS50020 error. On the call, we worked entirely on client configuration — clearing Credential Manager entries and renaming registry keys — rather than anything tenant-side. That turned out to be the right instinct, though I’d have appreciated knowing why at the time.
Theory: the client caches an address-to-tenant mapping and has no path to re-evaluate it when the mapping changes. I never got confirmation of this, and I can’t explain why some clients recovered and others didn’t.
What worked
Windows: reset Office’s configuration wholesale
Targeted fixes didn’t work. Clearing Credential Manager, removing work-or-school accounts, autodiscover registry keys, building fresh profiles — none of it, individually, resolved the sign-in failure.
What worked came out of the support call. With Outlook closed, we renamed these registry keys to append .OLD:
HKEY_CURRENT_USER\Software\Microsoft\Office
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0
Outlook rebuilds everything on next launch — profiles, cached identities, autodiscover state, credentials.
This resets all Office settings for that user account, not just Outlook. It’s a heavy hammer. But nothing narrower worked, and I’d reach for it much earlier next time.
Supporting steps from the same session:
- Credential Manager » Windows Credentials — delete every entry referencing the domain or
MicrosoftOffice16_Data - Settings » Accounts » Access work or school — disconnect any lingering registration to the old tenant
We also deleted a number of folders during the call that I didn’t record and can’t now identify. I mention it because it means I can’t say with certainty that the registry rename alone was sufficient — only that the combination worked. If you’re following this, get the case notes from support while you’re still on the call.
Also useful, earlier on: Test E-mail AutoConfiguration (Ctrl + right-click the Outlook tray icon) is not only a diagnostic. Running it and then adding the account immediately in the same session succeeded where adding the account directly had failed. My theory is that the test caches the autodiscover result and the wizard then reads the cache rather than repeating a failing lookup — inference from the observed sequence, not something I confirmed.
On domain-joined machines, ExcludeScpLookup = 1 under HKCU\Software\Microsoft\Office\16.0\Outlook\AutoDiscover stops Outlook querying Active Directory for stale Service Connection Points before trying Microsoft. I applied this and things later worked, but other changes happened in between, so I can’t say it was necessary.
iPad: trigger the wrong-account error deliberately
This is the counterintuitive one, and the most useful thing I learned.
Entering the correct address in Apple Mail’s Exchange setup produced an endless loop — “trying to sign you in,” flash, password prompt, repeat. No error, no progress.
Entering the .onmicrosoft.com address instead produced an immediate, clean user not found error — and a dialog offering to correct the address. Changing it there to the custom domain authenticated successfully, first time, no loop.
Theory: the error dialog’s retry uses a different code path than the initial setup flow, skipping whatever was looping. I have no way to verify that. What I can say is that it worked reliably and the normal path never did.
Supporting steps on iOS:
- Remove the account from Mail, Calendar, and Contacts separately — the same Exchange account appears in each, and removing it from one doesn’t remove the others
- Check the Passwords app for saved credentials against the address
- Check VPN & Device Management for profiles pushed by the old tenant
- Force restart before retrying
Manual configuration will not work. Basic authentication is permanently disabled in Exchange Online, so entering server details by hand fails with “unable to verify account information.” It has to go through the automatic sign-in handoff.
Three traps worth knowing about
PowerShell sessions stack
Connect-ExchangeOnline adds a session to the process rather than replacing one. Connect three times over an afternoon and you have three sessions, and cmdlets don’t necessarily use the newest.
I hit a stretch where Get-AcceptedDomain listed the custom domain as Authoritative while Set-Mailbox, in the same window, insisted it wasn’t an accepted domain. I lost over an hour assuming backend propagation lag. Closing everything and connecting once fixed it immediately.
Get-ConnectionInformation | Select-Object UserPrincipalName
More than one row means close the window and start over. Don’t use Disconnect-ExchangeOnline — on my machines it crashed the process via the authentication broker.
Module conflicts, and the order differs by machine
The Graph and Exchange Online modules ship different versions of the same MSAL authentication assembly, and .NET loads one per process. Whichever connects first wins; the other may fail with Method not found or a null reference in the identity stack.
One workstation needed Exchange connected first. Another needed Graph first. I found no way to predict which.
- Use PowerShell 7, not Windows PowerShell 5.1
- Use
-UseDeviceCode(Graph) and-Device(Exchange) to bypass the Windows account broker, which crashed repeatedly withRuntimeBrokernull reference exceptions on domain-joined machines - If one order fails, close the window completely and try the other — flags set after MSAL initializes have no effect
Also: Set-MgUserLicense lives in Microsoft.Graph.Users.Actions, not Microsoft.Graph.Users. Installing only the obvious sub-modules leaves you with users created but unlicensed.
Mismatched UPNs break Send As
I created users on the temporary .onmicrosoft.com domain and switched them to the custom domain at cutover. For the two role mailboxes, the SMTP address moved but the UPN didn’t — I’d only scripted the switch for user accounts.
Everything looked right in a mailbox listing. But sending as those addresses failed:
This message could not be sent. You do not have the permission to send the message on behalf of the specified user.
Send As permissions were verified present, repeatedly. Re-granting them returned “already present.” The fix was aligning the UPN with the primary SMTP address, after which it worked immediately.
Theory: Outlook resolved the name through the address book to the old .onmicrosoft.com address and tried to send as an address that was no longer the mailbox’s primary. The bounce mentioning “on behalf of” — a permission I hadn’t granted — supports this, since it suggests Outlook chose a different send method than intended. But I’m reasoning backwards from the fix.
Machines that had already cached the address book kept the stale entry afterwards. Forcing a full address book download and clearing the auto-complete list cleared it.
The large mailbox
The 48 GB mailbox resisted at every step:
- Outlook’s PST limit is enforced by registry values that warn around 47.3 GB and cap at 50 GB
- Exporting into an existing PST appends rather than replaces, so retrying after a failure resumes into a file already at the ceiling
- Importing exhausted Outlook’s resources. My read is that folder count mattered more than total size, since a structure with thousands of small folders behaved far worse than the raw gigabytes suggested — inference from the failure pattern, not measurement
- Upload to Exchange Online is throttled; early measurements suggested days
Emptying Deleted Items removed 18 GB and made everything tractable. It also permanently discarded roughly 58,000 items — a decision that belongs to the mailbox owner, not to whoever is fighting the export.
A server-side migration tool would have avoided all of this. BitTitan or CodeTwo, roughly $15 per mailbox: no local file, no size ceiling, native calendar and contact handling, delta sync at cutover. I didn’t use one because it requires admin credentials on the source tenant, which I didn’t have until late.
DNS: read the records, don’t transcribe them
I scripted the domain setup to pull required DNS records directly from Graph after verification rather than copying them by hand. The MX hostname Microsoft generates strips punctuation from the domain and can carry a collision suffix, producing something that looks like a typo.
(In the event, the MX was identical across both tenants — Microsoft derives it from the domain, not the tenant. I’d expected it to change. Reading it from the API was still the right approach.)
Microsoft’s list of required records includes several you should not add:
- Skype for Business SRV and CNAME records — legacy
msoid— deprecated- Intune enrollment records — only if you enroll devices
- A CNAME at the domain apex for SharePoint — this would break your website if it’s on the same domain
Only the MX, SPF TXT, and autodiscover CNAME are required for mail.
Clean the zone rather than importing it. Mine had 33 records; 19 were fossils. A bulk import would have carried all of them forward.
And check what automated scans miss. The new DNS provider’s scan missed five records, all part of the newsletter’s SES setup — a subdomain and three DKIM CNAMEs with random 32-character labels. Nothing would have guessed those. Losing them would have been quiet and expensive, since SES re-resolves its DKIM records periodically and suspends sending when they stop answering. Diff the scan against an authoritative zone export.
What I’d do differently
Release the domain first, then build on it.
Building users on the temporary domain let me import mail weeks ahead and kept the irreversible step off the critical path. But it meant every account went through a UPN change, and every client had to reconcile an address that had just moved tenants.
Releasing first means no UPN change ever happens — clients see a clean setup rather than a migration. The cost is that nothing proceeds until a release with genuinely unpredictable timing completes. Given how much time the identity artifacts consumed, I’d take that trade.
Reach for the heavy reset sooner. I spent hours on targeted client fixes before the registry rename. Nothing narrower worked on the machines that were stuck.
Establish who holds source-tenant admin on day one. The release requires a global administrator on the old tenant. In a reseller setup that’s often whoever bought the service years ago — someone who may never sign in and may not know their password. It also gates the better migration tooling.
Test on the device you’re supporting. I tested a configuration on an old spare iPad, watched it fail, and reasoned confidently about iOS versions and TLS support. The user’s actual iPad was a current model on a current OS. That detour was entirely self-inflicted.
Budget for the tail. Mail was flowing within hours of cutover. The client-side work took considerably longer and generated far more frustration, because it’s the part users actually experience.
Short version
Migrating mailboxes between Microsoft 365 tenants is straightforward. Migrating identities is not — reusing the same addresses in a new tenant means every previously-configured client has to reconcile something it has no clean way to reconcile.
Reset client configuration aggressively rather than surgically. Verify backups by opening them. Find out who holds source-tenant admin before you start.
And on iOS, if the sign-in loops, try the wrong address first.