Introduction

When a Plesk mailbox still shows the wrong quota after migration, the control panel number is often out of sync with the mailbox that actually exists on disk. The mailbox may have moved successfully, users may be able to sign in, and mail may even flow normally, but quota files, indexes, or mailbox metadata did not rebuild cleanly on the destination server. In other cases, the migrated mailbox really is larger than expected because Trash, Spam, or duplicate folder data came across with it. Start by proving the real mailbox size, then fix the Plesk or mail-service accounting that sits on top of it.

Symptoms

  • A migrated mailbox is shown as over quota immediately after migration
  • Deleting mail does not reduce the quota reading in Plesk
  • The mailbox looks small from mail client folders, but Plesk reports much higher usage
  • Users cannot receive new mail because the quota still appears full
  • Only one migrated mailbox is wrong while other mailboxes update normally
  • The issue started right after mailbox import, server move, or mail migration tool cutover

Common Causes

  • Plesk or the underlying mail service did not rebuild quota metadata after migration
  • Stale Maildir quota files or indexes were copied from the old server
  • The mailbox contains migrated duplicates in Trash, Spam, Sent, or archive folders
  • Ownership or permissions on the mailbox files are incorrect after restore or import
  • The destination mail service uses a different quota backend than the old server
  • The panel view is stale even though the mailbox content already changed

Step-by-Step Fix

  1. Measure the mailbox’s real size on disk or through the mail server view before trusting the Plesk number, because you need to know whether the problem is stale accounting or genuine mailbox growth from the migration.
  2. Confirm the mailbox object in Plesk is attached to the correct domain, mail service, and destination server, because a partial migration can leave the panel record and the real mailbox storage pointing at different places.
  3. Inspect the migrated mailbox folders closely for hidden large data such as Trash, Spam, Sent, archive folders, duplicate imports, or failed migration leftovers, because these folders often explain quota growth that the user did not notice from normal inbox views.
  4. Check whether old quota files, mail indexes, or mailbox metadata were copied from the previous server, because stale accounting files can survive migration and keep reporting the old usage even after the live mailbox changed.
  5. Verify mailbox ownership and permissions on the destination server, because mismatched ownership can prevent the mail service from updating quota information consistently after new mail arrives or old mail is deleted.
  6. Rebuild or refresh the mailbox indexes and quota data using the tools appropriate for the mail service running under Plesk, because a clean recount often fixes quota values that stayed wrong after an otherwise successful import.
  7. Watch the mail service and panel logs while forcing a recount or while testing mailbox activity, because silent rebuild failures can leave the old quota number in place and make it look like Plesk ignored the change.
  8. Compare the updated Plesk quota value with the real mailbox size again after the rebuild, because matching values confirm the issue was accounting-only while a continuing mismatch points to a deeper migration or mail-service problem.
  9. If the mailbox still shows the wrong size after a clean recount, collect the mailbox size, quota setting, mail service type, log output, and any stale quota artifacts you found, because that is the evidence Plesk support or the hosting provider needs to diagnose a quota backend issue.