SMTP 452 Insufficient Storage: Server, Mailbox or Recipient Limits

A 452 reply means the server could not accept the command because of a resource limit, and it expects you to try again later. RFC 5321 defines it as "Requested action not taken: insufficient system storage". Three different problems share the code, and the enhanced status code separates them.

Gmail's documented example is 452 4.2.2 The recipient's inbox is out of storage space. Gmail also documents 452 4.5.3 for "Your message has too many recipients" and "Domain policy size per transaction exceeded", so check Gmail's current error reference for exact wording.

postfix/smtp[4410]: 8A22C3F01: to=<kim@example.net>, relay=mx.example.net[198.51.100.30]:25, delay=2, dsn=4.2.2, status=deferred (host mx.example.net[198.51.100.30] said: 452 4.2.2 Mailbox full (in reply to RCPT TO command))

Step 1: work out which kind it is

Read the enhanced code in the log or bounce:

• 4.2.2: one recipient is the problem. Other recipients of the same message usually succeed.
• 4.3.1: every message to that server is affected, from every sender. It is not about your account.
• 4.5.3: the problem is the number of recipients in your envelope or the total size per transaction.

If it is 4.2.2 (recipient mailbox full)

You cannot fix someone else's quota. Retrying works only if they free space. After a few days the server may convert the deferral to a bounce when your queue lifetime expires. What to do:

1. Tell the recipient by another channel (phone, chat) that their mailbox is full.
2. For a customer or subscriber, mark the address as inactive in your list if it keeps happening for weeks. Persistently full mailboxes are often abandoned accounts.
3. If it is your own mailbox, delete or archive mail, empty trash and spam, and raise the quota. For Dovecot with quota plugin, see doveadm quota get -u user@example.com.

Some servers send 552 5.2.2 (permanent) for the same condition, covered in email mailbox full: 552 5.2.2.

If it is 4.3.1 on your own server (inbound refused)

Your mail system has no room for the queue or temp files. Postfix refuses incoming mail when free space in the queue partition falls below queue_minfree:

postconf queue_minfree message_size_limit mailbox_size_limit
df -h /var/spool/postfix
df -i /var/spool/postfix
sudo postqueue -p | tail -n 1

df -i matters because millions of tiny queue files can exhaust inodes while free space looks fine. Find what filled the disk: a runaway log, a huge queue of bounces, a backup in /var. Then free space, and if a compromised account is flooding the queue, secure it first. Postfix resumes accepting mail automatically once space is back above the threshold.

If the setting is too tight for your message size, queue_minfree should be at least 1.5 times message_size_limit, per Postfix guidance. Check the Postfix documentation for the current recommendation before tuning.

If it is 4.3.1 on a remote server

Nothing to fix on your side. Keep the message queued and watch for acceptance. If it persists for a day, contact the recipient's admin and include the server name from the log. Confirm the MX you are talking to with the MX लुकअप.

If it is 4.5.3 (too many recipients)

Split the send. Servers cap recipients per message; Postfix limits recipients per delivery with default_destination_recipient_limit (default 50). Many receivers allow around 100, others fewer, and some ask for one domain per transaction. For marketing sends use a proper email service instead of BCC lists of hundreds. For a script, batch recipients and send with a delay:

for i in range(0, len(recipients), 50):
    send(batch=recipients[i:i+50])

Step 2: monitor so it never surprises you

A full spool shows up as bouncing or deferred mail only after users complain. Alert on free disk (80 percent warning), queue length, and mailbox quotas. Add an अपटाइम मॉनिटर TCP check on port 25 and 587; see also the पोर्ट चेकर. A disk-full condition often leaves the port open but returning 452, so complement port checks with a mail-send test and log alerts.

How to verify

For the recipient case, send again after they confirm they cleared space. For your server, run sudo postqueue -f, then look for status=sent. A test with the ईमेल डिलीवरेबिलिटी टेस्ट confirms inbound acceptance end to end.

अगले कदम

• Read email mailbox full: 552 5.2.2 for the permanent version.
• See SMTP 552 message size exceeded for oversize messages.
• Learn the code families in email bounce codes explained.
• जाँचें SMTP 451 local error in processing.

सामान्य प्रश्न

Is 452 temporary or permanent?

Temporary. The sender queues it and retries. Many servers, however, return 552 for the same full-mailbox condition, and that one is permanent.

My recipient says their mailbox is not full. Why 452?

Some providers apply per-hour receiving limits or shared quotas, and report them with the same family of codes. Retry later and check the text of the reply.

How do I raise the message size limit?

That is a different error: 552 or 5.3.4. See SMTP 552 message size exceeded.

Can disk space on my server cause bounces for my senders?

Yes. When the queue partition is below queue_minfree, Postfix defers inbound mail with a 452, and senders see delays until you free space.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.