SMTP Nedir? Mail Nasıl Gönderilir ve Neden Gitmez?

SMTP (Simple Mail Transfer Protocol), e-postayı gönderen protokoldür ve tek yönlü çalışır: yalnızca gönderir, hiçbir zaman posta kutunuzu okumaz. Bir mail programı kurarken neden iki ayrı sunucu adresi girdiğinizin sebebi budur; giden trafiği SMTP taşır, gelen trafiği IMAP ya da POP3 taşır. Protokolün bugün geçerli tanımı Ekim 2008 tarihli RFC 5321 belgesidir.

Bu ayrım arıza anında ilk sorulacak sorudur, çünkü “mail gitmiyor” ile “mail gelmiyor” birbirine hiç benzemeyen iki problemdir. Bu yazı gönderme tarafını anlatıyor: SMTP’nin bir sunucuyla nasıl konuştuğunu, mailin neden tek adımda teslim edilmediğini ve gitmeyen bir maili hangi sırayla daraltacağınızı. Gerçek bir sağlayıcının posta sunucusuna bağlanıp konuşmayı da kaydettim, yani anlatılan şeyin ölçülmüş hali aşağıda duruyor.

Acele ediyorsanız iki yere doğrudan gidebilirsiniz: 25, 587 ve 465 portlarının neden aynı işi yapmadığı ve gitmeyen bir maili hangi sırayla daraltacağınız.

Bu makale kurumsal ağ protokolleri rehberimizin e-posta koluna odaklanır.

Konuyu tek bir yerden anlatacağım: bir otogar. Yolcu çoğu zaman gideceği şehre doğrudan gitmez; peronda bir görevliye emanet edilir, bir aktarma merkezine iner, orada başka bir otobüse biner. Bagajının etiketi ile elindeki biletin üstündeki isim ayrı ayrı yazılır. SMTP’nin bugün anlaşılmayan yanlarının neredeyse tamamı, bu iki ayrıntının protokole birebir kazınmış olmasından doğuyor.

Eşleme şöyle kuruluyor:

Analojinin koptuğu yer şurası: otogarda yolcu tektir ve bir anda tek bir yerde bulunur. E-postada ise mail her aşamada kopyalanır. Gönderdiğiniz bir mailin bir kopyası sizin Gönderilenler klasörünüzde, bir kopyası çıkış sunucusunun kuyruğunda, bir kopyası varış sunucusunun posta kutusunda durur. Bu yüzden “mail şu anda nerede” sorusunun tek bir cevabı yoktur, ve teşhis yaparken de “hangi kopyaya bakıyorum?” sorusu ilk sorulacak sorudur.

SMTP Neden Yalnızca Gönderir?

SMTP tek yönlü çalışır çünkü taşımak ile eriştirmek ayrı işlerdir. Postayı yola çıkarmak bir yetki ister, posta kutusunu açmak bambaşka bir yetki; ikisini tek protokole vermek, dünyaya açtığınız kapıyı posta kutularınızın da kapısı yapardı.

Adı bunu zaten söylüyor. SMTP’nin ortasındaki kelime Transfer, yani taşıma. IMAP’ın ortasındaki kelime ise Access, yani erişim. Bu iki kelime, iki protokolün işini tam olarak ayırıyor: biri taşır, diğeri eriştirir. Karışıklık yaşandığında bu ayrıma dönmek çoğu zaman yeter.

SMTP metin tabanlı bir komut protokolüdür. İstemci düz yazıyla bir komut yollar, sunucu üç haneli bir sayı ve kısa bir açıklamayla cevap verir. Bu sayılar rastgele değil, ilk hanesi cevabın türünü söyler:

• 2xx : işlem başarılı, devam edebilirsiniz
• 3xx : ara bir aşama, sunucu sizden devamını bekliyor
• 4xx : geçici hata, şu an olmadı ama sonra olabilir
• 5xx : kalıcı hata, tekrar denemenin anlamı yok

