Most Unix mailers have a feature where they periodically send people warning notes about email messages that haven't been delivered yet; Exim defaults to doing so roughly every 24 hours, for example (this is the delay_warning configuration setting, cf). I've come to believe that typical default values for when this happens are both too slow and too frequent, and should be rethought in today's Internet mail environment.

(Actually it looks like Postfix defaults to not sending delay notifications, so this may now be less common than I think.)

The reality of modern mail delivery, at least for us, is that mail delivery times are very skewed and likely quite bimodal. In particular, almost all of the mail sent through our outbound user email gateway is delivered to the remote SMTP server within a minute (and much of it is delivered within seconds) and most of the remainder is delivered within ten minutes. I have the strong feeling that people have come to expect this rapid email delivery, simply because it's what almost always happens.

In this environment, delaying initial notification of a delay for a day is not really what you want since a day is well after people expect their email to have been delivered. How soon the first notification should be sent depends on how mail delivery delays break down in your environment, so I recommend getting statistics. My gut feeling is that an hour is a good starting point under normal circumstances; when people hit an address that genuinely isn't accepting email, they'll probably get notified about it soon enough to know that they should take other steps.

(A related issue is giving people relatively prompt notification when they've misspelled a domain name into a variant that doesn't accept email. The hope is that they'll notice the mistake when they get the notification email and be able to resend their message soon enough to be useful. My unchecked intuition is that such misspellings are one of the significant sources of long term delayed email in our environment.)

However once we've sent one or two delay notifications I don't think there's much point in repeating them. My view is that by the time a day has gone by without a successful delivery, the person who sent the email is no longer really expecting it to get through any time soon. If getting the information through or getting a reply was important they'll probably already have taken alternate steps so further delay notifications are pointless, and if the email's not important the delay notifications are just noise in general. If you have a long message delivery timeout you might want to send another delay notification partway through, but certainly not one a day.

Of course all of this generously assumes that people actually see and read the delay notifications that your system sends them. If people filter them out or just reflexively delete them, you might as well not send them at all (although there may be political reasons to send them even though they'll get ignored). I don't have any information on this, although I have my suspicions.

PS: hopefully it goes without saying that you should only be sending delay notifications to your own local users.