SMTP Error 431

SMTP Error 431 is a temporary failure returned by the receiving mail server, typically reading 431 4.3.1 STOREDRV; mailbox disk is full or 431 4.3.1 STOREDRV.Submit.Exception on Microsoft Exchange. The leading 4 puts it in the transient (4xx) class, so the message is not permanently rejected: your sending server should queue it and retry.

Important: this is the receiving server telling you it is out of resources. It is not caused by "too many recipients," and there is nothing in the message body or recipient list you can edit to make 431 go away from the sender side.

What causes SMTP Error 431?

431 signals that the destination server lacks the system resources to accept the message right now. On Microsoft Exchange there are actually two distinct mechanisms that can produce a 431/452 4.3.1 response, and they're diagnosed differently:

• Store-level disk-full check (STOREDRV). The Mailbox Transport Submission service checks the free space on the drive holding the mailbox database, transaction logs, or system TEMP folder. When free space drops below a fixed threshold (roughly 1GB), it rejects submission with 431 4.3.1 STOREDRV; mailbox disk is full, logged in the message tracking log as a SUBMITDEFER event with source STOREDRIVER.
• Transport "back pressure." Separately, Exchange's Transport service monitors disk, memory, and queue-database (version bucket) usage as percentages of drive/resource utilization; when a resource crosses a threshold it throttles or stops accepting inbound mail and answers with 431/452 4.3.1, logging Resource Manager Event IDs 15004/15005 (resource pressure increased/decreased) and 15006/15007 (critically low disk/memory) — not SUBMITDEFER/STOREDRIVER. (Microsoft / Exchange back pressure)

Both mechanisms are ultimately about running low on disk or memory, and freeing space helps either one — but they trip independently and leave different log signatures, so which one fired determines where to look first.

Note on accuracy: 431 is not listed in RFC 5321. The base SMTP standard expresses this condition as 452 ("Requested action not taken: insufficient system storage," RFC 5321 §4.2.3). 431 is a vendor extension, used most notably by Microsoft Exchange and the Windows SMTP service. The attached enhanced status 4.3.1 maps to RFC 3463's "Mail system full" — a system-wide shortage, distinct from 4.2.2 "Mailbox full," which is a single recipient over quota.

How do I fix SMTP Error 431?

If you are the sender:

1. Do nothing first — let it retry. Because 431 is a 4xx transient code, a well-behaved MTA (Postfix, Exchange, SendGrid, SES, etc.) automatically requeues and retries with backoff. Many 431s clear once the remote server frees resources after a traffic spike or maintenance window.
2. Confirm it's not a hard bounce. Check your logs/bounce webhook: a 4xx 431 should defer, not bounce. If your platform is converting it to a permanent failure, adjust retry handling rather than re-sending blindly.
3. If 431 persists for hours against one domain, contact that recipient's mail administrator (or postmaster) — the fix lives on their server (free disk, add memory, relieve back pressure). It cannot be resolved by editing your message.

If you administer the receiving Exchange server:

• If the error is 431 4.3.1 STOREDRV; mailbox disk is full (tracked as a SUBMITDEFER/STOREDRIVER event), free disk space on whichever drive is low — the mailbox database/log volume or the system TEMP drive. This check uses a fixed low-space threshold rather than a percentage, so it can trip even on a large volume that still has meaningful free space in relative terms.
• If the error surfaces via Transport back pressure (Resource Manager Event IDs 15004-15007), check disk, memory, and queue-database utilization percentages. Freeing disk space on the transport-queue and database/log volumes lowers utilization and lets mail flow again.
• Investigate the queue-database checkpoint depth (DatabaseCheckPointDepthMax in EdgeTransport.exe.config, default 384MB). At default settings the transaction-log drive's high-utilization threshold is a flat ~1152MB reserve; DatabaseCheckPointDepthMax only feeds into that formula if you've customized it away from the default.
• Review the relevant event logs (15004-15007 for back pressure; message tracking SUBMITDEFER for STOREDRV) to confirm which mechanism tripped before applying a fix. (Microsoft / Exchange back pressure)

Sending through Courier or another API? Provider-managed sending infrastructure already applies RFC-compliant retry/backoff for 4xx codes like 431/452, so transient resource errors on the recipient side are usually retried for you. Watch your delivery logs to confirm eventual delivery, and treat a sustained 431 against a specific recipient domain as that domain's operational issue, not a content or list problem.