4xx ile 5xx arasındaki fark bu makalenin en pratik bilgilerinden biri ve teşhis bölümünde tekrar karşımıza çıkacak. Şimdilik şu kadarı yeter: 4 ile başlayan bir cevap aldığınızda mail kaybolmamıştır, sunucu onu kuyruğa alıp tekrar deneyecektir. 5 ile başlayan bir cevap ise reddediliştir ve size bir hata bildirimi döner.

SMTP Kodları HTTP Durum Kodu Değildir

Bu üç haneli sayılar SMTP’nin kendi yanıt kodlarıdır, HTTP durum kodları değil. Karıştırmak kolay, çünkü ikisi de üç hanelidir ve ikisinde de ilk hane cevabın sınıfını söyler. Ama sınıflar aynı şeyi anlatmaz, ve buradaki en pahalı yanılgı sınıfların kendisinde değil neye göre bölündüklerinde.

HTTP’de ayrım suçu paylaştırır, SMTP’de eylemi belirler. HTTP’de 4xx “hata sende”, 5xx “hata bende” demektir; yani eksen istemci ile sunucu arasındadır. SMTP’de böyle bir eksen yoktur. Orada 4xx “şu an olmadı, sonra tekrar deneyeceğim”, 5xx “olmayacak, vazgeçtim” demektir; yani eksen kalıcılıktır.

Farkın pratik karşılığı şudur: HTTP alışkanlığıyla 450 gören bir yönetici hatayı kendi istemcisinde arar, oysa SMTP’de o kod çoğu zaman karşı tarafın geçici bir durumunu bildirir ve yapılacak tek şey beklemektir. Tersi de geçerli: HTTP’de 5xx görünce “sunucu çökmüş” denir, SMTP’de 550 gördüğünüzde sunucu gayet iyi çalışıyordur, sadece o mesajı almayı reddetmiştir.

3xx grubu ise iki protokolde birbiriyle hiç ilgisiz. HTTP’de 301 sizi başka bir adrese gönderir; SMTP’de 354 “mesajın gövdesini şimdi yaz, bitince tek başına bir nokta koy” demektir. Aynı sınıf, taban tabana zıt iş.

Sayıların birebir çakıştığı bir örnek de var ve teşhiste kafa karıştırır: 421 her iki protokolde de tanımlıdır. HTTP’de “istek yanlış sunucuya yönlendirildi” anlamına gelir, SMTP’de ise “servis şu an müsait değil, bağlantıyı kapatıyorum” demektir. Aynı sayı, ilgisiz iki cevap.

Sıra da sandığınızın tersidir: üç haneli yanıt kodu fikri HTTP’den önce vardır. SMTP bu şemayı, kendisinden de eski olan dosya aktarım protokolünün geleneğinden devraldı; aynı karışıklığın oradaki hâlini ve iki kanallı bir aktarımın neden iki kod aldığını FTP, FTPS ve SFTP farkı rehberimizde ele alıyoruz. HTTP tarafındaki sınıflandırmayı ve hangi kodun ne anlattığını ise HTTP yanıtı ve durum kodları bölümümüzde bulabilirsiniz.

SMTP Oturumu: EHLO, MAIL FROM, RCPT TO ve DATA

Bir SMTP oturumu her zaman aynı sırayla ilerler ve bu sıra ezberlenecek kadar kısadır. Sırayla:

1. EHLO : istemci kendini tanıtır. Sunucu buna, desteklediği yetenekleri satır satır listeleyerek cevap verir. Eski adı HELO idi, EHLO onun genişletilmiş hali.
2. MAIL FROM : zarfın üstündeki gönderen adresi. Teslim edilemezse bildirim buraya döner.
3. RCPT TO : zarfın üstündeki alıcı adresi. Birden fazla alıcı varsa bu komut her alıcı için tekrarlanır.
4. DATA : buradan sonrası mesajın kendisidir. Başlıklar, gövde, ekler. Tek başına bir nokta içeren satırla biter.

