SMTP error 5.3.2 System not accepting network messages

What SMTP error 5.3.2 means

The host answered and then said it is not taking mail. That is the distinguishing feature: something replied. It arrives as 453 when the refusal is temporary, such as maintenance or load shedding, and as 521 when the host is stating flatly that it does not accept mail at all. A 521 is worth treating as an answer rather than a fault, because it is frequently a deliberate declaration that mail for that name belongs somewhere else.

Mail system status
Sent by The destination host, or whatever device is answering on port 25 in its place
Occasional

What SMTP error 5.3.2 System not accepting network messages actually means

The condition covers an imminent shutdown, excessive load and planned maintenance, and the same code carries a permanent refusal from a host that will never take mail. Both classes are registered, so the class digit decides whether the sender waits or bounces. In day-to-day support the interesting case is a host answering on port 25 that is not the mail server anyone intended: a router with a port forward left over from a migration, a load balancer answering before its pool members are ready, or a decommissioned box still powered on with its transport service stopped. Whatever answers first defines the outcome for the sender.

The host on which the mailbox is resident is not accepting messages. Examples of such conditions include an imminent shutdown, excessive load, or system maintenance. This is useful for both permanent and persistent transient errors.
— RFC 3463 with RFC 7504

How 5.3.2 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 521 5.3.2 as the pairing for this status. The registry also lists 453 for this condition, but that belongs with 4.3.2 rather than with this code, because a reply code and the status beside it always agree on whether the failure is temporary or permanent.

The leading 5 is the server's verdict rather than part of the code's identity: it marks this as a permanent failure, which means the sending server has given up and returned the message. The same condition reported as 4.3.2 is the other verdict on the identical problem, so a log showing that form has not produced a bounce yet.

What causes SMTP error 5.3.2 on a business phone system

Planned maintenance on a self-hosted serverA properly configured server refuses politely with a temporary code while it is patched or moved, so senders retry afterwards. The refusal is correct behaviour and the mail arrives late rather than not at all.
A port forward left behind after a migrationThe mailboxes moved to a hosted platform, the MX record was changed, and the firewall rule sending port 25 to the old internal server was never removed. Anything still using the old hostname reaches a machine that no longer wants the mail.
A device other than a mail server listening on port 25Some routers, UTM appliances and even printers answer on 25. They present a banner, refuse everything, and produce results that look like a mail server fault until you read what actually greeted you.
A host deliberately published as not accepting mailOrganisations that have consolidated onto one mail platform sometimes leave old hosts configured to refuse permanently rather than removing them. The refusal is the intended answer and no amount of retrying changes it.
Load shedding under pressureA small server that is struggling may refuse new inbound sessions to protect the ones in progress. It will look healthy from the console while turning senders away at the door.

How to fix SMTP error 5.3.2

Open the connection yourself and read the bannerConnecting to port 25 on the host by hand tells you immediately who answered and what they said. A banner naming an unexpected product is the fastest way to discover you are not talking to the mail server at all.
Confirm the MX record points where you think it doesResolve it from a public resolver rather than from inside the network, where an internal DNS zone may answer differently. Post-migration faults are very often an MX record still naming a host that has been retired.
Remove firewall rules that publish an old mail serverOnce mailboxes are hosted, nothing should be forwarding port 25 to an internal server unless a hybrid connector needs it. Tidying this up closes both a mail fault and an exposure.
Check the transport service on your own serverIf the failing host is yours, verify the transport service is running, that no maintenance mode is set, and that the receive connector is still bound to the right address and enabled.
Treat a persistent 521 as an answer and rerouteWhen a host states permanently that it takes no mail, the correct next step is to establish where that domain's mail should go and correct your own records, not to raise a fault against the far end.

Fixing the underlying problem

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

Questions about SMTP error 5.3.2

How is this different from getting no response at all?

Here the connection succeeded and the far end spoke. Where nothing answers, the sender reports 4.4.1 instead. That distinction narrows the search enormously: a refusal means the path works and the policy is against you, while silence means the path itself is broken.

We are doing planned maintenance. Will we lose mail?

Not if your server refuses temporarily rather than dropping connections. Senders hold the message and retry, so a maintenance window of a few hours simply delays delivery. Losing mail happens when the server is switched off with nothing answering behind it for longer than senders will wait.

Our supplier says their email is fine, yet we get this every time.

Check which host your server is actually connecting to. If their MX now points at a hosted platform and you are still reaching an old address, either a stale DNS answer or a hard-coded smart host on your side is sending you to a machine that has correctly retired.

Related SMTP status codes

Source. SMTP error 5.3.2 System not accepting network messages is defined in RFC 3463 with RFC 7504 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