4.4.7: The message expired in the queue

At a glance

• Type: the end of retrying (RFC 3463 §3.5, delivery time expired). The sending server tried again until the message expired, then returned it; nothing is retried after this report.
• Basic code: varies; the enhanced code is the part that identifies the problem.
• Enhanced code 4.4.7: “Delivery time expired” in the IANA registry (RFC 3463), in the group network and routing status (RFC 3463 §3.5).

Your mail server tried to deliver the message for as long as it is allowed to, failed every time, and then gave up. The 4.4.7 is not the real problem; it only says time ran out. The real cause is the error the server got on its last attempts.

What it means

RFC 3463 §3.5 defines X.4.7 as "delivery time expired": the message was considered too old, because it stayed on a host too long or its time-to-live ran out. The RFC adds that, where possible, the code for the actual problem should be returned instead.

Sending servers retry temporary failures. RFC 5321 §4.5.4.1 says the interval should generally be at least 30 minutes and the give-up time generally at least 4 to 5 days. When that time is reached, the server sends an expiry notice. It may carry the transient class 4.4.7, as Microsoft does, but the message will not be retried after that.

Common causes

• The recipient's server was unreachable for the whole period: down, or blocked by a firewall.
• The recipient domain's MX records were wrong or pointed to a host that did not answer.
• The receiving server kept deferring the message with a 4xx reply, for example for rate limits or reputation, such as 421 4.7.0.
• DNS lookups for the recipient domain kept failing temporarily.

How providers use it

Microsoft 365 reports this as 4.4.7 QUEUE.Expired and explains that the sending server kept retrying until the expiration time. Microsoft advises looking at the last error recorded for the message, and lists DNS, MX and firewall problems on the receiving side as typical reasons. Exchange Online also uses 5.4.300 for an expired message (Exchange Online NDR reference).

How to fix it

1. Find the last error. Read the whole NDR, or the sending side's queue log or message trace, for the reply given on the final attempts.
2. Fix that error, using the page for its code. A rate or reputation deferral needs a different fix from an unreachable server.
3. If there was no reply at all, check the recipient's MX records with dig MX example.com and test whether their mail host answers on port 25.
4. If you run the receiving domain, check your MX records, firewall rules and the health of your mail server for the period the message was queued.
5. Once the cause is fixed, send the message again; it is not retried on its own.

What to do with the address

Keep it until you know the cause. An expiry says nothing about whether the mailbox exists. If the last error was a permanent one about the address, act on that code instead.

Related codes

• 5.4.4: Unable to route: no mail server found for the domain
• 421 4.7.0: Temporarily refused: reputation, DNS or TLS
• 554 5.4.6: A mail loop was detected

See every bounce code in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.