Bu ilk adımı gerçek bir sunucuda kaydettim. İş istasyonundan smtp.gmail.com sunucusunun 587 numaralı portuna ham bir TCP bağlantısı açtım ve yalnızca kendimi tanıttım. Dökümü okurken üç şeye bakın:

• 220 ile başlayan ilk satır sunucunun hazır olduğunu bildiren karşılama satırı
• 250- ile başlayan satırların tamamı sunucunun yetenek listesi
• Bu listede ne olduğu kadar ne olmadığı da önemli, birazdan ona döneceğiz

220 smtp.gmail.com ESMTP d75a77b69052e-4ff2d9c8be1sm1857711cf.12 - gsmtp
EHLO test.sistemkusu.com
250-smtp.gmail.com at your service, [31.223.xx.xx]
250-SIZE 36700160
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8

Satır satır ne oldu:

1. Sunucu 220 ile karşıladı ve kendi adını söyledi. Bu satır her SMTP oturumunun ilk satırıdır.
2. Ben EHLO ile kendimi tanıttım.
3. Sunucu bize hizmete hazır olduğunu söylerken bizim genel IP adresimizi de yazdı. Yukarıdaki dökümde son iki haneyi maskeledim, gerçek oturumda adres tam olarak görünüyordu.
4. Ardından yeteneklerini sıraladı: kabul ettiği en büyük mesaj boyutu, sekiz bitlik karakter desteği, şifrelemeye geçebileceği, genişletilmiş durum kodları ve daha fazlası.
5. Son satır 250 ile başlıyor ve arasında tire yok. SMTP’de bu, listenin bittiği anlamına gelir; ara satırlar 250- şeklinde tireli gelir.

Buradaki bütün trafik şifresizdi. Sunucu adı, bizim adımız, IP adresimiz ve yetenek listesinin tamamı ağdan geçen herkesin okuyabileceği haldeydi. Bu bir kusur değil, tasarımın bir aşaması; nedenini birazdan STARTTLS bölümünde açacağız.

SMTP Zarfı ile Mail Başlığı Aynı Şey Değil

SMTP’de mailin nereye gideceğini zarf belirler, sizin ekranda gördüğünüz gönderen ve alıcı ise başlıktır, ve bu ikisi birbirini tutmak zorunda değildir.

Otogar benzetmesi burada tam oturuyor. Bagajınızın üstündeki etiket, bagajın hangi otobüse yükleneceğini ve nerede indirileceğini belirler; görevli yalnızca ona bakar. Biletin üstündeki isim ise size gösterilen bilgidir ve yönlendirmeye hiç karışmaz. E-postada da sunucular yönlendirmeyi MAIL FROM ve RCPT TO alanlarına, yani zarfa bakarak yapar. Mail programınızın gösterdiği From: ve To: satırları ise DATA bölümünün içindedir, yani mesajın içeriğinin bir parçasıdır.

Bu ayrım soyut değil, üç somut sonucu var:

• Gizli alıcılar buradan çıkar. Bir maili gizli kopya olarak gönderdiğinizde, o adres RCPT TO ile zarfa yazılır ama To: başlığına yazılmaz. Diğer alıcılar başlığı gördüğü için onu göremez.
• Teslim edilemeyen mail zarftaki adrese döner, başlıktakine değil. Bir posta listesinde hata bildirimlerinin listeyi yöneten adrese gitmesi, gönderen kişiye gitmemesi bundandır.
• Sahte mail atmak teknik olarak zor değildir. SMTP’nin kendisinde “bu kişi gerçekten bu adresten mi yazıyor” diye bir doğrulama yoktur.

Son madde doğal bir soru doğuruyor: madem zarf ile başlık birbirini tutmak zorunda değil, gelen bir mailin gerçekten göründüğü kişiden geldiğini ne doğruluyor?

