What 550 4.4.7 Means
550 4.4.7 (sometimes 5.4.7) is Exchange announcing that it gave up on delivering a message after the configured retry window expired. Per RFC 5321, mail servers retry transient (4.x.x) failures for a bounded period — Exchange's default is 48 hours. If every retry returned a transient failure for that entire window, Exchange converts the message to a permanent failure with 4.4.7 (or 5.4.7). The 4.4.7 enhanced code means 'delivery time expired.'
Exchange Online and on-premises Exchange. Some other receivers use similar codes (e.g. Postfix's 'queue lifetime exceeded' is logged differently but has the same meaning).
Destination server returned 4.x.x for 48+ hours straight (greylisting that never cleared, persistent throttling, destination down for maintenance, network unreachability); DNS resolution for the destination failed repeatedly; or destination MX was misconfigured and connection timed out on every attempt.
How to Fix 550 4.4.7
- 1
Look at the original deferral reason in your queue logs
Exchange's NDR usually includes the most recent deferral reason as part of the bounce body. Read it — that's the actual problem. 4.4.7 is just the umbrella saying 'we kept retrying and never got through.' The underlying 4.x.x cause tells you what to fix.
- 2
Verify the recipient's DNS resolves
Run an MX lookup on the recipient's domain. If the domain has no MX (or the MX records point to non-responding servers), every retry will fail. This is sometimes a recipient-side outage that's been ongoing for days; sometimes it's a typo in the recipient address (sending to user@gmial.com keeps failing because the domain barely exists).
- 3
Check if the recipient's MX is up
Try a live SMTP connection to the recipient's MX (telnet to port 25 or use online MX testers). If the MX is unreachable or returning 4.x.x to everyone, the recipient is having an outage and the cleanest path is just to resend later when their server is back.
- 4
Re-send the message manually
4.4.7 is final for the original attempt, but you can manually re-queue the message. Wait until you've confirmed the underlying cause (recipient outage, throttling, etc.) is resolved, then send again. If the cause is your own reputation/throttling, fix that before re-sending.
- 5
If this is happening to many recipients, audit your sending IP reputation
If 4.4.7 is widespread across many destinations, your IP may be on a soft-block at multiple receivers (each returning 4.x.x for days). Check SNDS for Microsoft, Postmaster Tools for Gmail, and the Blacklist Checker (coldrelay.com/tools/blacklist-checker) for major DNSBLs. Fix the reputation issue and re-send.
References
550 4.4.7 in the Cold Email Context
550 4.4.7 in cold email is usually a downstream consequence of one of two upstream problems: (1) the recipient's MX has a long-running outage (uncommon for major providers), or (2) your sending IP is being soft-throttled at the recipient for the entire retry window. The second case is the cold-email-relevant one — if your IP is on a soft-block at Microsoft or Gmail, every retry returns 4.x.x for days until Exchange's window expires. The structural fix is dedicated IPs with healthy reputation so soft-blocks don't accumulate, plus monitoring that catches reputation drops early. ColdRelay's Servers page surfaces per-IP reputation and bounce-rate metrics; the Sends log flags repeated deferrals so you can intervene before they accumulate to 4.4.7.
Frequently Asked Questions
Why does Exchange use 550 instead of 421 for expired messages?
By the time Exchange gives up, the message has been pending for 48+ hours and the sending user needs to know it failed permanently. 4.x.x semantically means 'try again later' — once retry has been exhausted, the message can't try again, so the code converts to 5.x.x semantics even though the underlying enhanced code keeps the 4.4.7 form.
Can I shorten the Exchange retry window?
On-premises Exchange administrators can tune the queue lifetime. Exchange Online's queue lifetime is fixed by Microsoft (48 hours for most cases). Shortening doesn't help the sender — it just means earlier hard-bounces.
Is the message lost?
Yes — once 4.4.7 fires, the message is permanently gone from Exchange's queue. You'll need to manually re-send. Most cold email platforms surface this in their UI; check your sends log for 4.4.7 bounces and decide whether to re-send based on whether the underlying cause is fixed.
What's the relationship between 4.4.7 and greylisting?
Greylisting is a recipient-side anti-spam tactic that initially returns 4.x.x to unfamiliar senders, expecting legitimate mail to retry (spammers usually don't). Persistent greylisting that never clears can cause 4.4.7. Most modern receivers don't greylist anymore because of this exact failure mode.