Table of Contents
Set Message Expiration Timeout Interval From 12 hours to 1 Day
I haven’t heard of a demand for a customizable message expiration timeout interval but apparently the need exists. At least, according to message center notification MC441064 (updated 8 December), Microsoft is rolling out a change to enable the capability to tenants now, delayed about a month from the original intent to deploy between mid-October and mid-December. The change is covered by Microsoft 365 roadmap item 93315.
MC441064 says that the ability to customize the message expiration timeout interval is a common request. This might be true for large enterprises, who tend to make these kinds of request, but I’m unsure if the same is true for the majority of Microsoft 365 tenants where administrators often leave default settings in place simply because there are too many jobs to be done.
Expiring Queued Messages That Cannot be Sent
In any case, the message expiration timeout interval governs how long the Exchange transport service holds a message when it cannot be delivered. Normally, the transport service processes messages immediately after sending by making a connection to the destination server and passing the message to that server. Transient errors like network glitches or server unavailability can stop a message leaving Exchange Online, and when this happens, Exchange Online puts the message in a retry queue and attempts to deliver it periodically (after 30 minutes initially and then after every hour).
If a message expiration timeout interval didn’t exist, Exchange Online would keep on retrying to send failed messages from here to eternity. The function of the timeout interval is to set a period after which Exchange Online should inform the sender that it cannot process the message for some reason. The key thing in setting the expiration timeout is to give Exchange sufficient time to allow transient errors to subside and allow queued messages to travel to their destination while not taking so long that the sender is left in limbo with no indication that their message is stuck. After a while, an email can become like a dead fish: it’s still a message but its contents are no good because so much time has elapsed.
Setting a Message Expiration Timeout Interval
The default message expiration timeout interval for Exchange Online is one day. This is a reasonable balance between the time needed to resolve issues and a message still being valid when delivered. The change being made allows tenant administrators to set the interval to any value between 12 and 24 hours. Reducing the interval means that Exchange will expire queued messages faster. Users will receive a non-delivery response (NDR) when their messages expire and because this happens sooner, users will be able to action the problem faster. For instance, they might decide to send the email to a different address.
To configure the message expiration timeout interval, use PowerShell to connect to the Exchange Online management module and run the Set-TransportConfig cmdlet. For instance, to set the interval to 12 hours and 30 minutes, the command is:
Set-TransportConfig -MessageExpiration 12:30:00
To check the value, use the Get-TransportConfig cmdlet:
Get-TransportConfig | Select-Object MessageExpiration MessageExpiration ----------------- 12:30:00
Figure 1 shows details from an NDR returned to a user after changing the message expiration timeout interval (in this instance, to 12 hours). The original message is dated 13:24 on December 9. The NDR arrives at 13:29 on December 10. We won’t quibble about the extra five minutes!
Things are a little different for on-premises Exchange Server as administrators have more control over how the transport service works. Here’s Microsoft’s advice about configuring message intervals for Exchange 2019.
Message Expiration Timeout is Now Tenant Choice
Any tenant can customize the message expiration timeout interval. However, I suspect that those who do will be organizations that want users to know as soon as possible if problems exist in sending email. Reducing the interval to 12 hours might help, but I guess that depends on if the user is available to receive the NDR and take action to reprocess the failed message.
Make sure that you’re not surprised about changes that appear inside Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.