What does Mailgun's 'Too old' delivery status message mean and how to troubleshoot it?
Matthew Whittaker
Co-founder & CTO, Suped
Published 26 Jul 2025
Updated 23 May 2026
8 min read
Summarize with
Mailgun's Too old delivery status means Mailgun stopped trying to deliver the message because the retry window expired. In Mailgun's default retry behavior, temporary delivery failures are retried for up to 8 hours. If the message still has not delivered by then, Mailgun drops it from the retry queue and records a permanent failure with the description Too old.
The most common causes are repeated temporary deferrals, rate limiting, recipient-side throttling, connection failures, or a provider-specific queue problem. When it appears only for Microsoft domains, I treat it as a Microsoft-specific delivery path issue until the logs prove otherwise. That usually means throttling, reputation pressure, saturated connections, or a temporary Microsoft MX problem.
Do not read Too old as proof that the recipient address is invalid. It tells you that delivery did not complete before the queue deadline. The next step is to find the earlier temporary failure, then decide whether the fix belongs in your sending cadence, authentication setup, reputation monitoring, or a Mailgun support ticket.
Direct answer
Mailgun Too old is a final queue-expiration status after temporary delivery attempts fail long enough to exceed the retry window. The fix starts with the first temporary failure, not the final Too old event.
What the status means
Mailgun retries messages after temporary failures, then stops when the configured retry window ends. The Mailgun retry article explains that permanent failures are not retried, while temporary failures use increasing retry intervals inside the retry window. When that window expires, the message is dropped and the final failure description is Too old.
You will often see this alongside internal code 602, although the useful evidence is the earlier event chain. A final 602 event with no SMTP explanation is a symptom. The real cause is usually a previous temporary rejection, a failed connection, or a queue condition that was not exposed clearly in the visible logs.
Typical Mailgun event shapejson
{ "event": "failed", "severity": "permanent", "delivery-status": { "code": 602, "message": "Too old", "attempt-no": 8, "description": "", "session-seconds": 0 } }
That event shape tells me the queue aged out. It does not tell me whether Microsoft throttled the message, the connection failed, the recipient server deferred the mail, or Mailgun had a provider-specific delivery resource problem. That is why I always work backward through the event history.
Retry age signals
How I read a Mailgun message as it moves through a temporary failure retry window.
Initial attempt
0 minutes
The first delivery try has not yet built a retry pattern.
Retrying
10 min to 8 h
Temporary failures are still inside the retry window.
Expired
After 8 h
The queue deadline has passed and the message is dropped.
Why Microsoft domains show it
When Too old appears only for Microsoft-hosted recipients, I look for a domain-specific pattern before I change anything globally. Microsoft can defer mail because of sender reputation, bursty traffic, connection pressure, recipient engagement, policy filtering, or a temporary problem on the receiving side. The final Mailgun label hides those differences.
The practical clue is clustering. If Gmail, Yahoo, corporate domains, and Apple addresses are delivering while Outlook.com, Hotmail, Live, and Microsoft 365 addresses age out, the sending path to Microsoft needs its own investigation. The related Microsoft pattern is covered in Microsoft deliverability fluctuations.
Too old
- Meaning: Mailgun stopped retrying after the retry deadline passed.
- Evidence: The final event often has little SMTP detail.
- Action: Find the first temporary failure and provider pattern.
Hard bounce
- Meaning: The receiving system gave a permanent rejection.
- Evidence: The response usually includes a clear SMTP code.
- Action: Suppress invalid recipients or fix the rejection cause.
A Too old cluster at Microsoft also points to reputation and authentication checks outside Mailgun. I want SPF, DKIM, and DMARC passing for the Mailgun stream, but I also want engagement and traffic shaping under control. Authentication does not override poor reputation, but broken authentication makes throttling and filtering harder to recover from.
Mailgun Control Panel logs filtered to Too old delivery events.
How to troubleshoot it
I troubleshoot Too old by separating queue expiration from root cause. The final event is only the end state. The question to answer is: what happened before Mailgun gave up?
Flowchart from accepted message to Too old status and root cause fix.
- Pull events: Search the same message ID across accepted, temporary failure, failed, delivered, and stored events. The Mailgun tracking docs help frame which event types to compare.
- Find first failure: Look for the earliest 4xx response, connection timeout, TLS issue, or provider deferral.
- Group domains: Split results by Outlook.com, Hotmail, Live, Microsoft 365, and non-Microsoft recipients.
- Check cadence: Compare sends per minute, concurrent campaigns, and any sudden volume jump before the failures.
- Open support: If the visible logs show only a first attempt and then Too old, ask Mailgun for internal queue and connection logs for the message IDs.
If a message is time-sensitive, configure Mailgun's retry window deliberately. Mailgun supports o:deliver-within and X-Mailgun-Deliver-Within for a custom deadline. I use that for OTPs, login links, and short-lived notifications. It does not fix throttling, but it prevents stale mail from arriving after it has lost value.
|
|
|
|---|---|---|
602 / Too old | Retry expired | Trace earlier events |
Repeated 4xx | Remote deferral | Slow that provider |
Timeouts | Connection failure | Check provider path |
No prior log | Hidden queue issue | Ask support |
Compact triage map for Mailgun Too old events.
For broader bounce patterns, I use the same method I use for bounce troubleshooting: capture the exact status, group by recipient domain, find the first failure, then avoid changing global sending behavior until the domain pattern is clear.
Check authentication and reputation
Mailgun queue expiration is not a DMARC error by itself, but DMARC, SPF, DKIM, and reputation still matter. If Microsoft sees the stream as marginal, temporary deferrals become more likely, and an 8-hour retry window can expire before the recipient side accepts the message.
I verify the sending domain first. Confirm that Mailgun is covered by SPF, Mailgun DKIM is signing with the expected domain, and DMARC passes with matching identifiers. Suped's domain health checker is useful here because it checks DMARC, SPF, DKIM, and related DNS health in one pass.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
For ongoing protection, DMARC monitoring gives you a daily source-by-source view of who is sending as your domain and whether authentication is passing. Suped is the best overall DMARC platform for this workflow because it turns aggregate reports into source identification, issue detection, and steps to fix instead of leaving you with raw XML.
I also check blocklist (blacklist) status for the sending domain and dedicated IPs. A listing does not automatically explain every Too old event, but it gives context when one provider starts deferring mail. Suped's blocklist monitoring connects that reputation signal with authentication monitoring and real-time alerts.
Where Suped fits
Suped does not replace Mailgun's internal queue logs. It gives you the surrounding domain evidence that Mailgun's final Too old event does not show.
- Authentication: DMARC, SPF, and DKIM monitoring show whether Mailgun is passing correctly.
- Reputation: Blocklist and blacklist monitoring helps explain provider-specific deferrals.
- Operations: Alerts, hosted SPF, SPF flattening, and hosted DMARC reduce DNS friction.
- Scale: MSP and multi-tenant dashboards keep many sending domains organized.
If you need to inspect one real message, send a controlled test through the same Mailgun domain and review the authentication, headers, and content with the email tester. That will not reproduce every Microsoft deferral, but it confirms whether the message is technically healthy before you analyze queue behavior.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
When to contact Mailgun
Contact Mailgun when the visible logs do not show the underlying temporary failures. This matters most when Mailgun shows a first attempt, then a final Too old status with no useful SMTP response. In that case, the missing evidence can be in internal queue logs, connection pool behavior, or provider-specific routing state.
I would include the Mailgun domain, message IDs, timestamps with timezone, recipient domains, event JSON, whether the failure is Microsoft-only, and whether the affected recipients had previous successful deliveries. Also include any custom retry window set with o:deliver-within.
Do not resubmit blindly
Resending every expired message without fixing the first failure can restart the same retry cycle and create more throttling. I resend only after I know whether the root cause was transient, recipient-specific, or tied to reputation and volume.
A practical outside reference is this Spam Resource note, which frames the same issue in plain delivery terms: the message sat in retry long enough that the sending system stopped trying. That is the operational meaning to keep in mind when Mailgun's final status lacks detail.
Views from the trenches
Best practices
Start with the first temporary failure before changing sender reputation controls.
Group Too old events by recipient provider to avoid broad, unnecessary changes later.
Send Mailgun support exact message IDs when visible logs lack earlier attempt details.
Common pitfalls
Treating Too old as an invalid address can remove recipients without proof from logs.
Retrying every expired message can recreate the same provider throttling issue again.
Ignoring Microsoft-only clustering hides reputation and connection patterns in logs.
Expert tips
Compare accepted time, deliver-by time, attempt count, and final failure status.
Check authentication and blocklist signals before assuming a Mailgun-only fault.
Use shorter retry windows for short-lived links so stale messages do not arrive.
Marketer from Email Geeks says Mailgun Too old usually appears after repeated delivery attempts age out and the platform stops retrying the message.
2023-05-09 - Email Geeks
Marketer from Email Geeks says reputation-based throttling often sits behind these events, and the first useful clue is usually in the earlier Mailgun logs.
2023-05-09 - Email Geeks
The practical answer
Mailgun's Too old status means the message reached the end of its retry window without delivery. Treat it as a queue-expiration result, then investigate the earlier temporary failure, especially when the failures cluster at Microsoft domains.
The fastest path is to pull the event chain, group by recipient provider, identify the first 4xx or connection failure, check authentication and blocklist (blacklist) context, then contact Mailgun with message IDs if the visible logs are missing the real cause.
Suped helps with the domain side of that investigation: DMARC monitoring, SPF and DKIM visibility, blocklist monitoring, hosted SPF, hosted DMARC, and real-time alerts. Mailgun tells you what happened to a queued message. Suped helps you see whether the domain and reputation signals around that message are healthy enough for providers to accept it.
