Email Tracking

In both my personal and professional life I’ve had people ask me how to be able to determine the status of an email, or to use a service that can determine the status of an email. While being able to check what the status of an email is, such as if the email was delivered to the user’s inbox, if the user has read the email, or if a user has clicked a link within the email, all of the methods of doing so produce so many false positives and negatives that it’s really not worth going through the effort to implement such a system. The following are the general methods for checking the status of message as well as their downfalls.

Delivery

Checking to see if an email was delivered to the mail server is easy, it’s a simple as checking your SMTP logs to see if the mail was delivered to the receiving mail server. It’s not really much harder than that.

The problem with this, however, is that servers may “accept” the mail only to put it in a user’s spam folder, or worse yet drop the email without notification. Dropping email after can happen without notification if the mail server doesn’t check it for spam, etc., until after closing the connection with the sending mail server, and the reason why you won’t get a notification back is to reduce backscatter. As for the spam folder, you can’t really do anything about that other than ensuring your SPF and DKIM records are set appropriately, signing your emails with said DKIM keys, and ensuring that the content of your emails don’t look “spammy”.

The only good notification you may get is a bounce message if the user’s mailbox doesn’t exist, if it’s full, etc., however you’ll normally only get those within the same connection the email is being sent with. If you do happen to get them after closing the connection you should probably contact their administrator as they’re contributing to the backscatter problem.

Read, Click, etc.

You may also want to check if a user has read your email or not, which could be useful in some circumstances. The following are the methods to do so and their downfalls.

Read Receipts

One way to accomplish this is via read receipts. Basically, a read receipt is an email sent via the users mail application when they open an email which is sent back to the sender. The senders email application then links this back to the original email to display a notification to the user indicating that the mail has been read.

While this sounds great, the problem is that this method does not always work. Read receipts can be turned off in the majority of circumstances, and additionally most systems default this setting to off (i.e., it had to be explicitly enabled), or do not even have the capability to do this at all. For instance, Google’s FAQ about read receipts indicates that read receipts are only available on Google Apps accounts if an administrator enables it, and is not available on personal accounts. Additionally, Google’s FAQ states the following:

Do not rely on read receipts for certifying mail delivery. Although read receipts generally work across email systems, you may sometimes get a receipt for an unread message or not get a receipt even though the recipient has read the message.

Remote Images

The next trick is to use a remote image within the email to signal to a server that the email has been read. When the email is opened, the users browser or mail application will load the remote image allowing a server to tell if the email has been read.

The flaw with this method is that most mail applications will not display remote images, and most webmail systems will not display remote images either. Google’s FAQ for Gmail indicates that images may be shown, however that’s only after Google determines them to not be malicious. What this implies is that, while images may be displayed, Google checks the images before ever showing it to the user, and therefore it’s possible the server gets a notification that the user has opened the email when in reality the user never actually opened it.

JavaScript

I’m not even going to go here as including JavaScript within emails is a good way to get yourself blacklisted, and it’s not going to work anyway because most providers will strip any scripts out of the email before displaying it to the user. See the Super User question about this.

Links

You could use links that contain a unique identifier in them, and then when he user clicks on the link, the server would be able to see that unique id and mark the email as read. This is about the only method that may actually work and make sense, however it has some of the same problems as remote images. The mail server could check the links to see if it’s linking to malware or something malicious, and your mail server may treat that as the user clicking on the link if that’s not accounted for.

The problem with this, however, is that if the user got this far, they’re probably on your site doing whatever it is you emailed them about, which you should be able to track already, so it’s kind of pointless short of email marketing campaigns that link to somewhere you do not control.

Conclusion

Email “status” tracking is inaccurate with false positives and negatives all throughout the process. If you understand these limitations and still want to track your users, then by all means go right ahead, just don’t get mad when your numbers are a little off from what you thought they would be. Lastly, if you’re running a third-party mailing service please make sure your users understand this as well.

Leave a Reply