Are 543, 546, and 547 real SMTP error codes?

RFC 5321 defines SMTP reply codes as a three-digit number where the first digit sets the broad

category (2 = success, 3 = intermediate, 4 = temporary failure, 5 = permanent failure) and the

second digit narrows the category (0 = syntax, 1 = information, 2 = connections, 5 = mail system).

Within the 5yz permanent-failure class, the codes the standard and its extensions actually

define are 500, 501, 502, 503, 504, 550, 551, 552, 553, 554, and 555. **543, 546, and 547 are

not among them** — no compliant SMTP server generates these as a base reply code, and they do not

appear in RFC 5321 or its enhanced-status-code companion, RFC 3463.

The codes, side by side with what is real

If you have seen one of these numbers in a bounce notification or a tool's summary, it is worth

checking the raw SMTP transcript rather than trusting the label — it is likely a paraphrase, a

third-party tool's internal classification, or a transcription of a vendor-specific extension that

does not match the real wire-level reply.

"543: routing server failure"

The real-world condition this describes — the message cannot be routed to the next hop — shows up

on the wire as 550 5.4.4 Unable to route (the recipient's domain cannot be resolved or reached at

all) or, if it is a temporary routing problem rather than a permanent one, as `451 4.4.1 Connection

refused`.

RCPT TO:<recipient@example.com>
550 5.4.4 Unable to route your message, check the recipient domain's MX records

Check your MX records resolve correctly and that the next hop in your delivery path is actually

reachable: dig MX recipientdomain.com +short, then confirm each returned host accepts

connections on port 25 with openssl s_client -starttls smtp -connect <host>:25.

"546: email looping"

A genuine mail loop — a message bouncing between two misconfigured servers, incrementing a hop

count each time — is reported by real servers as 554 5.4.6 Too many hops, defined precisely for

this condition in RFC 3463.

554 5.4.6 Too many hops, this message is looping

If you are chasing a loop, check for circular forwarding rules (A forwards to B, B forwards back to

A) or an autoresponder replying to its own bounce messages — read the Received: header chain in

the looping message itself, top to bottom, and look for the same hostname appearing more than

once.

"547: delivery time-out"

A message that exhausts its delivery attempts without a receiving server ever accepting it reports

back as 451 4.4.7 Delivery time expired while attempts are ongoing, and becomes a permanent

failure once your own sending queue gives up and generates a non-delivery report locally — that

final NDR is generated by your own MTA, not received from the far end, which is part of why its

numbering can look nonstandard.

451 4.4.7 Delivery time expired, retrying

How to find the real code

1. Get the raw SMTP transcript, not a summary — most mail logging and NDR-generation tools

preserve the literal server reply somewhere, even when their UI shows a translated or

categorised version. On Postfix, this means reading /var/log/mail.log directly rather than a

dashboard's rollup.

1. Match the real reply's first digit to 4 or 5 before doing anything else — that single digit

determines whether this is worth retrying or needs the address/route fixed outright.

1. Look up the actual enhanced status code (x.y.z after the three-digit code) against RFC

3463, not the three-digit code in isolation — the enhanced code carries the real detail.

What not to do

• Do not search documentation or RFCs for "543", "546", or "547" expecting a definition — you will

not find one, and time spent trying to map a tool's internal category back to an RFC that does

not define it is time not spent reading the actual transcript.

• Do not treat a tool's internal error classification as the literal wire protocol reply without

checking the raw transcript at least once — a monitoring dashboard that invents its own numbering

scheme for readability is common, and trusting its numbers as RFC codes will misdirect your fix.

• Do not build automated bounce-handling logic keyed on these numbers directly; key it on the real

RFC 5321/3463 codes behind the condition instead, since a future version of the same tool could

change its internal numbering without warning.

MailPilot surfaces the actual SMTP reply and enhanced status code behind every delivery event

rather than a paraphrased category, which is the only reliable way to tell a real 554 5.4.6

mail loop apart from a tool's shorthand for one.