SMTP error 4.3.1 Mail system full

What SMTP error 4.3.1 means

The receiving system has run out of storage for mail as a whole, not for one user. It arrives as 452 and the registry allows it only as a transient failure, so the sending server keeps the message queued and delivery resumes once space is freed. Keep it apart from 5.2.2, which is one person's mailbox being full and can be fixed by that person deleting things. Nobody but an administrator can fix 4.3.1, and while it lasts every message into that system is stopping.

Mail system status
Sent by The receiving mail system, most often an on-premise server or appliance
Occasional

What SMTP error 4.3.1 Mail system full actually means

The definition makes a point of saying the individual recipient cannot delete material to make room, and that is the practical difference. This is a disk, a database volume or a spool at the receiving end, and it affects everyone behind it. On-premise Exchange has a specific mechanism for it called back pressure: when free space on the transport queue volume or available memory drops past a threshold, the transport service starts refusing new connections and inbound messages with a temporary code so that senders retry rather than lose mail. Filtering appliances behave similarly when their quarantine or spool volume fills.

Mail system storage has been exceeded. The general semantics imply that the individual recipient may not be able to delete material to make room for additional messages. This is useful only as a persistent transient error.
— RFC 3463

How 4.3.1 appears in a bounce

A server reporting this condition sends it alongside a three-digit reply code, and a bounce prints the two together. The registry lists 452 4.3.1 as the pairing for this status.

The leading 4 is the server's verdict rather than part of the code's identity: it marks this as a temporary failure, which means the sending server is still retrying.

What causes SMTP error 4.3.1 on a business phone system

The transport queue volume has run out of spaceOn Exchange the queue database and its logs live on a volume of their own on a well-built server, and on a badly built one they share the system disk. Either way, once free space crosses the threshold the server sheds inbound mail deliberately.
Transaction logs not being truncated because backups are failingExchange only clears its logs after a successful backup. A backup job that has been quietly failing for a fortnight will fill a volume that has been comfortable for years, and mail stopping is often the first anyone notices.
A quarantine or spool filled by a spam floodAn appliance that retains every blocked message for review can consume its own storage during a large campaign. The retention setting was reasonable at normal volumes and is not reasonable at ten times that.
A stuck destination holding thousands of messages in the queueOne unreachable domain that the server keeps retrying can accumulate a queue large enough to exhaust the volume. The symptom is a storage failure; the actual problem is a routing or connectivity fault somewhere else entirely.
Verbose logging left switched on after troubleshootingProtocol logging and message tracking at high verbosity generate a surprising volume. Enabled for an afternoon of diagnostics and never turned off, they will eventually fill the disk they are written to.

How to fix SMTP error 4.3.1

Check free space on every volume the mail system usesNot just the system drive. Look at the database volume, the transport queue volume and the log volume separately, because the one that has filled is often not the one being monitored.
Inspect the queue for a single stuck destinationSort the queue by message count per destination. If one domain holds the bulk of it, dealing with that route frees the storage and prevents a repeat far more reliably than adding disk.
Run a successful backup to truncate the logsOn Exchange this is the supported way to reclaim log space, and it fixes the underlying reason the volume filled. Deleting log files by hand risks the database and should be a last resort taken knowingly.
Reduce quarantine retention on filtering appliancesThirty days of every blocked message is rarely worth the storage. Cut the retention period, purge, then confirm the inbound queue drains and the temporary failures stop.
Put threshold alerting on the volumes that matterAn alert at twenty per cent free space turns this from an outage into a ticket. If the server is old enough to be running out of room regularly, that is a strong argument for moving the mailboxes to a hosted platform.

Fixing the underlying problem

This page explains the code. These guides walk through the fix in detail.

Questions about SMTP error 4.3.1

Will messages sent to us during this be lost?

Not immediately. A 452 tells the sending server to hold the message and try again, and most senders will persist for a day or more before giving up. Messages only bounce if the storage problem outlasts the sender's retry window, which is why fixing it the same day matters.

How is this different from a mailbox being full?

A full mailbox is 5.2.2 and affects one person, who can clear space themselves. Mail system full is the platform beneath every mailbox running out of storage, so nobody on that system receives anything until an administrator intervenes.

Can this happen to us on Microsoft 365?

Not as an inbound condition. Microsoft manages the underlying storage, so what you meet instead is a per-mailbox quota or an archive limit. Seeing 4.3.1 in an NDR points at an on-premise server, a hybrid server still in the path, or a recipient running their own mail system.

Related SMTP status codes

Source. SMTP error 4.3.1 Mail system full is defined in RFC 3463 and registered in the IANA SMTP Enhanced Status Codes registry. The causes and fixes above are drawn from our own experience supporting UK business email systems.

All Email delivery & SMTP codes