Skip to content 99% OFF 🎉 Anniversary Sale 99% OFF Shared Hosting Use Code HURRYUP Claim Offer 99% OFF Hosting
99% OFF Hosting — Code HURRYUP
Products
AI Website Builder New VPS Hosting Cloud Servers Web Hosting cPanel Hosting Dedicated Servers Domains
Company
About Documentation Support Center Contact Get Started Call +91 75795 45488
Login
Hosting Panel — cPanel & Billing Console Panel — VPS Management
ALL SYSTEMS OPERATIONAL
Hosting

cPanel Mailbox Quota Stuck Full After You Clean It Up

Getwebup 6 min read

You emptied Trash, deleted five years of newsletters from an old mailbox, and the usage bar in Email Accounts still says 498 MB / 500 MB. Mail is still bouncing with "quota exceeded." You didn't imagine it — cPanel's mailbox size isn't always a live measurement, and sometimes it stops updating after a big cleanup instead of before one.

Symptom: you deleted the mail, but the number didn't move

This shows up a specific way, and it's worth confirming you're actually looking at this problem before you start digging:

  • You emptied Trash and Junk in webmail (Roundcube or Horde), refreshed, and Email Accounts in cPanel still shows the same usage percentage as before
  • Mail keeps bouncing with 552 5.2.2 mailbox full even though you're certain the inbox is nearly empty now
  • An IMAP client like Outlook shows a nearly empty mailbox, but the server-side quota bar disagrees by hundreds of megabytes
  • Waiting an hour, a day, even logging out and back in doesn't change the number

If the quota bar was accurate before your cleanup and is still accurate now, that's a different problem — see our guide on fixing a genuinely full mailbox instead. This post is specifically for when the number is wrong, not just high.

Cause: cPanel doesn't measure your mailbox live, it reads a cache file

Under the hood, cPanel email runs on Dovecot with the Maildir format. Every message is its own file, split across cur, new, and per-folder directories like .Trash and .Junk. Adding up every file's size on every single login would be slow on a mailbox with tens of thousands of messages, so Dovecot doesn't do that. Instead it keeps a small cache file called maildirsize inside the mailbox's home directory, and updates it incrementally as messages come and go.

That cache is usually reliable, but it can drift out of sync with reality in a few common situations:

What happenedWhy the cache goes stale
A webmail client marks mail "deleted" but doesn't expunge itIMAP's \Deleted flag just hides the message from view — the file stays on disk, still counted, until an actual EXPUNGE runs
Mail was removed by a script or bulk operation outside normal IMAPFiles vanish, but nothing tells Dovecot to update its size cache, so it keeps reporting the old total
A huge cleanup happened all at onceDovecot recalculates the cache incrementally on certain triggers, not instantly on every delete — a very large change can outrun that
The mailbox has a corrupted or half-written maildirsize fileDovecot falls back to whatever number is already in the file instead of a fresh count

None of this is a cPanel bug — it's a deliberate performance trade-off. It just means "the quota bar says full" and "the mailbox is actually full" are two different claims, and after a big cleanup they can disagree for a while.

Fix: confirm the real size, then force a recalculation

Step 1: check what's actually on disk

If you have SSH access to the account, this settles the question in ten seconds. From the account's home directory:

cd ~/mail/yourdomain.com/username
du -sh .

Compare that number to what cPanel's Email Accounts page shows. If du reports a genuinely small mailbox and cPanel still shows it near the limit, you've confirmed it's a cache problem, not a real one. No SSH access? Ask your host to run this — at Getwebup we do this check first before touching anything else, since it takes the guesswork out of the rest of the fix.

Step 2: make sure Trash and Junk were actually expunged, not just emptied

In Roundcube, clicking "Empty" on a folder should expunge it immediately, but some third-party mail clients only flag messages for deletion and wait for the next sync to remove them for real. Log into webmail directly (not through a desktop client) and empty Trash and Junk from there — it removes the files immediately rather than queuing the deletion.

Step 3: delete the stale cache file and let Dovecot rebuild it

This is the actual fix, and it needs root access, so it's typically something your hosting provider runs on your behalf (cPanel's own interface doesn't expose it to individual users). The command is:

doveadm quota recalc -u username@yourdomain.com

This forces Dovecot to walk the mailbox and rebuild maildirsize from scratch instead of trusting the cached number. It's safe to run on a live mailbox — it only recalculates, it doesn't touch any messages. If you're on a VPS with WHM root access yourself, you can run this directly over SSH; if you're on shared cPanel hosting, open a ticket and ask support to recalculate the mailbox quota rather than raise the limit — raising the limit on a mailbox that isn't actually full just delays the same confusing report.

Step 4: if it still hasn't updated, restart Dovecot

Occasionally the fix above needs a service restart to take effect cleanly, especially if the mailbox was mid-sync when the cache got corrupted. In WHM this is Restart Services → Mail Server (Dovecot). It briefly disconnects active IMAP sessions — clients reconnect automatically within a few seconds — and doesn't touch queued or stored mail.

Prevention: stop the cache from drifting again

  • Clean up from webmail, not raw file deletion. If you or a script ever deletes mail directly from the filesystem instead of through IMAP, follow it with a doveadm quota recalc — the cache has no way to know files disappeared otherwise.
  • Set Trash and Junk to auto-purge. In Roundcube, Settings → Folders lets you enable "clear on logout," which keeps those folders from silently growing into the actual source of a full mailbox.
  • Don't panic-raise the quota first. If a mailbox reports full right after a cleanup, check du before increasing the limit — you'll often find there's nothing to raise it for.
  • Recalculate after any bulk migration. Moving mail in with imapsync or a bulk import is one of the more common ways this cache goes stale on day one of a new mailbox.

Frequently asked questions

I emptied Trash and Junk but the quota bar hasn't moved at all — how long should I wait?

Under normal load, Dovecot updates its cache within seconds of an actual expunge. If it's been more than a few minutes with no change, stop waiting and check the real usage with `du -sh` from SSH, or ask your host to check it. A stuck cache doesn't fix itself with time.

Can I run `doveadm quota recalc` myself from cPanel?

Not from the cPanel interface itself — that command needs root, so it runs at the server (WHM) level. If you have root SSH access on your own VPS you can run it directly; on shared cPanel hosting, ask your host's support team to recalculate the specific mailbox.

Is a stale quota cache a sign my mailbox got corrupted?

No. It just means the cached size number and the real disk usage temporarily disagree — the messages themselves are intact. Recalculating rebuilds the count without touching any mail.

Should I just increase the quota instead of fixing the cache?

Only if you've confirmed the mailbox is genuinely near its limit with `du -sh`. If the real usage is small, raising the quota just hides the stale-cache problem — it'll likely show up again the next time someone does a big cleanup.

Does restarting Dovecot delete any email?

No. It briefly drops active IMAP/webmail connections, which reconnect automatically within a few seconds. Stored mail on disk is untouched — only the running mail service process restarts.

#cpanel #mailbox-quota #dovecot #email-bounce #maildir #webmail

Keep reading

Chat with Support