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
Keep the feedback coming. We appreciate continued details as to which option(s) would work best. The trick is balancing notifying users (who usually can’t take action, but certainly want to know when messages are delayed) vs. notifying the admins (who may or may not be able to take action but may not want such a quick notification — for example if they are responsible for a server that is down for planned maintenance or a DNS change which takes time to propagate). We would certainly like for this to be somewhat configurable in the future, but also are considering alternatives to the current 48 hours.
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.
Remo Weber commented
Please fix this issue: serious problem with serious money implications. I only can support the other statements here.
I'm surprised this hasn't been implemented yet. Come on Microsoft, this should be available.
Francis St-PIerre commented
Please fix this issue. It has important consequences for urgent matters. Only for this I regret swicthing our business to the exchange service. We just lost a sale because of this. We sent our quote for the job in time, but there was an error in the mail adress, we received the failed delivery message after the last day of wich we could postulate on the job. Serious problem with serious money implications.
Sascha Stops commented
Agreeing with others here. We enforce TLS using a mail flow rule and users get only notified 48 hours after they send the email. This is not feasible. There should be an option to notify the user after the first or second failed attempt of delivery. Users might be sending urgent messages and do not get notified if they don't get through.
Matt Skorupski commented
More than 2 years later...Has this topic been forgotten? 2 day-retry may have been necessary in the past with lag and internet connectivity issues. These days of instant and reliable connectivity, if something is down for more than two hours a notice should be sent.
Paul Kecun commented
Chiming in. We're enforcing TLS everywhere and we don't even get a delivery delayed message - just a bounce after 2 days.
I'd expect a non-TLS negotiation to be rejected immediately, not queued for 2 days because STARTTLS was unavailable.