SMTP postası doğal olarak güvensizdir, öyle ki ilgisiz kullanıcılar bile alıcı ve röle SMTP sunucuları ile doğrudan haşır neşir olabilir ve saf/toy/taze bir alıcıyı başka bir yerden gelmiş gibi görünen iletiler gönderip kandırabilir. Böyle bir iletinin "yanıltıcı" davranışının bir uzman tarafından tespit edilemeyecek şekilde oluşturulması biraz zordur, ama bilgili ve kararlı birini caydıracak kadar değil. Sonuçta, Genel Ağ posta bilgisinin artışına bağlı olarak, SMTP postasının aktarım seviyesinde doğal olarak kimlik kanıtlamalı olamayacağı veya bütünlük sınamalarının yapılamayacağı ortaya çıktı. Gerçek posta güvenliği sadece uç noktalarda ileti gövdesinin incelenmesiyle (örn, sayısal imzalar) sağlanabilir (bkz, PGP [4], S/MIME [31]).

Aktarım seviyesinde (yani, SMTP istemcisinden SMTP sunucusuna aktarımda) kimlik kanıtlaması sağlayan çeşitli protokol eklentileri ve yapılandırma seçenekleri yukarıda açıklanan geleneksel durumu biraz düzeltebilir. Yine de, dikkatle tasarlanmış bir güvenlik ortamının sorumluluğu bunlara aynı dikkatle eşlik etmedikçe, aktarım sisteminin bütünlüğüne bağlı kalmaktansa sayısal imzalı iletileri kullanan uçtan uca mekanizmalardan doğal olarak daha zayıf kalacaklardır.

Zarf dönüş yolunu ve başlık "From" alanlarını kendilerininkinden farklı olarak doğru bir adresi gösterecek şekilde ayarlamayı kullanıcılar için daha zor hale getirme çabaları amacından epeyce saptırılmıştır: bir kullanıcı tarafından bir başkası yararına posta gönderimi veya özel bir adrese yönlendirilmesi gereken hata (veya normal) yanıtların gönderimi şeklindeki meşru uygulamaları boşa çıkarmışlardır. (Her iletiye özel olmak üzere kullanıcılarına bu alanları değiştirebilme imkanı sunan sistemler, ileti verisi içindeki gönderici alanlarının hassas bir şekilde üretilebilmesi için kullanıcıya bir birincil ve kalıcı posta kutusu adresi sağlamaya çalışmalıdır.)

Bu belirtim, sahte posta göndermeye çalışan görgüsüz bir kullanıcıya karşı küçük bir koruma sağlayacağını umarak bu faydalı işlevselliğin iptal edilmemesini savunmak dışında, SMTP ile ilgili kimlik kanıtlama konularının adresi değildir.

İleti başlıklarında görünmeyen adresler bir SMTP sunucusunda RCPT komutlarında şu veya bu sebeple görünebilir. En çok karşılaşılan ikisi bir posta adresinin bir "liste patlatıcısı" olarak kullanımı (tek bir adres çok sayıda adres olarak çözümlenir) ile "gizli kopya" varlığıdır. Özellikle birden fazla RCPT komutunun varlığında ve bu mekanizmaların bazı amaçlarını da yok etmemek için, ister izleme başlıklarının parçası olarak ister bilgilendirici ya da özel eklenti başlıkları olarak, SMTP istemcileri ve sunucuları RCPT komutlarının bağımsız değişkenlerinin tamamını başlıklara kopyalamamalıdır *ÖNERİ*. Bu kural uygulamada sıkça ihlal edildiğinden, "bcc" kullanmayı bilen gönderici SMTP sistemleri her gizli kopyayı tek bir RCPT komutu içeren ayrı bir ileti aktarımında göndermeleri daha yararlıdır *SEÇİMLİK*.

SMTP aktarımındaki ("zarf") ve başlıklardaki ne "dönüş" adresleri (MAIL, SAML, vs. komutlarındaki) ne de "sevk" adresleri (RCPT komutlarındaki) arasında doğal bir ilişki vardır. Alıcı sistemler böyle ilişkileri ortaya çıkarmaya ve teslimat için onları ileti başlıklarını değiştirmekte kullanmaya çalışmamalıdır *ÖNERİ*. Güncel olan "Apparently-to" başlığı bir kasıtsız bilgi ifşasının genel kaynağı olarak bu prensibin ihlalidir ve kullanılmamalıdır *ÖNERİ*.

Adres Hatalarını Ayıklama Komutları bölümünde bahsedildiği gibi bağımsız bazı siteler güvenlik kaygılarıyla VRFY veya EXPN komutunu veya her ikisinide iptal etmek isteyebilir. Yukarıda bahsedilenin doğal sonucu olarak, buna izin veren gerçeklenimler aslında doğrulamadıkları halde adresleri doğrulamış gibi görünmemelidir *ZORUNLU*. Eğer bir site bu komutları güvenlik nedenleriyle iptal ederse, SMTP sunucu başarılı veya başarısız doğrulama ile karıştırılabilecek bir yanıt kodu kullanmak yerine bir 252 yanıtı döndürmelidir *ZORUNLU*.

