Alıcı SMTP bir posta parçasını kabul etmekle (DATA komutuna yanıt olarak bir "250 OK" iletisi göndererek), iletinin teslimat veya röleleme sorumluluğunu kabul etmiş olur. Bu sorumluluğu ciddiyetle ele alması gerekir. İletiyi konağın sonradan bozulması veya önceden kestirilebilir kaynak kıtlığı gibi sudan sebeplerle kaybetmemelidir *ZORUNLU*.

Bir iletinin kabulü sonrası bir teslimat başarısızlığı olursa, alıcı SMTP'nin bir bildirim iletisi oluşturup postalaması gerekir *ZORUNLU*. Bu bildirim zarfta boş ("<>") dönüş yolu kullanılarak gönderilmelidir *ZORUNLU*. Bu bildirimin alıcısının adresi zarf dönüş yolundan (veya Return-Path: satırından) elde edilmelidir *ZORUNLU*. Ancak, bu adres boşsa ("<>"), alıcı SMTP bir bildirim göndermemelidir *ZORUNLU*. Açıkça, bu bölümdeki hiçbir şey günlük tutma ile ilgili yerel kararları (alıcı SMTP ile aynı sistem ortamının parçası olarak) yasaklayamaz, yasaklamamalıdır da, aksi takdirde boş adres olayları hakkında bilgi yerel olarak aktarılır, eğer istenen buysa. Eğer adres açık bir kaynak rotası ise, son sekmesine indirgenmelidir *ZORUNLU*.

Örneğin,

MAIL FROM:<@a,@b:kullanıcı@d>

ile gelen bir ileti için bir hata bildirimi gönderilmesi gerektiğini varsayalım. Bildirim iletisinin

RCPT TO:<kullanıcı@d>

kullanılarak gönderilmesi gerekir *ZORUNLU*. İleti SMTP tarafından kabul edildikten sonraki bazı teslimat başarısızlıkları kaçınılmaz olacaktır. Örneğin, RCPT komutlarındaki tüm teslimat adreslerinin doğrulanması alan SMTP sunucusu için imkansız olabilir; bunun sebebi, bir "yazılımsal" alan adı sistemi hatası olabileceği gibi hedefin bir posta listesi olması (RCPT ilk açıklamalarına bakınız) veya sunucunun bir röle olarak davranmasından dolayı teslimat sistemine doğrudan erişilememesi olabilir.

Zamanaşımlarının bir sonucu olarak yinelenmiş iletilerin alınmasından kaçınmak için alıcı SMTP, son <CRLF>.<CRLF> veri sonu belirtecine yanıt için gereken süreyi en aza indirecek çalışmayı yapmalıdır *ZORUNLU*. Bu sorunun daha ayrıntılı bir açıklaması için RFC 1047'ye [28] bakınız.