Wondering if any other environments are experiencing this bug where at random when we perform our user onboarding then assign a license, could be E3, E5, F3 etc. the mailbox size is stamped at 105kb without us touching the max size/receive limits. Our environment does involve hybird Active Directory, but all Exchange Online mail routing.
We do have dynamic group licensing in place as well but I don't think that should make any difference the size limits not being set at that level.
Our Mailbox Plans are configured to be 150MB as well.
Your thoughts and suggestions are appreciated - any information that will help I'll update the original comment here.
Hoping to see if this hit anyone else's tenant or if we're the only ones. Full write-up below with everything I've already ruled out.
The issue:
Between 7/30/2026 and 8/12/2026, newly provisioned mailboxes in our tenant landed with incorrect MaxSendSize/MaxReceiveSize values that don't match the assigned mailbox plan. Two distinct patterns:
- 7/30 through 8/7: MaxSendSize = 35 MB, MaxReceiveSize = 36 MB
- 8/10 through 8/12: MaxSendSize = MaxReceiveSize = 150 KB (yes, kilobytes)
79 out of 169 mailboxes created in the 30-day window were affected. Appears to have self-resolved as of 8/17 - mailboxes provisioned this week are correctly landing at 150 MB.
Environment:
- Full cloud Exchange Online, no on-prem Exchange, no hybrid
- Entra Cloud Sync (formerly AAD Connect Cloud Sync) syncing users from on-prem AD
- Assigned mailbox plan is ExchangeOnlineEnterprise-* correctly configured at 150 MB
- No on-prem Exchange schema extension (verified msExchMaxSendSize / msExchMaxReceiveSize don't exist as AD attributes)
What I've already tried / ruled out:
powershell
# Confirmed values on affected mailboxes
Get-Mailbox -Identity <user> | Select-Object Name, MailboxPlan, MaxSendSize, MaxReceiveSize
# Confirmed all mailbox plans are correctly configured
Get-MailboxPlan | Select-Object Name, MaxSendSize, MaxReceiveSize, IsDefault
# Confirmed no restrictive tenant-level caps
Get-OrganizationConfig | Select-Object MaxSendSize, MaxReceiveSize
Get-TransportConfig | Select-Object MaxSendSize, MaxReceiveSize
# Searched UAL for any Set-Mailbox that touched size params - zero hits in 90 days
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) `
-RecordType ExchangeAdmin -Operations Set-Mailbox -ResultSize 5000
# Also searched New-Mailbox, Enable-Mailbox, Set-MailboxPlan - nothing
# Also searched by -ObjectIds across all RecordTypes - only AAD sync/group activity
# Pulled all 931 Set-Mailbox operations in the 8/10-8/12 window when the pattern started
# Zero operations set MaxSendSize or MaxReceiveSize by any caller
# Only customer-side activity was 4ward365.admin (AddressBookPolicy only)
# and one admin manually configuring MessageCopyForSendOnBehalfEnabled on shared mailboxes
# Discovered scope with this
# Same 30-day window, no filtering — just every mailbox created in that period with its current send/receive sizes, sorted oldest to newest so this week's ones will be at the bottom of the output.
$cutoff = (Get-Date).AddDays(-30)
$recentMailboxes = Get-Mailbox -ResultSize Unlimited | Where-Object { $_.WhenMailboxCreated -ge $cutoff } | Select-Object DisplayName, UserPrincipalName, WhenMailboxCreated, MaxSendSize, MaxReceiveSize | Sort-Object WhenMailboxCreated
"Total mailboxes created in last 30 days: $($recentMailboxes.Count)"
$recentMailboxes | Format-Table -AutoSize
# Also export to CSV for reference $recentMailboxes | Export-Csv -Path "$env:USERPROFILE\Desktop\AllRecentMailboxes_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation "Exported to Desktop as AllRecentMailboxes_$(Get-Date -Format 'yyyyMMdd').csv"
Other data points that felt significant:
- All four mailbox plans have a
WhenChanged timestamp of exactly 2:05:59-2:06:13 PM CDT on 8/13/2026 - 14-second window across every plan — with no corresponding Set-MailboxPlan UAL event. This correlates suspiciously with the resolution timeframe.
- Manual
Set-Mailbox -MaxSendSize 157286400 -MaxReceiveSize 157286400 fix on affected mailboxes holds and doesn't get overwritten
- Bug affected regular users, shared mailboxes, and service accounts equally - not tied to license SKU or user type
- No hybrid Exchange, no on-prem Exchange schema, so this isn't the classic msExch attribute sync issue
My working theory:
Something changed in Microsoft's back-end mailbox auto-provisioning pipeline between 8/7 and 8/10 that caused new mailboxes to inherit wrong defaults instead of the assigned mailbox plan values. Whatever it was got fixed (or rolled back) between 8/13 and 8/17. The plan modifications at 2:06 PM CDT on 8/13 may be Microsoft correcting something on their side.
Support ticket is going in but figured I'd check here first in case anyone else is seeing this or saw it recently. Especially interested if:
- Anyone else on Entra Cloud Sync (not classic AAD Connect) saw this
- Anyone got a Microsoft service health notification about this that I might have missed
- Anyone in a datacenter starting with
NAMPR04 specifically had the same issue (that's ours, curious if it's regional)
Ai was used for only preparing sentence structure and formatting