SMTP error 4.4.5 Mail system congestion

What SMTP error 4.4.5 means

The far end is busy and is asking you to come back later, reported as 451 4.4.5. Nothing is wrong with the message, the address or the route. Registered only as a transient failure, so the sender defers rather than losing anything. A few deferrals at a busy hour are ordinary. A whole sending run deferring consistently means you are being rate limited, and the answer lies in how you are sending rather than in trying harder.

Network and routing status
Sent by The receiving system under load, or your own outbound platform applying a throttle
Occasional

What SMTP error 4.4.5 Mail system congestion actually means

Congestion covers genuine capacity limits and deliberate rate limiting, and the large providers use it mostly for the second. They apply throttles per sending address and per sending domain, tuned by how much they trust you, so two organisations sending identical volumes get different treatment. That is why this code is so closely tied to sending reputation. Where 4.3.1 is a receiving system out of storage, this is a receiving system out of throughput, and it usually says more about your sending pattern in the last hour than about their hardware.

The mail system was unable to deliver the message because the mail system was congested. This is useful only as a persistent transient error.
— RFC 3463

How 4.4.5 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 451 4.4.5 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.4.5 on a business phone system

Genuine peak load at the receiving endA small on-premise server at nine on a Monday morning, or a filtering appliance working through an overnight backlog, will defer some connections to protect the ones it is already handling. It clears without intervention.
Per-sender throttling based on reputationProviders limit how much they will accept per hour from a sender they do not know well. A new sending address with no history is throttled hardest, which is why a freshly migrated tenant sometimes struggles for its first few weeks.
A newsletter or invoice run pushed through an ordinary mailboxSeveral hundred messages leaving in a burst from a single mailbox looks precisely like a compromised account to the receiving side. Deferral is the polite version of the response you can expect.
A compromised account sending spam in your nameOne account taken over will sour the reputation of the whole tenant within hours, and everybody else's mail starts being deferred as a result. Sudden congestion affecting all your users deserves a look at sign-in logs before anything else.
A backlog on your own gatewayWhere mail leaves through a hosted security service, that service has its own queues. One slow destination can back up behind others, and what your users experience as congestion is happening on your side of the path.

How to fix SMTP error 4.4.5

Look at your own send volume to that domain firstCount what left in the previous hour before assuming the receiver is at fault. A spike that matches the onset of deferrals answers the question and points at which mailbox or application caused it.
Move bulk sending to a platform built for itMarketing and mass notifications belong on a proper bulk sending service with its own sending domain, unsubscribe handling and delivery reporting. Keeping that traffic away from your mailbox platform protects the reputation your ordinary business email depends on.
Check for a compromised mailboxReview recent sign-ins for unfamiliar locations, look for forwarding rules nobody created, and check sent items for messages users do not recognise. Enforcing multi-factor authentication is the fix that prevents the recurrence.
Introduce new sending infrastructure graduallyA new IP address or sending domain should build volume over days rather than starting with a full run. Providers reward a steady, predictable pattern and throttle sudden arrivals.
Give it a few hours before escalatingDeferrals that clear on their own were doing their job. Escalate only when the same destination is still deferring after several retry cycles, and take your send volumes with you when you do.

Fixing the underlying problem

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

Questions about SMTP error 4.4.5

Have we been blacklisted?

Not on the strength of this code. A blocklisting is stated permanently with a 5xx reply and usually names the list involved. Congestion is a request to slow down, though repeated throttling is a warning sign that your reputation is heading that way.

Is this affecting all our email or just one recipient?

Check the queue by destination. Deferrals against a single domain are that domain's capacity or their view of you. Deferrals spread across many domains mean the problem travels with your sending address, which points at volume or reputation rather than at anybody's hardware.

Will the messages eventually arrive?

Usually, yes. Transient deferrals are retried on a schedule and most clear within a few cycles. They only turn into bounces if the deferral persists past the sender's retry window, which for Exchange Online is around a day.

Related SMTP status codes

Source. SMTP error 4.4.5 Mail system congestion 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