Cevap: SMTP’nin içinde hiçbir şey. Bu doğrulama protokolün kendisinde değil, alan adının DNS zone’unda yapılır. SPF, DKIM ve DMARC kayıtları tam olarak bu işi yapar ve üçü de bu makalenin değil, SPF, DKIM ve DMARC rehberimizin konusudur. Şimdilik akılda kalması gereken şu: kimlik doğrulaması taşıma katmanının değil, isim katmanının işidir. Giden mailleriniz karşı tarafta spam klasörüne düşüyorsa, aradığınız yer büyük ihtimalle bu makale değil o kayıtlardır.

Zarfın ve başlığın gerçek bir mailde nasıl göründüğünü, Return-Path ile From alanının nerede ayrıştığını mail başlığı nasıl okunur yazımızda satır satır okuduk.

SMTP Teslimi Neden Tek Adımda Olmuyor?

SMTP sakla ve ilet (store-and-forward) mantığıyla çalışır: yol üstündeki her sunucu maili tam olarak teslim alır, diskine yazar, sorumluluğu üstlenir ve ancak ondan sonra bir sonrakine iletir.

Aktarmalı yolculuk tam olarak budur. Yolcu ilk otobüse bindiğinde son şehre ulaşacağı garanti değildir, ama aktarma merkezine ulaşacağı garantidir; oraya vardığında sorumluluk o merkeze geçer. Bir sonraki otobüs geç kalırsa yolcu kaybolmaz, bekler.

Bu olmasaydı ne bozulurdu? Uçtan uca doğrudan bir bağlantı kursaydınız, mail ancak iki tarafın da aynı anda açık olduğu saniyede gönderilebilirdi. Alıcının sunucusu bakımdaysa, hattı kopmuşsa ya da yoğunsa mail hiç yola çıkamazdı ve tekrar denemek gönderenin işi olurdu. Sakla ve ilet, bu sorumluluğu kullanıcıdan alıp sunucuya verir. Bugün gönderdiğiniz bir mailin siz bilgisayarınızı kapattıktan sonra teslim edilebilmesinin sebebi budur.

Received Başlıkları Aşağıdan Yukarı Okunur

Maile dokunan her sunucu, mesajın başına bir Received: satırı ekler. Yeni satır her zaman en üste eklendiği için, mailin yolculuğunu okumak isterseniz başlıkları aşağıdan yukarı doğru okursunuz.

Tipik bir başlık yığını şuna benzer:

Received: from mx.alici.com by imap.alici.com; Wed, 20 Aug 2026 14:22:07 +0300
Received: from aktarma.saglayici.net by mx.alici.com; Wed, 20 Aug 2026 14:22:05 +0300
Received: from istemci.gonderen.com by aktarma.saglayici.net; Wed, 20 Aug 2026 14:09:41 +0300

En alttaki satır yolculuğun başlangıcı, en üstteki satır sonu. Bu yığın tek başına bir teşhis aracı:

• Satırlar arasındaki saat farkı gecikmenin nerede olduğunu söyler. Yukarıdaki örnekte ilk iki aşama arasında 13 dakika var, sonraki ikisi arasında 2 saniye. Yani mail sağlayıcının aktarma sunucusunda beklemiş, alıcı tarafında değil.
• Beklenmeyen bir sunucu adı görürseniz mail beklenmeyen bir yoldan gelmiştir. Bu, sahte mail incelemesinin ilk adımıdır.
• Hiç Received satırı yoksa mail o sunucuya SMTP ile hiç uğramamıştır; büyük ihtimalle aynı sistemin içinde üretilmiştir.

Türkçe kaynaklarda en az anlatılan yer burasıdır, oysa “mail neden geç geldi?” sorusunun cevabı neredeyse her zaman bu üç satırın arasındaki saatlerde durur. Gerçek bir zinciri, saat dilimleri ve hangi satıra güvenileceğiyle birlikte mail başlığı yazımızın Received bölümünde okuduk.

Kuyruk ve Yeniden Deneme: Geciken Mail Kaybolmuş Mail Değildir

Bir sunucu maili kabul edemediğinde iki farklı şey söyleyebilir, ve hangisini söylediği mailin kaderini belirler.

