SMTP Error 547

Is "SMTP Error 547" a real SMTP code?

No — and that distinction is the most useful thing to know. There is no reply code 547 in RFC 5321, the SMTP specification. A basic SMTP reply is a three-digit number whose second digit denotes a functional category (x0z syntax, x1z information, x2z connections, x3z/x4z unspecified, x5z mail system). RFC 5321 itself defines only 500–504 and 550–555 as 5xx codes. Across the wider set of SMTP RFCs, other 5xx codes exist too — 521 and 556 come from RFC 7504, and 530/534/535/538 are SMTP AUTH codes from RFC 4954 — but 547 is not among them in any of these.

What "547" almost always is: a mangled rendering of the enhanced mail system status code 5.4.7 (or its transient sibling 4.4.7) defined in RFC 3463. You'll most often see it in a bounce as 554 5.4.7 or 550 4.4.7. The leading three-digit reply code (554/550) and the dotted enhanced code (5.4.7) get collapsed into "547." So if you're chasing a literal 547, look at the full bounce message instead.

What does 5.4.7 / 4.4.7 actually mean?

Per RFC 3463, X.4.7 is "Delivery time expired": "The message was considered too old by the rejecting system, either because it remained on that host too long or because the time-to-live value specified by the sender of the message was exceeded."

In practice this is a sending-side queue timeout. Your MTA accepted the message, couldn't hand it off to the recipient's server, retried for its configured window, and finally gave up and bounced it:

• 4.4.7 — transient. Still retrying; the message has been delayed, not killed. No action may be needed yet.
• 5.4.7 / 554 5.4.7 — permanent. The retry window expired and the message was returned as undeliverable.

This is distinct from a per-recipient rejection (550 "no such user") — the recipient address may be perfectly valid; the problem is that the connection to their server never succeeded in time. Note that vendors don't always keep the leading digit consistent between the base reply code and the enhanced code — Microsoft, for example, reports a permanent-looking 550 base code together with the transient 4.4.7 enhanced code for a temporary delivery delay. When the two disagree, treat the enhanced code's leading digit (4 vs. 5) as the more reliable transient/permanent signal.

How do I fix SMTP 5.4.7 ("547")?

Work the delivery path from the recipient's DNS back to your own queue:

1. Check the recipient domain's MX and DNS. A timeout often means your server couldn't resolve or reach the destination MX. Verify records resolve: bash dig +short MX recipient-domain.com dig +short A mx-host-from-above.com If MX lookups fail intermittently, fix your resolver/DNS before anything else (Cisco and Microsoft both list DNS/MX resolution as the first cause of 5.4.7/4.4.7).
2. Confirm the recipient server is reachable and accepting mail on port 25 from your sending IP. Firewalls, greylisting, or an overloaded destination that keeps deferring (4xx) until your window expires all produce this bounce: bash nc -vz mx-host.com 25
3. Inspect your sending server's queue. A backlog of stuck messages points to a local performance or routing problem, not the recipient. Check whether the message was deferred repeatedly and why.
4. Review the retry/timeout window only as a last resort. Retry windows vary widely by platform — Microsoft 365/Exchange Online retries for 24 hours before generating this NDR, while some on-prem gateways like Symantec/Broadcom Messaging Gateway default to roughly 5 days. Lengthening your own window just delays the bounce; it doesn't fix an unreachable destination. Treat it as a knob of last resort.
5. Rule out blocklisting of your sending IP/domain if the destination silently defers your connections. Check the IP against major DNSBLs.

If you send through Courier, transient 4.4.7 delays are retried by the downstream provider automatically; a permanent 5.4.7 bounce surfaces in your message logs and indicates the destination was unreachable for the full retry window — investigate the recipient domain's DNS/MX and reachability first.