Designing an email system to guarantee delivery
- by GlenH7
We are looking to expand our use of email for notification purposes. We understand it will generate more inbox volume, but we are being selective about which events we fire notification on in order to keep the signal-to-noise ratio high.
The big question we are struggling with is designing a system that guarantees that the email was delivered. If an email isn't delivered, we will consider that an exception event that needs to be investigated. In reality, I say almost guarantees because there aren't any true guarantees with email. We're just looking for a practical solution to making sure the email got there and experiences others have had with the various approaches to guaranteeing delivery.
For the TL;DR crowd - how do we go about designing a system to guarantee delivery of emails? What techniques should we consider so we know the emails were delivered?
Our biggest area of concern is what techniques to use so that we know when a message is sent out that it either lands in an inbox or it failed and we need to do something else.
Additional requirements:
We're not at the stage of including an escalation response, but we'll want that in the
future or so we think.
Most notifications will be internal to our enterprise, but we will have some notifications being sent to external clients.
Some of our application is in a hosted environment. We haven't determined if those servers can access our corporate email servers for relaying or if they'll be acting as their own mail servers.
Base design / modules (at the moment):
A module to assign tracking identification
A module to send out emails
A module to receive delivery notification (perhaps this is the same as the email module)
A module that checks sent messages against delivery notification and alerts on undelivered email.
Some references:
Atwood: Send some email
Email Tracking
Some approaches:
Request a response (aka read-receipt or Message Disposition Notification).
Seems prone to failure since we have cross-compatibility issues due to differing mail servers and software.
Return receipt (aka Delivery Status Notification).
Not sure if all mail servers honor this request or not
Require an action and therefore prove reply.
Seems burdensome to force the recipients to perform an additional task not related to resolving the issue. And no, we haven't come up with a way of linking getting the issue fixed to whether or not the email was received.
Force a click-through / Other site sign-in.
Similar to requiring some sort of action, this seems like an additional burden and will annoy the users. On the other hand, it seems the most likely to guarantee someone received the notification.
Hidden image tracking.
Not all email providers automatically load the image, and how would we associate the image(s) with the email tracking ID?
Outsource delivery.
This gets us out of the email business, but goes back to how to guarantee the out-sourcer's receipt and subsequent delivery to the end recipient.
As a related concern, there will be an n:n relationship between issue notification and recipients.
The 1 issue : n recipients subset isn't as much of a concern although if we had a delivery failure we would want to investigate and fix the core issue.
Of bigger concern is n issues : 1 recipient, and we're specifically concerned in making sure that all n issues were received by the recipient. How does forum software or issue tracking software handle this requirement? If a tracking identifier is used, Where is it placed in the email? In the Subject, or the Body?