Geçici ret (4xx): gönderen sunucu maili kuyruğunda tutar ve artan aralıklarla tekrar dener. Deneme süresi tipik olarak birkaç güne kadar uzar. Kullanıcı bu sırada hiçbir şey görmez, ya da yalnızca “teslim gecikiyor” uyarısı alır.

Kalıcı ret (5xx): gönderen sunucu vazgeçer ve size bir teslim edilemedi bildirimi döner. Ölçülen arama terimleri arasında smtp 550 hatası da var ve 550 tam olarak bu ailenin en sık görülen üyesidir: alıcı adresi yok, kutu kapalı ya da sunucu sizi kabul etmiyor.

Bu ayrımın en öğretici uygulaması gri listeleme (greylisting). Bazı sunucular hiç tanımadıkları bir gönderene ilk denemesinde bilerek 4xx döner. Kurallara uyan bir mail sunucusu bunu geçici hata sayar ve birkaç dakika sonra tekrar dener; ikinci denemede mail kabul edilir. Kurallara uymayan basit bir spam aracı ise tekrar denemez, çünkü sıradaki milyonlarca adrese geçmek ona daha ucuza gelir. Yani gri listeleme bir filtre değil, bir sabır testidir.

Sahada bunun karşılığı şudur: yeni bir iş ortağına ilk mailiniz on dakika gecikiyorsa, ikincisi anında gidiyorsa, ortada arıza yoktur. Sistem tasarlandığı gibi çalışmaktadır.

SMTP Portları: 25, 587 ve 465 Neden Üç Tane?

SMTP’nin üç portu olmasının sebebi şifreleme değil, kimin kime yazdığıdır. Üçü de aynı protokolü konuşur, ama üçünün kabul ettiği taraf farklıdır.

Bir mail programı yapılandırırken giden sunucu için doğru cevap neredeyse her zaman 587 olur. Gelen sunucu tarafı ayrı bir protokolün işidir ve portları da ayrıdır; onları IMAP ile POP3 farkı rehberimizde ele alıyoruz.

Port kavramının kendisi ve bir portun açık olup olmadığını nasıl ölçeceğiniz ayrı bir konu; port numaraları ve TCP ile UDP farkı makalesinde ele alınıyor.

25 numaralı port sunucudan sunucuya teslim içindir. Bir mail sunucusu, başka bir kurumun mail sunucusuna teslim yaparken bu portu kullanır. Bu portun karakteristik özelliği şu: kimlik doğrulama istemez, isteyemez. Size dünyanın herhangi bir yerinden mail gelebilmesi için, sunucunuzun tanımadığı sunucuları da dinlemesi gerekir.

587 numaralı port ise istemciden sunucuya gönderim içindir ve tam tersi kuralla çalışır: kimlik doğrulama zorunludur. Kendi kullanıcınız, kendi sunucunuza, kendi parolasıyla bağlanır. Bu ayrım bir isimlendirme tercihi değil, standardın kendisinde tanımlı.

465 numaralı port da gönderim içindir ve tek farkı şifrelemenin ne zaman başladığıdır; bir sonraki bölümün konusu bu.

Bu ayrım pratikte neyi belirler? Açık aktarıcı (open relay) dediğimiz hatayı. Bir sunucu, kendi kullanıcısı olmayan birinden mail alıp üçüncü bir tarafa taşırsa açık aktarıcı olur ve kısa sürede spam gönderiminde kullanılıp kara listelere düşer. Yapılandırmayı denetlerken sorulacak soru şudur: bu sunucu 25 üzerinden yalnızca kendi alan adına gelen mailleri mi kabul ediyor, yoksa herhangi bir hedefe taşıyor mu?

SMTP TLS ile Nasıl Şifreleniyor? STARTTLS’in Sırası

SMTP şifrelemeyi iki farklı sırayla yapabilir ve ikisi de bugün kullanımda. 465 numaralı portta bağlantı ilk saniyeden itibaren şifrelidir. 587 numaralı portta bağlantı düz metin başlar, istemci STARTTLS komutunu verir ve aynı bağlantı şifreliye çevrilir.

