DSN: Delivery Status Notification for SMTP Email

What is DSN in email?

Person reading email on laptop

Rawpixel / PXhere 

Delivery Status Notification has been around since RFC 821 (from 1982). As soon as the DATA part of the SMTP protocol is finished and the server has accepted the email for delivery it is responsible for it. If for any reason it cannot get it through to the recipient it must send it back with notification of the error to the original sender. This resulted in some obscure email.

Apart from that, this old convention either meant that you received an error message or you received nothing, in which case you knew nothing. The email may have arrived or it may not have arrived. The error messages in many cases were just as helpful as no error messages. With email becoming more and more important this is no longer satisfactory (as if it was before).

DSN Extensions to SMTP

RFC 1891 proposes some extensions to the SMTP protocol that should result in a more reliable and more usable DSN system. It is a set of extensions to the MAIL and RCPT commands.

No EHLO, No Fun

First, we have to make sure that the server supports DSN. Thus, we have to say EHLO to him and listen carefully. If it responds with DSN somewhere in the feature list we can assume that it will be able to serve our requests. If not, then not: we can try another server or simply fall back to email without DSN. For example:

220 larose.magnet.at ESMTP Sendmail 8.8.6/8.8.6; Sun, 24 Aug 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at Hello localhost [], pleased to meet you
250 HELP

Luckily, among other things we find DSN.

DSN Sender Extensions

The next command typically is MAIL FROM. With DSN, this is no different. But there are two additional options you may issue: RET and ENVID.

The RET option was rather arbitrarily placed in the MAIL command, but it fits here as well as it would anywhere else. The purpose is to specify how much of your original message should be returned in case of a delivery failure. Valid arguments are FULL and HDRS. The former means that the complete message should be included in the error message, HDRS instructs the server to only return the headers of the failed mail. If RET is not specified, it is up to the server what to do. In most cases, HDRS will be the default value.

ENVID really belongs to the sender as she or (rather) her email client will be the only one that makes use of this envelope identifier. Its purpose is to tell the sender which email a possibly issued error message corresponds to. The format of this ID is basically left to the imagination of the sender. We will not use ENVID in our example:

MAIL FROM: sender@example.com RET=HDRS
250 sender@example.com... Sender ok

Apparently, we only want to get the headers back in our DSN.

DSN Recipient Extensions

The RCPT TO: gets its fair share of extensions as well: NOTIFY and ORCPT.

NOTIFY is the real heart of DSN. It tells the server when to send a delivery status notification. The first possible value is NEVER which means that under no circumstances a DSN must be returned to the sender. This was not possible without DSN. Then there is SUCCESS, which will notify you when your mail has arrived at its destination. FAILURE is SUCCESS's counterpart: a DSN will arrive if an error occurred during delivery. The last option is DELAY: you will be notified if there is an unusual delay in delivery, but the actual delivery's outcome (success or failure) is not yet decided. NEVER must be the only argument if it specified, the other three may appear in a list, delimited by a comma. SUCCESS and FAILURE make up for a pretty strong team together, telling you in (almost) any case what happened to your mail.

The purpose of ORCPT is to preserve the original recipient of an email message, for example, if it is forwarded to another address. The argument to this option is the email address of the original recipient together with the address type. The address type comes first, followed by a semicolon and finally the address. For example:

RCPT TO: support@example.com NOTIFY=FAILURE,DELAY ORCPT=rfc822;support@example.com
250 support@example.com... Recipient ok (will queue)

This is followed by the DATA as we know it and eventually, hopefully, a delivery status notification notifying you of success.

Does DSN Work?

Of course, all this beauty and it will only work if the mail transport agents from sender to recipient support DSN.