Sadece sözdizimsel olarak kontrol ettikten sonra VRFY komutundaki adresi içeren bir 250 yanıtı döndürmek bu kuralı ihlal eder. Şüphesiz, VRFY komutunu, adres geçerli olsun olmasın daima 550 yanıtı döndürerek destekleyen bir gerçeklenim de aynı uyumlulukta değildir.

Son bir kaç yıldır, posta listelerinin içeriği "spamcılar" denen kitle için bir adres bilgi kaynağı haline geldi. Liste yöneticileri listelerin kendilerini uygunsuz kullanımına karşı korumak üzere önlemler aldıkça "adres hasadı"nda EXPN kullanımı arttı. Gerçeklenimler EXPN desteğini yine de sağlamalı *ÖNERİ*, fakat siteler karşılıklı tavizleri dikkatle değerlendirmelidir *ÖNERİ*. Kimlik kanıtlama mekanizmaları SMTP'ye tanıtıldıkça, bazı siteler EXPN'yi sadece kimliğini kanıtlayan istekçilere kullanılabilir kılmayı seçebilir.

Karşılama yanıtlarında ya da HELP komutunun yanıtında sunucu türünü ve sürümünü (hatta bazan alan adını) duyurmanın hata ayıklamaya getirileri ile olası bir düşmanca saldırı için kullanışlı olabilecek bilgiyi açığa çıkarmasının götürüleri arasındaki ödünleşimler hakkında süregiden bir tartışma yaşanmıştı. Hata ayıklama bilgisinin faydası şüphe götürmez. Bu bilginin duyurulmasını isteyen kişiler bir SMTP sunucusunu gerçekten güvenli kılmanın, sunucunun kimliğini saklayarak bilinen savunmasızlıkların gizleneceğini ummaktan daha iyi olduğu noktasına dikkat çekerler. Sitelerin bu durumu akılda bulundurarak ödünleşime değer biçmeleri (neye taviz vereceklerine karar vermeleri) tavsiye edilir; gerçeklenimlerin diğer ağ konaklarına tür ve sürüm bilgilerini asgari düzeyde bile olsa bir şekilde erişilebilir kılmaya çalışmaları kesinlikle tavsiye edilmektedir.

Postanın konakları doğrudan Genel Ağ'a bağlı olmayan bir yerel ağdan kaynaklanması gibi durumlarda, bu belirtimle uyumlu olarak üretilmiş izleme ("Received") alanları, konak isimlerinin ve normalde erişilir olmayan benzeri bilgilerin ifşasına sebep olabilir. Bu sıradan bir durum olarak bir sorun teşkil etmese de isim ifşası ile özel ilgisi olan sitelerin bundan haberleri olması gerekir. Ayrıca, birden fazla alıcı olduğu durumda FOR cümleciği dikkatli kullanılmalıdır, aksi taktirde "gizli kopya" alıcılarının diğerlerine görünür hale gelmesine yol açılabilir.

Adres Düzeltmek veya Güncellemek için Yönlendirme bölümünde açıklandığı gibi, bir posta kutusuyla ilişkilendirilmiş sevk yolu adresini tanımlamak için 251 veya 551 yanıt kodlarının kullanımı hassas bilgilerin açığa çıkmasına yol açabilir. Bu gibi durumlardan endişe duyan siteler, sunucuları buna uygun seçip yapılandırdıklarından emin olmalıdır.

Sunucuyu sağlayan siteye mantıklı gelen herhangi bir işlemsel veya teknik sebep yüzünden bir SMTP sunucunun posta alımını reddetmesi iyice oturmuş bir prensiptir. Bununla birlikte, Genel Ağ, siteler ve tesisler arasındaki işbirliği ile mümkün olur. Siteler trafiği reddetmenin yararlarından aşırı yararlanmaya kalkarlarsa, epostanın yaygın olarak kullanılabilirliği (Genel Ağ'ın güçlü yanlarından biri) giderek azalmaya başlayacaktır; eğer bir site kabul edip işleyeceği trafikte seçici olmaya karar verirse çok dikkatli olunmalı ve denge sağlanmalıdır.

Son yıllarda, postanın kaynaklandığı yeri gizlemek için röleleme işlevi düşmanca bir çababanın bir parçası olarak rasgele sitelerde kullanıldı. Bazı siteler kaynakları tanımlayabilmek ve bilmek için röleleme işlevinin kısıtlanmasına ve gerçeklenimlerin bu tür filtreleme yapabilme kabiliyetinde olması gerektiğine *ÖNERİ* karar verdiler. Posta bu veya başka bir kural sebebiyle reddedildiğinde, EHLO, MAIL veya uygunsa RCPT'e yanıt olarak bir 550 kodu kullanılmalıdır *ÖNERİ*.