SMTP Error 543

Is "SMTP Error 543" a real SMTP code?

No. SMTP reply codes are defined in RFC 5321 §4.2.3 ("Reply Codes in Numeric Order"), and 543 is not one of them. The 5xx (permanent failure) replies listed in §4.2.3 are: 500, 501, 502, 503, 504, 550, 551, 552, 553, 554, and 555. (RFC 7504 later added 521 "Host does not accept mail" and 556 "Domain does not accept mail" to that list.) There is no 543 in any of them.

Where the number comes from is the enhanced status code system in RFC 3463. Enhanced codes look like X.4.4 ("Unable to route") and are written with dots, not as a bare three-digit number. A real bounce that involves routing looks like this:

550 5.4.4 [recipient.example] Unable to route: no MX record found

Here 550 is the RFC 5321 reply code and 5.4.4 is the RFC 3463 enhanced code. Somewhere along the way, tools and SEO pages collapsed "5.4.x routing" into a fictional "543." Treat "SMTP Error 543" as a mislabel: go read the server's actual reply line.

What is the real error behind it (X.4.4 "Unable to route")?

Per RFC 3463 §3.5, class X.4.x is "Network and Routing Status." The specific code X.4.4 "Unable to route" means: "The mail system was unable to determine the next hop for the message because the necessary routing information was unavailable from the directory server" — in practice, a DNS/MX lookup that returned nothing usable (for example, only an SOA record and no MX or A record for the recipient domain). The leading digit tells you severity: 4.4.4 is a temporary routing failure worth retrying; 5.4.4 is permanent.

How do I diagnose the real routing failure?

1. Capture the full reply. Get the exact line from your MTA/provider logs — the real reply code (421, 450, 550…) plus the enhanced code (4.4.4 / 5.4.4) and the human-readable text. That text is the ground truth, not "543."
2. Check the recipient domain's MX records. Run dig MX recipient-domain.com +short (or nslookup -type=MX recipient-domain.com). If nothing returns, the domain has no mail route — confirm the address and domain are spelled correctly and the domain still exists.
3. Fall back to A/AAAA per RFC 5321 §5.1. If a domain has no MX records, RFC 5321 treats it as having an "implicit MX" pointing at the domain's own host, so senders use the domain's A/AAAA record. If neither MX nor address records resolve, delivery cannot be routed — this is the classic X.4.4 condition.
4. Test resolution from the sending host. DNS can resolve fine from your laptop but fail on the mail server (split-horizon DNS, a broken resolver, or an outbound firewall blocking port 53). Verify from the host that actually sends.
5. If you operate the routing. For an on-prem MTA (Postfix transport_maps, Exim routers, a smart host), confirm the route/relay host for the destination is defined and reachable. A bad transport map produces a local "unable to route," not a remote bounce.

Note that some sources describe "543" as an invalid/blocked recipient — that overlaps with 550 5.1.1 ("bad destination mailbox address") and is a different diagnosis. Don't guess: the enhanced code in the bounce tells you whether it's routing (5.4.x) or a bad address (5.1.x).