4.4.7 Message Expired: Why a Bounce Arrives Days Later

A 4.4.7 "message expired" bounce, sometimes written "delivery time expired", means your message waited in the sending queue until the time limit ran out and the sender gave up. Every delivery attempt failed to complete, so the bounce arrives long after you sent, often a day or more later. The cause is almost always on the recipient side: a mail server that does not answer, a domain with broken DNS, or constant deferrals. Before you resend, check the recipient domain's mail servers, because sending to a server that never answers will expire the same way. SimpleVerifier checks those servers before you send. Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off, and 100 free checks.

What the code says

RFC 3463 defines the enhanced status X.4.7 as "delivery time expired": the message was considered too old by the rejecting system, either because it stayed on one host too long or because the sender's time-to-live was exceeded. The RFC adds that, where possible, the specific underlying problem should be reported instead, which is why a 4.4.7 often feels vague.

Microsoft's Exchange Online nondelivery report documentation, which we read on 10 November 2026, lists "4.4.7 Message expired". It says the message in the queue expired: the sending server tried to relay or deliver it, but the action was not completed before the expiration time. It adds that the code can also indicate that a message header limit was reached on a remote server, or that some other protocol timeout occurred during server communication. Its guidance is that this usually points to an issue on the receiving server, and to check the validity of the recipient address and whether the receiving server is configured correctly.

You will see variations such as:

550 4.4.7 QUEUE.Expired; message expired
4.4.7 Message delayed

The first digit is 4, which is a temporary class, but the notice you receive is a final failure. That mix is why 4.4.7 confuses people. Our reference page is /smtp/550-4-4-7.

Why it happens: the usual causes

Every cause comes down to "the message could not be handed over before time ran out":

1. The recipient's mail server never answers. The domain has MX records, but the host is down, firewalled or gone. Each attempt times out.
2. The domain has no working mail servers. An expired or parked domain, or one with misconfigured DNS, gives no place to deliver.
3. Constant deferrals. The server answers every attempt with a temporary refusal, for example greylisting, rate limiting or a full queue on its side, until the clock runs out. See greylisting and the 450 reply.
4. Protocol timeouts mid-conversation, which Microsoft also lists.
5. Too many recipients on one message, which can slow handling on the receiving side.
6. A temporary problem on your side, such as a blocked outbound port 25 on a cloud server. See cloud providers that block port 25.

Does it mean the address is bad?

Not by itself. The notice says delivery did not complete. It does not say the mailbox does not exist, because the sender never got far enough to ask. That makes it different from 550 5.1.1 user unknown.

What to do depends on the pattern:

Pattern	Reading	Action
One address, once	A server problem at the time	Retry once on the next send
One address, repeatedly	Dead or unreachable	Suppress
Many addresses at one domain	The domain's mail setup is down or broken	Pause the domain, check MX
Many addresses across domains	Your own sending path or throttling	Check your sending setup and rate

The bounce domain hotspot finder groups bounces by domain so you can see which of these you have.

Step by step

1. Read the full notice. Look for the recipient domain and any underlying text such as "connection timed out" or "no route".
2. Group by domain. Find out whether it is a few domains or a wide spread.
3. Look up the domain's mail servers with the bulk MX lookup. No MX, or MX hosts that do not resolve, explains the expiry.
4. Check DNS health with the email DNS error checker for domains you send to often.
5. Do not resend straight away to the same domain. Wait and retest, or pause the contact.
6. Check your own side if the spread is wide: outbound port 25, your sending tool's retry settings, and your sending rate. A very short retry window can expire messages sooner than necessary.
7. Suppress what stays dead. An address that expires on two or three separate sends is not reachable. Remove it. See removing repeat soft bounces.
8. Count it correctly. These notices can be counted differently by different tools: some treat them as soft bounces, some as hard. Check how yours treats them before you compare bounce rates. Hard bounce vs soft bounce explains the usual conventions.

Why it hurts a cold email sender

Because the notice comes days later, you may have sent step two or three of a sequence to an address that was never reachable. Each of those attempts sits in a queue, and the eventual failure counts against you. Cold lists built from scraped domains contain many parked and abandoned domains, and these are a typical source of expiry. Our post on why cold emails bounce lists the common causes.

Prevention: check the domain before the first send

The part of this problem that is preventable is the dead-domain and dead-server case. A verifier looks up the recipient domain's mail servers, connects to them, and asks whether the server would accept mail for the address. A domain with no mail server, or one that does not answer, comes back as invalid or risky, so you know before the first send instead of days later.

What it cannot promise: it cannot predict a deferral that starts after the check, and a server that is only temporarily down at check time may come back risky rather than definite. Treat risky rows as "test in a small batch". See accept-all vs unknown results, and why verified emails still bounce for the limits of any check.

A routine that works:

• Verify each list when it is built, and again before a large send if it is older than a few months.
• Look at the domains behind invalid and risky results, because a cluster points to a broken domain.
• Send risky rows in a small batch and watch for late bounces for several days.
• Keep your sending tool's retry window at its normal setting.

Check one address with the free email checker, or run a file through /verify.

How SimpleVerifier fits

SimpleVerifier Pro is $39 a month. The first 100,000 checks a month run at full speed, then slower, and you are never cut off. You can try 100 free checks, no card. See pricing.

What not to do

• Do not resend to the same unreachable domain in the hope it works this time.
• Do not delete an address after one expiry. The recipient's server may just have been down.
• Do not shorten your retry window to get faster failure. It makes valid mail fail too.
• Do not compare bounce rates between tools without checking how each counts expired messages.

Bottom line

4.4.7 means a message waited until its time ran out. The address may be fine, but the server behind it did not accept delivery in time. Group the bounces by domain, check the mail servers, suppress what stays dead and verify lists before the first send. The bounce doctor is a useful next step if late bounces keep arriving, and the 100 free checks on /verify will show how many of your domains have no working mail server.