Allow Settings for Message Expiration Timeout Interval and NDR
For some error codes related to sending mails, the senders may receive the NDR immediately. However, for some other error codes, the mail server marks the undeliverable messages as a temporary error and the senders doesn't immediately receive an NDR. Instead, Exchange Online repeatedly tries to deliver the message over two days. Only after two days of unsuccessful delivery attempts does the sender receive this NDR.
For some time critical businesses this is not acceptable. The user has to be informed very quickly (<6 hours) that his Mail was not delivered by now. Then the user can phone the recipient or sent the mail to another address. I do not care if exchange online continues trying to send the message after 6 hours, but the user has to be informed.
Exchange Server 2016 an older allowed customization of the Message Expiration Timeout Interval and NDR Settings. Please add this to ExchangeOnline
Today, based on feedback, we’ve lowered the timeout to 24 hours. In the future, we are planning more improvements, although we do not have any dates or details to share at this time. Thank you for the continued feedback.
I've had this problem, too.
When my mail was sent, Exchange Online didn't check the other party's MX records, and tried to post it for 12 hours.
The equivalent of my users need to send 12 hours before they know that the mail sent failed!
It's really not being received!
For you looking for a work around, it's possible to do something on your own in powershell. By default, you won't recieve a NDR until 24 hours later. Instead, you can query those emails being pending due to the lack of TLS and pick them up and send a custom email to the sender. I just did this for my own organization as we have the same requirement due to GDPR.
Looking to implement forced TLS the option to lower the timeout is also nessesary in my business. Please advice if this has been implementet or if there is a work around.
Hello, We received a NDR 24 hours after a message was sent. If there could be a setting to configure in our tenant related to Message Expiration Timeout Interval, that would be helpful. Or lower the time out to 4-8 hours.
This is surely a feature that more or less is required for Forced TLS to work. We cant wait 2 days before getting a notification. That could lead to a company having to close down. In our office people would send over the error message to IT who would then be able to recommend another way to contact the client. Admins themselves dont care about individual mails not being delivered - the users do and therefore it should be them who receives a message after a set amount of hours. GDPR forces us to implement forced TLS, and we would prefer not to use a portal solution.
Martijn Hoogmoed commented
Hi, and thanks for considering..
We are implementing Forced TLS for a few of our clients and as such we need to be able to set the NDR time as such. The client indicated he wanted 1 hour because it takes 2 whole days before he is notified that his mail cant be deliverd because of the TLS restriction.
Barry Fee commented
I think our business users would like to know immediately if their message did not get delivered, we could then opt to send via post or call the recipient to discuss.
Also, we would like to follow up any issues with the mail provider and Microsoft. What should not be happening is we find out after 2-3 days it was not sent as this is unhelpful when you are dealing with time dependant legal matters.
Benny Hui commented
It is a concern if the user receive the NDR after 48 hours. Recommend to inform user after 4 - 6 hours about the pending.
Same problem : No excuse for the bounce to be after 48 hours with no warning to the sender until the queue expires.
We can not wait 48 hours to have an error of no delusion. Office 365 is for professionals!
This is ridiculous- electronic email bouncing and not notifying the sender it has bounced for two days —let’s the client think they have been ignored - this is not acceptable in today’s world- clients demand more from us- Microsoft needs to fix.
Paul Mead commented
So 3 years later.....it seems this is still not possible. Unreal - particularly when Exchange on-premise this is a configurable option.
Paul K commented
I can't believe this still isn't supported, I honestly thought after the EU regulation changes in 2018 that enough people would be screaming for this that it would have been made a priority. There's no excuse for the bounce to be after 48 hours with no warning to the sender until the queue expires. If the timer can't be changed then there should be a toggleable option for an instant bounce if the receiving server indicates STARTTLS not available.
Just switched to Exchange Online to get rid of an on-premises mail server. The company owner just notified me that communication to very important client was delayed for the 2 day period without notification. I was shocked to find that I can't configure this, when I could do it in Kerio Mailserver. I am SO NOT thrilled to realize that all the work migrating to O365 was for nothing because a possible 2 day delay is simply unacceptable. Thanks Microsoft.
Please prioritize and fix this issue. It is really a big problem when trying to ensure encrypted transmissions. We cannot wait 2 days for TLS enforced connections to fail, when sending to non-TLS supported recipients - it should be instant. The server will not begin supporting TLS just because it tries for 2 days. We use Office Message Encryption when it fails for non-TLS supported recipients, but having to wait several days to be adviced an e-mail cannot be delivered is unacceptable for our usage. Thank you!
Andrew Nimon commented
Yes, this is very important! I assumed that this was possible but I just didn't know how to do it. My clients need this functionality to make Office 365 viable when email delivery is critical.
When the O365 Help desk informed me that there was no way to configure O365 to change this behavior I was flabbergasted. How could a system that is touted as a "business solution" allow such a glaring lack of functionality to have even existed in the first place let alone not fix it after it was reported 2 years ago.
I can no longer recommend Office 365 for serious business use because of this gross inadequacy.
More than 2 years later... IT administrators need the ability to configure the Message Expiration Timeout Interval and NDR settings. 2 day default value is too long time.
Don Hogan commented
Waiting 48 hours to receive an NDR is not acceptable. Especially with no notification to the sender, that their message is stuck in the queue. We have already lost millions by missing proposal deadlines because no one knew that their message was not delivered for 2 days. Their needs to be an adjustment put in place to allow Online Exchange Message Expiration Timeout to set to 2 - 4 – 6 hours (rather than 2 days) with a sender notification every hour that their message is not delivered yet.
In this day and age, 48 hours is much too long to notify the sender. Please make this configurable, or introduce another warning after 4-6 hours so the sender knows there's a potential problem prior to two days later.
Fabian Melchior commented
Mail is unreliable now. 48 hours for a NDR is way too long these days. This is a big issue for my customers. If this problem isn't going te be solved asap, many of my customer will leave Office365 and use other mailsystems.
If the interval time can't be changed at the moment, please profit a delaynotification after 1 hour, with the message that the emailserver will be try delivering the mail for teh next 48Hours.