SMTP 452 4.3.1: receiving server is out of storage

452 4.3.1 is a 4xx temporary deferral. The enhanced code 4.3.1 specifically means "mail system full" at the system level — the receiving mail server itself is low on storage or resources, distinct from 4.2.2, which indicates an individual recipient's mailbox is full. This is a server-wide condition, not specific to the one recipient you're sending to.

Who is at fault

The recipient's infrastructure. There is nothing on the sending side that causes or fixes this — it's purely a capacity condition on their mail server.

The exchange

220 mx.example.com ESMTP ready
EHLO mail.yourdomain.com
250 mx.example.com
MAIL FROM:<sender@yourdomain.com>
250 2.1.0 OK
RCPT TO:<recipient@example.com>
250 2.1.5 OK
DATA
354 Start mail input; end with <CRLF>.<CRLF>
452 4.3.1 Insufficient system storage

How the big three word it

This specific code is seen far more often from self-hosted or smaller mail systems than from the large consumer providers, which run with substantial headroom.

Diagnose it

There's nothing to diagnose on your side beyond confirming the pattern:

$ grep "452 4.3.1" /var/log/mail.log | wc -l

Check whether this is isolated to one recipient domain (their server) or appearing broadly (which would suggest the code is being misreported and is actually something else — re-check the raw reply text).

Fix it, in order

1. Do nothing to your own sending setup — there's no sender-side cause here.
2. Let your MTA's retry queue handle it. This condition typically clears within hours as the receiving server frees capacity.
3. If it persists for days against the same domain, that recipient's mail system has a real ongoing capacity problem — there's no action you can take beyond waiting or, for a B2B contact, flagging it to them directly.
4. Don't remove the recipient from your list on the basis of this alone — it's not evidence the address or domain is invalid, only that the server is temporarily full.

A cause worth distinguishing: system-wide versus per-mailbox storage

It's worth being precise about scope here because the fix (or lack of one) differs. 4.3.1 means the receiving mail system itself — the shared infrastructure serving many mailboxes — is short on storage or resources. 4.2.2, by contrast, means one specific recipient's mailbox is full while the rest of that system is fine. If you're seeing 452 4.3.1 against many different recipients at the same domain within a short window, that confirms the system-wide reading; if it's isolated to one address, double-check the raw enhanced code, since a mislabeled 4.2.2 is a different, equally sender-side-inactionable, but individually-scoped condition.

An additional check

$ grep "452" /var/log/mail.log | awk '{print $NF}' | sort | uniq -c

Counting how many distinct recipient addresses at the affected domain triggered the 452 in the same time window tells you quickly whether this is one overloaded mailbox or a genuinely system-wide capacity event — useful context before deciding whether to even bother checking back later.

How long this usually takes to clear

System-wide storage exhaustion on well-run infrastructure (anything from a major provider) is typically a short-lived capacity blip that clears within hours as old mail is purged, backups complete, or additional storage is provisioned. On a smaller or less actively maintained mail system, it can persist for days, since there's no external pressure forcing a fast fix the way there is for the receiving provider's own reputation. Your MTA's retry queue will keep attempting delivery through its normal backoff schedule the entire time regardless, so there's nothing time-sensitive for you to do beyond the occasional check-in if the condition is unusually persistent. This is also one of the few deferral types where contacting the recipient's postmaster directly, if you have any relationship with that organization, can genuinely speed things up — unlike a reputation-based deferral, there's no sender-side signal they're waiting to see improve.

What not to do

• Don't treat this as a sign your message or domain triggered a problem. 4.3.1 has nothing to do with your content, authentication, or reputation.
• Don't retry manually and repeatedly. It won't clear any faster than the receiving server's own resource situation allows, and repeated manual retries just add load to an already-strained system.
• Don't suppress or hard-bounce the recipient. This is a temporary condition, not evidence of an invalid address.

MailPilot's bounce classification separates recipient-infrastructure conditions like this from sender-side reputation or authentication issues, so a wave of 452s from one domain doesn't get misread as a problem with your own sending.