4.4.7: the message expired before it could be delivered

What the bounce means

A 4.4.7 status means the message sat in your server's outbound queue, was retried repeatedly, and hit the end of its retry window without ever being accepted. The wording differs by server, and the SMTP reply code it appears with varies too; the enhanced code 4.4.7 is the part to trust.

The important thing to understand is that 4.4.7 is a summary bounce, not a cause. It does not tell you what went wrong; it tells you that whatever went wrong kept going wrong until your server stopped trying. The actual cause is the temporary error each retry ran into, and a well-behaved bounce quotes it: read the NDR text for the last error the queue recorded. It is usually one of a connection timeout (nothing answered), a greylisting response (the receiver asked your server to come back later, then never let it in), or a deferral (the receiver was overloaded, rate-limiting, or temporarily distrusting the connection).

How long servers retry before giving up

Retry windows are set by whoever runs the sending server, so there is no single answer. Windows of one to five days are common, with attempts spaced out on a backoff schedule: frequently at first, then every few hours. Many servers also send a delay warning partway through, so a “your message is delayed” notice followed days later by a 4.4.7 is the same story told twice. The gap between when you sent the message and when the expiry bounce arrived tells you roughly what window your server used.

What to do about it

• Find the underlying tempfail first. Read the quoted error in the bounce. A timeout points at their infrastructure; a greylist or deferral response usually names the receiver's reason in its text. Fixing or waiting out that error is the whole job; the 4.4.7 itself needs nothing.
• Then resend. Unlike a live tempfail, an expired message is gone from the queue. Nothing retries after a 4.4.7. Once the underlying problem clears, send the message again yourself.
• If it keeps happening to one domain, the pattern is the answer: repeated expiries against a single domain almost always mean that domain's mail infrastructure is down, misrouted, or silently dropping your connections. Contact the recipient another way; their own team may not know their mail is unreachable.
• If it is happening to many domains, turn the suspicion around: when unrelated destinations all expire, the common factor is your server's outbound path, not five different receivers failing at once.

Frequently asked

Does my server keep retrying after a 4.4.7?

No. The 4.4.7 is issued at the moment the queue gives up, so the retries are over and the message has been dropped. Once the underlying problem clears, you have to resend the message yourself; nothing happens automatically from here.

How long do mail servers retry before expiring a message?

It varies by server and by how the administrator configured it. Retry windows of one to five days are common, with attempts spaced out on a backoff schedule. The delay between sending a message and receiving its 4.4.7 bounce tells you roughly what window the sending server used.

Is 4.4.7 my fault or the recipient's?

The code itself does not say; it only says the retries ran out. Read the underlying error quoted in the bounce text. A connection timeout or an outage points at the receiving side, which is the usual case. If messages to many different domains are all expiring, look at your own server's outbound path instead.

Why does the bounce arrive days after I sent the message?

Because your server spent those days retrying. Temporary failures do not bounce immediately; the message sits in the outbound queue while the server retries on a schedule. The 4.4.7 only exists because every one of those attempts failed, so it arrives at the end of the retry window, not at the start.