Why is a 4.x.x code in a permanent bounce?

The enhanced code describes the temporary failures behind it, while the bounce itself is final because the queue lifetime ran out.

Should I resend after 4.4.7?

Yes, once you have checked the last error and the cause is fixed. The server will not try again on its own.

Can I make my server retry longer?

Yes (Postfix `maximal_queue_lifetime`), but most deferrals that last five days need a fix, not more time.

4.4.7 bounce: delivery time expired

4.4.7Delivery time expiredTemporary: the sender retries

Typical wording

550 4.4.7 QUEUE.Expired; message expired

What it means

RFC 3463 names X.4.7 "Delivery time expired". Your sending server held the message in its queue, retried delivery repeatedly, and reached its maximum queue lifetime (five days by default in Postfix and Sendmail, often shorter in hosted services) without success. It then gave up and sent you this notice. The example shows how Exchange typically words a queue expiry.

The odd mix of a 5xx reply with a 4.x.x enhanced code is normal: the delivery attempt is over (so the bounce is final), but the underlying failures were all temporary. The real reason is the last deferral, which the bounce usually quotes under a "last error" or "Diagnostic-Code" field, for example 4.4.1 no answer from host or a 4.7.x greylisting or throttling reply.

You may also see 5.4.7 from systems that report the final failure in the permanent class. Both mean the same thing: nothing more will be tried, and you need to fix the cause and send the message again.

Likely causes

The recipient’s mail server was unreachable for days (see 4.4.1 and 4.4.2).
The receiver kept deferring your mail with temporary policy replies such as rate limiting or reputation throttling.
A DNS failure for the recipient domain lasted longer than your queue lifetime (see 4.4.3).
Your own relay or smart host was down, so messages sat in a local queue until they expired.

How to fix it

Find the last error in the bounce. It names the actual problem; 4.4.7 only says time ran out.
Fix that underlying cause, for instance a blocked port, a DNS problem, or a reputation issue, then resend the message.
If the receiver kept rate limiting you, slow your sending and check your IP and domain reputation before trying again.
If messages expire for many destinations, check your own outbound connectivity and smart host health first.

Checks that apply

Your domain or sending IP (fills in the checks below)

TCP Port Test Tests whether the recipient MX accepts connections on port 25 now, the most common reason messages time out.
Blacklist Check Checks your sending IP on blocklists, since deferrals from listed IPs often run until expiry.
MX Lookup Confirms the recipient domain still has working MX records your server can reach.

FAQ

Why is a 4.x.x code in a permanent bounce?: The enhanced code describes the temporary failures behind it, while the bounce itself is final because the queue lifetime ran out.
Should I resend after 4.4.7?: Yes, once you have checked the last error and the cause is fixed. The server will not try again on its own.
Can I make my server retry longer?: Yes (Postfix `maximal_queue_lifetime`), but most deferrals that last five days need a fix, not more time.

All 191 bounce codes