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.

Bir iletideki "Received:" başlıklarının basitçe sayılması her zaman en iyisi olmasa da posta sistemlerinde döngülerin saptanması için etkin bir yoldur. Bu tekniği kullanan SMTP sunucuları en azından 100 "Received:" girdilik büyükçe bir red eşiği kullanmalıdır *ÖNERİ*. Hangi mekanizma kullanılırsa kullanılsın, sunucular gereksiz döngüleri algılamak ve durdurmak için hazırlıklı olmalıdır *ZORUNLU*.

Şanssızlık eseri, Genel Ağ posta protokolleri ile ilgili çeşitlemeler, yaratıcı yorumlar ve açıkça ihlaller ortaya çıkar; bazıları bunların o kadar sık görülmediğini söyler. İyi bir SMTP alıcısı veya rölesi, bozuk bir iletiyi red mi etmeli, hiçbir değişiklik yapmadan geçirmeye mi çalışmalı yoksa başarılı bir teslimat veya yanıt şansını arttırmak için onarmaya mı çalışmalı tartışmaları yapısal ağ postasının ortaya çıkışı ile başladı ve bitecek gibi de görünmemektedir. Red yanlıları onarmaya çalışmanın herzaman yeterli olmadığını ve hatalı iletilerin reddedilmesinin yazılımın tamirinde tek çözüm olduğunu iddia ederler. "Tamir et" veya "ne olursa olsun teslim et" yanlıları ise kullanıcıların postanın eğer olabilirse iletilmesi gerektiğini düşündüklerini ve bu yönde önemli piyasa baskısı olduğunu söyleyip karşı çıkarlar. Uygulamada, bu piyasa baskıları belirli satıcılar için asıl geliştiricilerin tercihlerine bakmaksızın, standartlara kesinlikle uymaya çalışmaktan daha önemli olabilir.

Hatalı biçimlenmiş iletilerle ilgili sorunlar ayrık posta okuma protokollerinin [3, 26, 5, 21] ortaya çıkışı ile iyice arttı. Bu protokoller SMTP'yi postalama protokolü olarak ve SMTP sunucularını da bu istemci konaklar (sıkça ama aralıklarla Genel Ağ'a bağlanan konaklar) için röleleme sistemleri olarak kullanmayı teşvik etti. Geçmişe baktığımızda, bu istemci makinelerin çoğunun SMTP tarafından varsayılan bazı bilgilere ve mekanizmalara (ve tabii, posta biçimleme protokolüne [7]) ihtiyaç duyduklarını görürüz. Bazıları zamanı yeterince takip edemedi; bazıları zaman dilimleri kavramından habersizdi; bazıları hala isim ve adreslerini tanımlayamıyor; ve, tabii ki hiçbiri RFC 822'nin kimlik kanıtlamalı adresler kavramının dayandığı öngereklilikleri sağlayamadı.

Bu zayıf SMTP istemcilerine yanıt olarak, artık bir çok SMTP sistemi kendilerine eksik veya yanlış biçimlenmiş olarak teslim edilen iletileri tamamlamaktalar. Bu strateji, sunucu istemciyi tanıdığında veya kimliğini kanıtlamasını istediğinde ve aralarında ön anlaşmalar olduğunda genellikle doğru sayılır. Karşıt olarak, en büyük endişe, kullanıcı veya istemci makinesi hakkında çok az bilgisi olan veya hiç bilgisi olmayan bir röle veya teslimat SMTP sunucusu tarafından uygulanan düzeltmelerle ilgilidir.

Aşağıdaki değişiklikler işlenmekte olan bir iletiye, gerek oluşturucu gerekse SMTP'nin ilk postalama protokolü hedefi olarak kullanıldığı SMTP sunucusu tarafından uygulanabilir *SEÇİMLİK*.

Sunucunun istemci hakkında ne kadar az bilgisi olursa, bu değişiklikler o kadar az doğru olur ve düzeltmelerin yapılıp yapılmaması veya nasıl yapılması gerektiği ele alınırken daha fazla dikkat ve tutarlılık gösterilmesi gerekir. Bu değişiklikler ara röleleme işlemi yapan SMTP sunucuları tarafından uygulanmamalıdır *ZORUNLU*.

Her durumda, doğru bilgi sağlayarak düzgün işleyen istemciler, SMTP sunucuları tarafından düzeltmeler bakımından tercih edilir. Tüm durumlarda, sunucular tarafından yapılan hareketlerin mutlaka belgelenmesi (izleme alanları ve/veya başlık yorumlarında) önerilir.