Bu kalıbı sitede daha önce görmüştük: LDAP’ta da aynı ikilik var ve çerçevesi LDAPS ile StartTLS ayrımında kurulu. Kısaca: aynı işi iki farklı sırayla yaparlar. Şifrelemenin kendisi, sürüm pazarlığı ve sertifika doğrulaması ise TLS’in nasıl çalıştığı makalesinin konusu.

Buradaki asıl mesele sıranın ne bıraktığı: STARTTLS’te komut verilene kadar geçen her şey ağda açıktadır.

Ölçüm: Gmail’in 587 Kapısında Şifreden Önce Ne Konuşuluyor?

Sahada bu soruya verilen standart cevap şudur: “587 şifreli porttur, oradan geçen her şey şifrelidir.” Ölçtüm. Bağlantının ilk yarısı düz metin okundu, ve sunucu bize kendi genel IP adresimizi de düz metinde söyledi.

Bu makalenin başındaki döküm zaten o ölçümün kendisiydi. Şimdi ona bir soru sorarak tekrar bakalım: listede 250-STARTTLS var, peki AUTH nerede?

Yok. Şifrelenmemiş bağlantıda sunucu, parola ile kimlik doğrulamayı teklif bile etmiyor.

Aynı bağlantıyı şifreye çevirip aynı EHLO komutunu tekrar yolladım. Bu, iki ayrı bağlantı değil; tek bir TCP oturumunun şifrelenmeden önceki ve sonraki hali. Komut şuydu:

printf 'EHLO test.sistemkusu.com\r\nQUIT\r\n' | openssl s_client -starttls smtp -connect smtp.gmail.com:587 -crlf -quiet

Şifrenin içinden gelen cevapta liste değişti:

250-smtp.gmail.com at your service, [31.223.xx.xx]
250-SIZE 36700160
250-8BITMIME
250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8

İki listeyi yan yana koyduğunuzda tek bir cümle çıkıyor:

• Şifreden önce: STARTTLS var, AUTH yok.
• Şifreden sonra: AUTH LOGIN PLAIN ... var, STARTTLS yok.

Sunucu, kanal şifrelenene kadar parola doğrulamayı hiç önermiyor; şifrelendikten sonra da şifrelemeyi tekrar önermiyor, çünkü zaten şifreli. Bu bir nezaket değil, bilinçli bir tasarım: AUTH PLAIN, adının söylediği gibi parolayı düz olarak taşır ve o yüzden yalnızca şifreli kanalda anlamlıdır.

Şifrelemenin kendisi de ölçüldü. Aynı oturumda kurulan TLS bağlantısı TLSv1.3 ile, TLS_AES_256_GCM_SHA384 şifre paketiyle ve X25519MLKEM768 anahtar değişimiyle kuruldu; bu son değer post-kuantum hibrit bir anahtar değişimidir, yani klasik ve kuantum dirençli iki yöntemi birlikte kullanır. Sertifika zinciri üç seviyeydi ve doğrulama başarılıydı. Anahtar değişiminin ne olduğu ve neden gerektiği şifrelemenin temelleri makalesinde anlatılıyor.

Bu ölçümün operasyonel karşılığı şu: STARTTLS kullanan bir bağlantıda şifreleme, istemci onu zorunlu tuttuğu için gerçekleşir. Mail programınızın şifreleme ayarı “otomatik” ya da “varsa kullan” olarak duruyorsa, sunucu STARTTLS satırını herhangi bir sebeple vermediğinde istemci sessizce düz metin devam edebilir. Kullanıcı hiçbir uyarı görmez, mail gider, parola ağda açık geçer. Ayarı denetlerken bakılacak yer port numarası değil, şifrelemenin zorunlu mu isteğe bağlı mı olduğudur.

Aynı sorunun dosya aktarımı tarafındaki hali daha önce ölçülmüştü: FTP, FTPS ve SFTP karşılaştırmasında parola da dosyanın içeriği de düz metin okunmuştu. Kalıp aynı, protokol farklı.

