SMTP 452 4.1.0: a resource error with a mismatched address-status code

452 is a genuine 4xx temporary failure meaning the receiving server has run out of some resource - disk, mailbox quota, or recipient count per message - and cannot process this transaction right now. The base code is unambiguous and well documented. The enhanced status code attached to it in this case, 4.1.0, is less consistent: RFC 3463 defines the 4.1.x family as "mailbox/address status" problems (ambiguous address, bad destination mailbox), not resource exhaustion, which properly belongs to the 4.2.x (mailbox status) or 4.3.x (mail system status) families. In practice, some MTAs pair 452 with 4.1.0 as a generic "something about this transaction, try later" catch-all rather than a precise classification, so treat the subcode here as informational, not literal.

Who is at fault

The fault is on the receiving server's resource state, not the recipient address and not your sending reputation. The 452 base code is the reliable signal; do not over-read the 4.1.0 as meaning the address itself is the problem. It helps to remember why this mismatch happens at all: many MTA codebases implement enhanced

status codes as a lookup keyed primarily off the base three-digit reply, with the subcode filled

in from a smaller, older table that was never fully updated as RFC 3463 added more granular

address and resource categories later. The result is a server that is otherwise perfectly

RFC-compliant on the base code producing a subcode that reads oddly to anyone checking it against

the newer, more detailed table. This is a labelling quirk in specific MTA implementations, not

evidence of anything wrong with the message or the recipient.

The exchange

220 mx.example.com ESMTP
EHLO mail.yourdomain.com
250-mx.example.com
250 SIZE 26214400
MAIL FROM:<sender@yourdomain.com>
250 2.1.0 OK
RCPT TO:<recipient@example.com>
452 4.1.0 <recipient@example.com>: Temporary failure, try again later

The rejection happens at RCPT TO, which is consistent with a resource limit (too many recipients being processed for that account or domain right now), not with the address itself being malformed - the address format is fine.

How Gmail, Microsoft 365 and Yahoo word the same resource-exhaustion condition

Notice all three use the more semantically correct 4.2.x or 4.3.x subfamilies for the same underlying event - which is additional evidence the 4.1.0 pairing you received is informal rather than standard.

Diagnostic commands

$ swaks --to recipient@example.com --from sender@yourdomain.com --server mx.example.com
<~  452 4.1.0 <recipient@example.com>: Temporary failure, try again later

$ for i in 1 2 3; do sleep 300; swaks --to recipient@example.com \
  --from sender@yourdomain.com --server mx.example.com; done

Repeating the probe every five minutes for 15-20 minutes tells you whether the server's resource pressure is momentary (clears quickly) or structural (persists for hours, suggesting a quota or disk issue on their end that will not resolve itself soon).

The ordered fix

1. Treat the 452 base code as authoritative and the 4.1.0 subcode as non-diagnostic noise from this particular server.
2. Let your queue retry on its normal schedule - a resource shortage on their end is their problem to clear, and most do within hours.
3. If it is one specific recipient repeatedly, suspect a personal mailbox quota rather than a domain-wide issue.
4. If it is every recipient at that domain, suspect a shared resource limit (connection cap, disk) and reduce your concurrent connections to that domain while it resolves.
5. Re-test after 24 hours; if still failing, reach the recipient through another channel.

What not to do

• Do not read 4.1.0 as "bad address" and remove the recipient. The base 452 code tells you this is a resource issue, and the address format and existence are not in question here.
• Do not change your own DNS or authentication records. This has nothing to do with SPF, DKIM or DMARC.
• Do not escalate your sending rate to "push through" the resource limit - that makes a capacity problem on their end worse, not better.
• Do not count this against your own sender reputation. It is not a complaint, a spam classification, or a blocklist signal.

Why the subcode mismatch is worth noticing, not fixing

You cannot correct another server's enhanced-status pairing, but noticing the mismatch is useful

for one practical reason: it tells you this receiving system's software is older or less strictly

maintained than one that correctly separates address status from resource status. That is weak but

real evidence the domain is self-hosted on a smaller or less actively patched mail stack, which is

useful context the next time you see an unusual reply from the same domain - treat its codes as

informal signals of the general condition rather than literal, by-the-book classifications.

MailPilot's reputation tracking distinguishes transient resource deferrals like this from genuine complaint or authentication failures, so a mismatched or unusual enhanced status code from one receiving server does not distort your overall per-mailbox score.