Start with the rejecting mailbox and server
A 5.2.2 “mailbox full” rejection points to the receiving mailbox’s storage limit or available capacity. If the intended recipient uses a DirectAdmin-hosted mailbox, check that mailbox’s usage and the hosting account’s total storage before deleting anything or increasing a limit. A bare 552 code is less specific: read the full bounce, especially its enhanced code, recipient and rejecting host.
This guide applies when your accepted Novasean service includes a DirectAdmin-hosted mailbox. If your domain receives mail at another provider, its operator must diagnose that provider’s storage rejection. A failed delivery does not prove that Novasean hosts the recipient or that your own outgoing-mail settings are wrong.
Identify whose storage rejected the message
- Keep the full error code, the words after it, the recipient domain, rejecting hostname and time with time zone. Redact private addresses and message content before sharing a ticket.
- Compare the rejecting host with the domain’s current MX records and the mail provider named in the accepted service. Use the authoritative DNS guide if the panel and public answer differ.
- If the bounce is from an external recipient’s provider, ask that recipient to contact its mail operator. Increasing your DirectAdmin quota will not repair their mailbox.
The SMTP enhanced code 5.2.2 identifies a full mailbox. A message-size refusal (5.3.4) requires a different check; do not treat every 552 as proof that one mailbox reached its quota. A full mail system is another distinct condition.
Compare mailbox, account and server capacity
At the correct DirectAdmin User account, open E-mail Accounts for the domain and review the affected mailbox’s displayed quota and usage if your service exposes them. Then check the hosting account’s overall disk usage. A mailbox can reach its own limit before the account is full; the account or underlying storage can also be constrained even when the mailbox display looks below its limit. DirectAdmin documents mailbox quota and account filesystem quota as separate mechanisms.
Record the figures and the time you viewed them. Do not assume two panel numbers measure identical bytes: DirectAdmin’s detailed quota output distinguishes disk blocks from file sizes, and accounting views may update at different times. If the apparent free space contradicts the rejection, ask support to check the effective Dovecot quota, account limit, server capacity and delivery log rather than changing values at random.
A daily sending limit is a different control. If the failure concerns messages you send rather than incoming delivery, follow the DirectAdmin sending-limit guide.
Preserve needed mail before freeing storage
Identify the mailbox owner and any retention requirement before removing messages. If the owner approves a clean-up, preserve needed mail through an authorised export or backup and verify that it can be read. Inspect server-side folders, including Sent, Spam and Trash if present; a desktop client’s local deletion may not remove server-stored copies. Empty or purge a folder only when the owner understands what will be lost and a usable copy exists.
After one small, approved change, refresh the mailbox and account usage views and check whether the effective limit now has headroom. Do not delete an entire mailbox, disable quota enforcement or set an unlimited value as a shortcut. A higher mailbox setting cannot create physical storage or expand a purchased account entitlement.
When capacity must change
If retained mail legitimately needs more space, compare the required size with your accepted service terms. An authorised account owner may be able to adjust a mailbox quota within the plan; the available panel control and maximum vary by service. Ask Novasean support to confirm the permitted change, available account capacity and operator responsibility when the control is absent or the account is near its own limit. Any plan or service change needs its own agreed terms.
For a managed mail service, leave server-side Dovecot, filesystem and delivery-log changes to the operator. For a self-managed server, use your own change control and tested backup before operator-level repair. This article does not establish a Novasean-wide mailbox size, retention period or automatic warning.
Verify the recovery with a new message
Send a small controlled message from an external account to the affected address after the quota or capacity issue is resolved. Confirm it appears in the intended provider’s webmail or server-side mailbox, then check the mail client separately. Keep the sender’s timestamp and message ID for support if it still fails. Previously bounced messages may need to be sent again; do not assume that an earlier permanent failure will be replayed after space is freed.
If there is no bounce but nothing arrives, follow the broader send-but-not-receive guide. It separates MX routing, server delivery, filtering and client retrieval.
What to give support
Provide the service and domain, affected mailbox, redacted bounce with exact SMTP and enhanced status codes, rejecting host, time with time zone, current MX answer, and the mailbox and account usage figures you can see. State whether you preserved mail before any clean-up and whether a fresh external test reached webmail. Do not send passwords, unrestricted logs or complete private messages in an ordinary ticket.
Can I fix this by changing my sender settings? Not when the recipient’s server rejected delivery for storage. Can I simply raise the quota? Only if the accepted service permits it and the account and server have capacity. Will the old message arrive later? Do not rely on that; ask the sender to resend a previously bounced message after recovery.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.