Port 25 Neden Kapalı? ISP Engellemesinin Ölçümü

Kendi mail sunucusunu kurmayı düşünen herkesin duyduğu standart cümle şudur: “Sunucuyu kurarız, 25 numaralı porttan gönderir.” Ölçtüm: o port abone hattından çıkmıyor.

Ama bunu “internet yavaş” ya da “firewall kapatmış” gibi belirsiz bir sonuca bağlamamak için, ölçümü aynı sunucunun aynı IP adresi üzerinde farklı portlarla yaptım. Böylece yol aynı, hedef aynı, değişen tek şey port numarası oluyor.

Aynı IP adresine 46 milisaniyede bağlanabiliyoruz, ama 25 numaralı portta sekiz saniye boyunca hiçbir cevap gelmiyor. Yol açık, hedef ayakta, engel portta. Altı bağımsız hedefe daha denedim, altısında da sonuç aynı çıktı.

Ölçüm için kullanılan komut:

Test-NetConnection smtp.yandex.com -Port 587

Sebebi spam. Ele geçirilmiş bir ev bilgisayarı, doğrudan alıcı kurumların mail sunucularına bağlanıp 25 numaralı porttan milyonlarca mesaj gönderebilir. Giden 25’i kapatmak bunu engelleyen yaygın bir uygulamadır ve meşru gönderimi etkilemez, çünkü meşru kullanıcı sunucusuna 587 üzerinden bağlanır.

Bir sınırı da yazalım: yukarıdaki ölçüm tek bir abone hattında yapıldı, yani sonucu “bütün sağlayıcılar her yerde kapatır” diye okumayın. Kapatma abone hatlarında yaygındır, kurumsal hatlarda ve sunucu barındırma sağlayıcılarında ise 25 çoğu zaman açıktır ya da talep üzerine açılır. Kendi hattınızda durumun ne olduğunu yukarıdaki komutla bir dakikada ölçebilirsiniz.

Sonucu ise mimaridir: ofisinize kurduğunuz bir mail sunucusu, karşı tarafın sunucusuna doğrudan teslim yapamaz. Sunucudan sunucuya teslim 25 numaralı portu kullanır ve o port kapalıdır. Kendi mail sunucunuzu işletmek istiyorsanız ya kurumsal bir hattaki açık 25 portuna ya da bir aktarım hizmetine ihtiyacınız olur. Bu, “kendi mail sunucumuzu kuralım” kararının önündeki en somut ve en sık atlanan engeldir.

Mail Gitmiyor: SMTP Tarafında Teşhis Sırası

Gitmeyen bir maili daraltmanın sırası vardır ve o sıraya uyduğunuzda çoğu arıza üç adımda kapanır.

1. Önce yönü doğrulayın. Kullanıcı gönderemiyor mu, yoksa gönderiyor ama karşı taraf almıyor mu? İkincisi gönderme arızası değildir; SMTP tarafı çalışıyor demektir ve aranacak yer başkadır.
2. Port erişimini ölçün. Giden için 587. Bağlantı hiç kurulamıyorsa sorun mail tarafında değil, ağ ya da güvenlik duvarı tarafındadır; güvenlik duvarı yapılandırması ilk bakılacak yerdir.
3. Sunucunun ne dediğine bakın. Hata kodu 4 ile mi 5 ile mi başlıyor? Dördüyse mail kuyrukta bekliyor ve beklemek bir eylemdir. Beşse reddediliş var ve gerekçe mesajın devamında yazar.
4. Bildirim nereye döndü. Teslim edilemedi bildirimi zarftaki adrese gider, başlıktakine değil. Kullanıcı bildirimi hiç görmüyorsa zarftaki gönderen adresi beklediğiniz adres olmayabilir.
5. Received başlıklarını aşağıdan yukarı okuyun. Gecikme varsa hangi iki aşama arasında olduğunu bu satırlar söyler.

Belirtiden başlamak isterseniz:

