SMTP komutlarının ve yanıtlarının sözdizimleri katı kurallara sahiptir. Tüm komutlar bir komut fiiliyle başlar. Tüm yanıtlar ise üç hanelik bir sayısal kod ile başlar. Bazı komutlarda ve yanıtlarda argümanlar varsa bunların fiil veya yanıt kodunundan hemen sonra olmaları gerekir *ZORUNLU*. Bazı komutlar (fiilden sonra) argüman kabul etmezler ve bazı yanıt kodlarından sonra, bazan isteğe bağlı olarak, serbest biçimli metin olabilir. Her iki durumda da, bir metin olduğunda, metin fiil veya yanıt kodundan bir boşluk karakteri ile ayrılır. Komutların ve yanıtların tanımlarının tamamını SMTP Belirtimi bölümünde bulabilirsiniz.

Fiiller ve argüman değerleri (RCPT komutundaki "TO:" veya "to:" ve eklenti ismi anahtar sözcükleri gibi), bu belirtimdeki bir posta kutusunun yerel-kısım belirtimi ile ilgili biricik istisna dışında, harf büyüklüğüne duyarsızdır (SMTP Eklentileri açıkça harf büyüklüğüne duyarlı bileşenler belirtebilirler). Yani, bir komut fiili, posta kutusu yerel-kısım'ı hariç bir argüman değeri ve serbest biçimli metin, tamamen büyük harflerden, tamamen küçük harflerden veya her ikisinin karışımından oluşabilir *SEÇİMLİK* ve bu bir anlam değişikliğine yolaçmaz. Bu, bir posta kutusunun yerel-kısım'ını belirtirken geçerli değildir. Bir posta kutusunun yerel-kısım'ı harf büyüklüğüne duyarlı olmalıdır *ZORUNLU*. Bundan dolayı, SMTP gerçeklenimleri posta kutularının yerel-kısım'larını bu bakımdan korumaya dikkat etmelidir *ZORUNLU*. Posta kutusu alan'ları harf büyüklüğüne duyarlı değildir. Bazı konaklarda, bazan "smith" kullanıcısı ile "Smith" kullanıcısı farklı olabilmektedir. Bununla birlikte, posta kutusu yerel-kısım'larının harf duyarlılığının istismar edilmesi birlikte çalışabilirliğe sekte vurmaktadır ve cesaret kırıcıdır.

Birkaç SMTP sunucusu, bu belirtime (ve RFC 821'e) aykırı olarak, komut fiillerinin istemciler tarafından büyük harflerle kodlanmasını gerektirmektedir. Gerçeklenimler isterlerse bu sunucuları da kapsamak için bu kodlamaya da destek verebilirler *SEÇİMLİK*.

Argüman alanları uzunluğu ile ilgili bir sınırlama olmayan ve satır sonlandırıcı ile yani, <CRLF> ile biten bir karakter dizisinden oluşur. Alıcının bu dizilim alınana kadar hiçbir şey yapmaması gerekir.

Her komutun sözdizimi o komutun açıklaması ile birlikte gösterilmiştir. Ortak bileşenler ve parametreler ise Komut Argümanlarının Sözdizimi bölümünde gösterilmiştir.

Komutlar ve yanıtlar, ASCII karakter kümesinin [1] karakterlerinden oluşur. 8 bitlik baytlar (sekizli) kullanan bir aktarım kanalı sağlayan bir aktarım hizmetinin varlığı halinde, her 7 bitlik karakter, sekizli içinde sağa yanaştırılıp, sekizlinin yüksek biti sıfır yapılarak aktarılır. Hatta özellikle, eksiz (yalın) SMTP hizmeti sadece 7 bitlik aktarım sağlar. Belli bir sunucuyla ilgili eklentiyi başarıyla müzakere edemeyen (böyle bir yeteneği olmadığı için) bir oluşturucu SMTP istemcisi, iletileri sekizlinin yüksek bitindeki bilgiyle (yüksek biti sıfırlamadan) aktarmamalıdır *ZORUNLU*. Böyle iletiler bu kurala aykırı olarak aktarılıyorsa, alıcı SMTP sunucuları yüksek biti temizleyebilir veya iletiyi geçersiz olduğu gerekçesiyle reddedebilir *SEÇİMLİK*.

Genelde, bir röle SMTP aldığı iletinin içeriğinin geçerli olduğunu varsaymalı ve zarfın bunu yapmasına izin verdiği varsayımıyla içeriğini incelemeksizin rölelemelidir *ZORUNLU*. Şüphesiz, eğer içerik yanlış etiketlenmişse ve veri yolu asıl içeriği kabul edemiyorsa, bu, eninde sonunda alıcıya birkaç bozuk ileti teslimatıyla sonuçlanabilir. Hiçbir SMTP sistemi zarf komutlarını US-ASCII'den farklı bir karakter kümesinde göndermeye izin vermemelidir; alıcı sistemler böyle komutları, normalde, "500 syntax error - invalid character" (sözdizimi hatası - geçersiz karakter) yanıtlarıyla reddetmelidir *ZORUNLU*.

Bir istemci bir sunucudan, sekiz bitlik ileti içeriğinin ek SMTP oluşumları, özellikle de "8BITMIME" eklentisi [20] kullanılarak aktarılmasını isteyebilir *SEÇİMLİK*. 8BITMIME, SMTP sunucuları tarafından desteklenmelidir *ZORUNLU*. Bununla birlikte, bu kural, sekiz bitlik malzemenin koşulsuz aktarılmasına izin varmış gibi yorumlanamaz *ZORUNLU*. Göndericilerin, MIME biçiminde olmayan ama uygun bir içerik aktarım kodlaması kullanarak hazırladıkları yüksek bitli malzeme için 8BITMIME isteği yapmamaları gerekir *ZORUNLU*; sunucular böyle iletileri reddedebilirler *SEÇİMLİK*.

Bu belgede kullanılan dilötesi gösterim Genel Ağ posta sistemi belgelerinde kullanılan "Arttırımlı BNF"ye karşılıktır. Bu sözdizimine aşina olmayan okuyucuların ABNF belirtimini [8] incelemeleri iyi olur. Metin üzerinde kullanılan dilötesi terimler arılık amacıyla açılı ayraçlarla sarmalanmıştır (<CRLF> gibi).