SMTP 554 4.4.7: message delivery timed out after repeated attempts

554 4.4.7 is a 5xx permanent failure, but with an unusual origin: it's typically generated by your own sending MTA, not sent by the recipient's server. Enhanced code 4.4.7 means "delivery time expired" — your outbound queue attempted delivery repeatedly, kept hitting a temporary (4xx) condition, and finally gave up once it exceeded its maximum retry window (commonly 24–72 hours depending on MTA configuration).

Who is at fault

Depends entirely on what the underlying recurring 4xx condition was. 554 4.4.7 itself doesn't tell you the cause — it tells you a temporary problem never cleared in time. Check your queue logs for the actual 4xx reply that kept recurring before the final give-up.

The exchange

[Attempt 1, 00:00] 421 4.4.1 No answer from host
[Attempt 2, 00:15] 421 4.4.1 No answer from host
[Attempt 3, 01:00] 421 4.4.1 No answer from host
...
[Attempt N, 72:00] Maximum retry period exceeded
554 4.4.7 Message expired, delivery time exceeded (generated locally by sending MTA)

How the big three word the underlying recurring condition

This is one of the few conditions where all three providers look identical in the final bounce, because the final message doesn't come from them — it comes from your own mail system reporting that it stopped trying.

Diagnose it

$ grep "message-id" /var/log/mail.log | grep -B20 "4.4.7"

Pull the full delivery attempt history for the specific message, not just the final line — the repeated 4xx reply earlier in the log is the actual problem to fix.

Fix it, in order

1. Find the specific 4xx code that recurred across the failed attempts — this is the real underlying issue (connectivity, reputation throttling, recipient server unavailability).
2. Fix that underlying condition using the diagnostic steps for whichever specific 4xx it was.
3. Resend manually once the cause is fixed — the original message is gone for good once the queue expires it, so correcting the cause only prevents recurrence, it doesn't recover the specific failed send.
4. Check your MTA's retry window configuration — if this is happening often, a longer retry window buys more time for transient recipient-side issues to clear before you lose the message outright.

How retry windows vary by MTA — a cause worth knowing about directly

The exact point at which a 4xx condition turns into this final 554 4.4.7 depends entirely on your own outbound MTA's configuration, not on anything RFC 5321 mandates. Postfix defaults to a maximum_queue_lifetime of 5 days; Exim defaults its retry timeout around 4 days; many ESP-hosted sending platforms use shorter internal windows, commonly 24–72 hours, before formally reporting a message as expired back to your application. If you're comparing behavior across two sending systems and one seems to "give up" faster than the other on what looks like the same underlying 4xx condition, check each system's specific retry-window setting before assuming one network path is worse than the other.

An additional diagnostic step

$ mailq | grep -B5 "4.4.7|expired"

Checking your live queue for other messages approaching the same expiration threshold, rather than only looking at the one that already failed, can surface a developing pattern (several messages to the same domain all aging out together) before each one individually crosses the final deadline.

Why extending the retry window isn't free

A longer maximum retry window gives more time for a genuinely transient recipient-side issue to clear, but it also means a message sent toward a domain with a persistent, non-clearing problem sits in your queue consuming resources for longer before you get the clear signal that it has failed. For most senders the default window in a well-known MTA is a reasonable balance already tuned by people who've seen this trade-off at scale; change it only if you have specific evidence (a particular recipient domain with known multi-day outages) that justifies the trade-off for your traffic.

What not to do

• Don't treat 554 4.4.7 as information about the recipient. It's a report from your own system about its own retry exhaustion, not a rejection reason from them.
• Don't resend the identical message repeatedly immediately after seeing this. If the underlying 4xx condition is still active, you'll just rebuild the same failure history.
• Don't ignore a pattern of 4.4.7 failures concentrated on one recipient domain. That's a strong signal of either a persistent problem with their infrastructure or a reputation-based throttle on your side that never clears within your retry window.

MailPilot's deliverability monitoring tracks delivery attempts and underlying 4xx patterns per domain, so a queue timing out after days of silent retries is caught and explained well before you're staring at a final 4.4.7 with no context.