Dördüncü satır özellikle önemli, çünkü en sık yanlış yerde aranan arıza odur. Mail karşı tarafa ulaşıyorsa SMTP tarafı çalışıyor demektir; mesajın spam klasörüne düşmesi bir taşıma sorunu değil, bir güven sorunudur ve cevabı alan adınızın DNS kayıtlarında durur.

Ama tablodaki üçüncü ve dördüncü satırlar sandığınızdan daha yakın akraba, ve bu bağ sahada sık gözden kaçıyor. Alan adınızın yayınladığı policy, kendi mailiniz kimlik doğrulamayı geçemediğinde alıcının ne yapacağını belirler. Yani “spam’e düşüyor” ile “hiç gitmiyor” aynı kökten, farklı policy’yle çıkmış iki belirti olabilir:

Bu, kendi ayağınıza sıkabileceğiniz bir yapılandırmadır ve klasik senaryosu şudur: kimlik doğrulama kayıtlarınızı kurar, reject policy’ye geçersiniz, ama alan adınız adına mail gönderen kaynaklardan birini (faturalama yazılımı, pazarlama aracı, ofisteki çok fonksiyonlu yazıcı, bir bulut uygulaması) listeye eklemeyi unutursunuz. O kaynaktan çıkan mailler spam’e bile düşmez, hiç teslim edilmez ve kullanıcı size “sistem çalışmıyor” diye gelir.

Teşhiste ayırt edici işaret, dönen kalıcı ret metnidir: içinde kimlik doğrulama ya da policy ifadeleri geçiyorsa aradığınız yer sizin mail sunucunuz değil, alan adınızın DNS zone’udur.

Kayıtların kendisini, nasıl okunduklarını ve reject policy’ye hangi sırayla geçildiğini bu makale kapsamıyor. Onları kendi alan adımızın kayıtlarıyla ayrı bir yazıda anlattık.

Arıza gönderme değil alma tarafındaysa, yani kullanıcı gönderebiliyor ama gelen kutusu boşsa, bakılacak yer bu makale değil: IMAP ile POP3 arasındaki fark rehberimiz okuma tarafını ve onun kendi teşhis sırasını ele alıyor.

Sonuç: Zarf Yönlendirir, Başlık Gösterir

SMTP’yi tek cümlede toparlayalım: postayı yalnızca gönderir, teslimi tek adımda yapmaz ve kimin gönderdiğini kendi başına doğrulamaz.

Ama asıl kalması gereken şey tanım değil, altındaki iki ayrım. Birincisi zarf ile başlığın aynı şey olmadığı: sunucular yönlendirmeyi zarfa bakarak yapar, kullanıcı ise başlığı görür, ve ikisinin birbirini tutması protokol tarafından garanti edilmez. Sahte mail meselesinin teknik kökü tam olarak burada. İkincisi şifrelemenin sırasının önemli olduğu: STARTTLS kullanan bir bağlantıda komut verilene kadar geçen her şey ağda açıktadır, ve ölçtüğümüz oturumda sunucu bize kendi genel IP adresimizi tam da o açık kısımda söyledi.

Bu ikisinden birer soru doğuyor ve ikisinin de cevabı başka yerde. Kimlik doğrulama sorusu birincisinden çıkar ve cevabı alan adınızın DNS kayıtlarındadır. Şifreleme sorusu ikincisinden çıkar ve cevabı TLS’in kendi mekaniğindedir.

Otogar benzetmesine son kez dönelim: görevli sandığı otobüse verdi, aktarma merkezleri onu taşıdı, son durakta emanete bıraktı. SMTP’nin işi orada biter. Sandığı dolaptan kimin, nasıl ve hangi şartla alacağı ayrı bir protokolün konusu ve onu IMAP ile POP3 farkı rehberimizde ele alıyoruz.

Protokollerin birbirine nasıl bağlandığını ve bir kurumda hangilerinin pazarlık dışı olduğunu görmek isterseniz, protokollerin işlev gruplarını bir arada gösteren rehber bu makalenin de ait olduğu haritayı çiziyor.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn