SMTP error 547
Delivery time expired — a garbled form of 5.4.7, not a real code.
Updated Jul 1, 2026
SMTP 547 is not a real SMTP reply code. It is almost always a garbled rendering of enhanced status 5.4.7 (or 4.4.7), "delivery time expired": your sending server retried delivery for days, never reached the recipient server, and bounced the message. Fix it by checking the recipient domain MX and DNS, and your sending server queue and retry settings.
Check recipient MX / DNS and reachability, and your own queue.
What it means
There is no 547 reply code in RFC 5321. A basic reply is a three-digit number whose second digit denotes a category (x0z syntax, x1z information, x2z connections, x5z mail system), and RFC 5321 itself defines only 500 through 504 and 550 through 555 as 5xx codes. Across the wider set of SMTP RFCs, others exist (521 and 556 from RFC 7504, and 530, 534, 535, 538 from RFC 4954), but 547 is in none of them. What "547" almost always is: a mangled rendering of enhanced status 5.4.7 (or its transient sibling 4.4.7) from RFC 3463, seen in bounces as "554 5.4.7" or "550 4.4.7", where the reply code and the dotted enhanced code got collapsed. Per RFC 3463, X.4.7 is "delivery time expired": the message was considered too old, either because it stayed on the host too long or its sender time-to-live was exceeded.
Common causes
Your MTA accepted the message, could not hand it off to the recipient server, retried for its configured window, and bounced it. 4.4.7 is transient (still retrying, delayed not killed) and 5.4.7 or 554 5.4.7 is permanent (window expired, returned).
A timeout often means your server could not resolve or reach the destination MX. Cisco and Microsoft both list DNS or MX resolution as the first cause of 5.4.7 or 4.4.7.
Firewalls, greylisting, or an overloaded destination that keeps deferring (4xx) until your window expires all produce this bounce.
A destination that silently defers your connections can be reacting to a DNSBL listing.
How to fix it
- Check the recipient domain MX and DNS
Verify records resolve with "dig +short MX recipient-domain.com" and then "dig +short A mx-host-from-above.com". If MX lookups fail intermittently, fix your resolver or DNS before anything else.
- Confirm the recipient server is reachable on port 25
Test from your sending IP with "nc -vz mx-host.com 25". Firewalls, greylisting, or repeated deferrals until your window expires all cause this bounce.
- Inspect your sending server 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.
- Review the retry or timeout window only as a last resort
Windows vary: Microsoft 365 and Exchange Online retry for 24 hours before this NDR, while some on-prem gateways such as Symantec or Broadcom Messaging Gateway default to roughly 5 days. Lengthening your own window just delays the bounce; it does not fix an unreachable destination.
- Rule out blocklisting
If the destination silently defers your connections, check your sending IP and domain against major DNSBLs.
Paired code
A real bounce often shows both a 3-digit code and an enhanced code together. This one commonly pairs with:
Common questions
Is SMTP Error 547 a real SMTP reply code?
No. RFC 5321 defines only 500 through 504 and 550 through 555 as 5xx codes; other SMTP RFCs add a few more (521 and 556 from RFC 7504, 530, 534, 535, 538 from RFC 4954), but none is 547. "547" is almost always a garbled form of enhanced status 5.4.7 (or 4.4.7), "delivery time expired", often seen as "554 5.4.7" or "550 4.4.7".
What is the difference between 4.4.7 and 5.4.7?
4.4.7 is transient: the message is still being retried and may yet deliver. 5.4.7 is permanent: the retry window expired and the message bounced. When a base reply code and the enhanced code disagree, trust the enhanced code leading digit (4 versus 5) as the transient or permanent signal.
Why did my email bounce with 5.4.7 if the recipient address is valid?
Because 5.4.7 is a delivery timeout, not a bad-address rejection. The recipient may be perfectly valid; the problem is that the connection to their server never succeeded within your retry window, usually a DNS, MX, firewall, or reachability issue.