- SMTP nedir, ne işe yarar?
- SMTP oturumu nasıl ilerler?
- SMTP hangi portları kullanır?
- SMTP bağlantısı nasıl test edilir?
- SMTP kimlik doğrulaması ve TLS
- SMTP, IMAP ve POP3 aynı işi mi yapar?
- SMTP gönderimi çalışmıyorsa nereden başlanır?
- SMTP sunucusu kurarken kritik ayarlar
- Sık Sorulan Sorular
- Kaynaklar
SMTP nedir, ne işe yarar?
Bir e-posta gönderdiğinizde mesaj alıcının bilgisayarına doğrudan gitmez. Önce kullandığınız uygulama bir SMTP submission sunucusuna bağlanır. Bu sunucu göndereni, alıcıyı ve mesaj verisini kabul eder; ardından alıcı alan adının MX kaydını bulup hedef posta sunucusuyla yeni bir SMTP oturumu açar.
SMTP, yani Simple Mail Transfer Protocol, e-postaların bir istemciden posta sunucusuna ve bir posta sunucusundan başka bir posta sunucusuna aktarılmasını sağlayan uygulama katmanı protokolüdür. Mesajın teslim edilip edilmediğini SMTP sunucuları arasındaki konuşma belirler. Gelen kutusunu okumak için ise genellikle IMAP veya POP3 kullanılır.
VPS yönetenler açısından ayrım önemli. Web uygulamanız çalışıyor olabilir; fakat uygulama yanlış porta, yanlış TLS moduna veya kimlik doğrulaması gerektiren bir sunucuya hatalı ayarlarla bağlanıyorsa gönderim başarısız olur. Sadece “SMTP bilgilerini girdim” demek bağlantının doğru kurulduğunu göstermiyor.
SMTP oturumu nasıl ilerler?
SMTP metin tabanlı bir istemci-sunucu iletişimi kurar. İstemci komut gönderir, sunucu üç haneli bir yanıt kodu döndürür. RFC 5321’deki temel akışta bağlantı kurulur, istemci kendisini tanıtır, gönderen ve alıcı bildirilir, ardından mesaj verisi aktarılır.
DNS ile hedef sunucuyu bulma
Gönderen sunucu, alıcının alan adı için MX kaydını sorgular. Örneğin ornek.com adresine mesaj gönderen bir sunucu, bu alan adının hangi posta sunucusunu kullandığını DNS üzerinden öğrenir. MX kaydı bulunamazsa bazı sunucular A veya AAAA kaydına başvurabilir; bu davranış düzgün bir posta yapılandırmasının yerine geçmez.
MX kaydını terminalden görmek için dig kullanırım:
dig +short MX ornek.com
Çıktıdaki sayı MX önceliğidir. Daha düşük sayı daha yüksek öncelik anlamına gelir. Birden fazla kayıt varsa gönderen sunucu genellikle önceliği en yüksek hedefi dener; bağlantı kurulamazsa diğer kayıtları değerlendirebilir.
DNS tarafındaki bir hata yalnızca SMTP’yi etkilemez. Alan adının diğer servisleri de aynı kayıt zincirine bağlıdır. Bu nedenle DNS sorunlarında panel ekranına güvenmeden dig ile sorgu yaparım. Tarayıcıda benzer bir hata görüyorsanız DNS_PROBE_FINISHED_NXDOMAIN Hatası Nasıl Çözülür? başlıklı yazıdaki kontrol adımları işinize yarayabilir.
TCP bağlantısı ve SMTP komutları
İstemci, hedef sunucunun ilgili portuna TCP bağlantısı açar. Sunucu bağlantıyı kabul ederse çoğunlukla 220 koduyla başlayan bir karşılama mesajı verir.
Temel komutlar kısaca şunlardır:
EHLOveya eski istemcilerdeHELO: İstemcinin kendisini tanıtması.MAIL FROM: Zarf göndereninin bildirilmesi.RCPT TO: Zarf alıcısının bildirilmesi.DATA: Konu, başlıklar ve mesaj gövdesinin aktarılması.QUIT: Oturumun düzgün biçimde kapatılması.
Buradaki zarf göndereni ile mesajın görünen From: başlığı aynı şey değildir. SMTP oturumunda verilen MAIL FROM değeri teslimat ve geri dönüş işlemlerinde kullanılır. Mesaj başlığındaki From: ise alıcının e-posta istemcisinde gördüğü alandır. Bu ayrımı atlamak, sahte gönderen adresleri ve teslimat sorunları incelenirken teşhisi zorlaştırır.
Mesaj verisinin aktarılması
Oturum kabaca şu sırada ilerler:
S: 220 mail.hedef.example ESMTP Postfix
C: EHLO gonderen.example
S: 250-mail.hedef.example
S: 250-PIPELINING
S: 250-STARTTLS
S: 250 AUTH PLAIN LOGIN
C: MAIL FROM:<[email protected]>
S: 250 2.1.0 Ok
C: RCPT TO:<[email protected]>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: Subject: Deneme
C:
C: Merhaba
C: .
S: 250 2.0.0 Ok: queued
C: QUIT
S: 221 2.0.0 Bye
DATA sonrasında tek başına gelen nokta veri bölümünün bittiğini belirtir. Sunucunun 250 queued yanıtı mesajı kabul ettiğini gösterir; mesajın alıcının gelen kutusuna kesinlikle ulaştığını değil. Hedef sunucu daha sonra spam filtresi uygulayabilir, teslimatı erteleyebilir veya mesajı reddedebilir.
SMTP hangi portları kullanır?
Port seçimi SMTP yapılandırmalarında sık karşılaştığım hatalardan biri. IANA kayıtlarında SMTP için 25, message submission için 587 ve TLS ile güvenli SMTP bağlantısı için 465 bulunur. RFC 6409, kullanıcıların mesaj teslim etmek üzere bağlandığı submission hizmetini sunucular arası SMTP aktarımından ayırır.
| Port | Yaygın kullanım | TLS biçimi | Kimlik doğrulama |
|---|---|---|---|
| 25 | Posta sunucuları arası aktarım | Başlangıçta düz bağlantı, gerekirse STARTTLS | Sunucu politikasına bağlı; istemci gönderimi için genellikle uygun değil |
| 587 | İstemci veya uygulamanın mesaj göndermesi | Çoğunlukla STARTTLS | Genellikle zorunlu |
| 465 | İstemci veya uygulamanın TLS ile SMTP bağlantısı | Bağlantının başından itibaren TLS | Genellikle zorunlu |
Port 25 ne zaman kullanılır?
Port 25, SMTP sunucularının birbirine mesaj teslim ettiği geleneksel porttur. Gönderen alan adının MX sunucusu, alıcının MX sunucusuna port 25 üzerinden bağlanabilir. Bu trafik sunucular arası olduğu için birçok VPS sağlayıcısı yeni sunucularda port 25 çıkışını sınırlayabilir. Amaç, spam gönderen kötüye kullanımları azaltmaktır.
Port 25’in engelli olması web uygulamanızın e-posta gönderemeyeceği anlamına gelmez. Uygulamayı bir relay veya submission hizmetinin 587 numaralı portuna yönlendirmek çoğu durumda doğru yaklaşımdır. Sağlayıcıdan blok kaldırılmasını istemek de mümkün; önce kendi SMTP sunucunuzu mu çalıştıracağınızı, yoksa harici bir relay mi kullanacağınızı netleştirin.
587 ve 465 arasındaki fark
Port 587, RFC 6409’a göre message submission için ayrılmıştır. İstemci genellikle düz TCP bağlantısıyla başlar, sunucunun EHLO yanıtında STARTTLS yeteneğini görür ve TLS oturumuna geçer. Kimlik doğrulama çoğunlukla TLS kurulduktan sonra yapılır.
Port 465’te TLS bağlantının ilk baytlarından itibaren başlar. Bu yönteme implicit TLS veya SMTPS denir. RFC 8314, güvenli submission için doğrudan TLS bağlantısını ve STARTTLS kullanımını ele alır. Uygulama ayarlarında “SSL” çoğu kütüphanede 465’i, “STARTTLS” ise 587’yi ifade eder.
Port numarasıyla şifreleme modunu karıştırmayın. 587’ye bağlanıp implicit TLS seçerseniz sunucu düz SMTP yanıtı gönderdiği için TLS el sıkışması başarısız olur. 465’e bağlanıp STARTTLS komutu göndermek de aynı hatalı eşleşmedir.
SMTP bağlantısı nasıl test edilir?
Ben önce ağ erişimini, sonra TLS’yi, en son uygulama ayarlarını test ederim. Her şeyi aynı anda değiştirmek sorunun yerini gizler. Portun açık olması da SMTP kimlik doğrulamasının veya mesaj tesliminin çalıştığını kanıtlamaz.
587 numaralı portta STARTTLS testi
openssl s_client -starttls smtp -connect smtp.ornek.com:587 -crlf -servername smtp.ornek.com
Başarılı bağlantıda sertifika zincirini ve TLS sürümünü görürsünüz. Ardından elle EHLO test.example yazdığınızda sunucunun yetenekleri listelenir. Çıktıda 250-STARTTLS görmeniz TLS’nin etkin olduğu anlamına gelmez; sunucunun bu özelliği sunduğunu gösterir.
465 numaralı portta TLS testi
openssl s_client -connect smtp.ornek.com:465 -crlf -servername smtp.ornek.com
465’te -starttls smtp kullanmıyorum, çünkü TLS bağlantının başında kuruluyor. Sertifika adı bağlandığınız hostname ile uyuşmuyorsa istemci doğrulama hatası verebilir. Sertifika kontrolünü kapatmak yerine alan adı ve sertifika yapılandırmasını düzeltin; güvenlik uyarısını susturmak çözüm değil.
Porta erişim var mı?
nc -vz smtp.ornek.com 587
Bu komut yalnızca TCP bağlantısının kurulup kurulamadığını sınar. succeeded çıktısı portun erişilebilir olduğunu söyler; SMTP hesabının doğru olduğunu söylemez. timed out sonucu güvenlik duvarı, sağlayıcı filtresi, yanlış IP veya ağ yönlendirmesiyle ilgili olabilir. Ağ yolunu incelemek gerektiğinde mtr kullanırım. TCP port testiyle rota analizini aynı şey sanmamak gerekiyor.
SMTP kimlik doğrulaması ve TLS
SMTP AUTH, gönderim yapan istemcinin kullanıcı adı ve parolayla tanınmasını sağlar. Kimlik doğrulama tek başına şifreleme sağlamaz. Kullanıcı adı ve parolanın düz bağlantıda gönderilmesi ağ üzerinde dinleme riski oluşturur. Güvenilir yapılandırmada önce TLS kurulur, ardından sunucunun sunduğu AUTH mekanizmalarından biri kullanılır.
Bir uygulamada şu bilgiler ayrı ayrı bulunur:
- SMTP hostname: Örneğin
smtp.ornek.com. - Port: Sağlayıcının önerdiği 587 veya 465.
- TLS modu: STARTTLS ya da doğrudan TLS.
- Kullanıcı adı: Çoğu hizmette tam e-posta adresi.
- Parola: Uygulamaya özel parola veya SMTP parolası olabilir.
- Gönderen adresi: Hesabın ya da sunucu politikasının izin verdiği adres.
Web uygulamasının hata günlüğünde parolayı açıkça bırakmayın. Ortam değişkenleri veya uygulamanın gizli yapılandırma mekanizması kullanılabilir. Dosya izinleri de yalnızca web servis kullanıcısının okuyabileceği şekilde sınırlandırılmalı. Her işi root ile yürütme alışkanlığı burada da geri teper.
SMTP, IMAP ve POP3 aynı işi mi yapar?
SMTP gönderme ve sunucular arası teslim işini yapar. IMAP ve POP3 ise teslim edilmiş mesajların kullanıcı tarafından alınması veya senkronize edilmesi için kullanılır. Gelen posta çalışırken giden posta çalışmayabilir; iki işlem farklı protokol, port ve kimlik doğrulama ayarlarına sahiptir.
| Protokol | Temel görev | Yaygın portlar |
|---|---|---|
| SMTP | Mesaj gönderme ve posta sunucuları arasında aktarım | 25, 465, 587 |
| IMAP | Mesajları sunucuda tutarak klasörlerle senkronize etme | 143, 993 |
| POP3 | Mesajları istemciye indirme | 110, 995 |
Bu ayrımı kendi laboratuvarımda da yaşayarak öğrendim. Bir kernel güncellemesinden sonra test makinem açılmadı; rescue mode’a geçip dosya sistemini bağladım, chroot içinde GRUB’u yeniden kurdum ve posta servisinin yapılandırmasını snapshot’tan karşılaştırdım. Sorun SMTP komutlarında değildi, güncelleme sonrası açılış zincirindeydi. O olaydan sonra servis ayarlarını değiştirmeden önce VPS snapshot’ı almayı ve kritik dosyaların geri dönüşünü denemeyi rutin haline getirdim. Snapshot tek başına yedek değil, ama kriz anında çok zaman kazandırıyor.
Uygulama bir proxy arkasındaysa veya upstream yanıt veremiyorsa SMTP’den bağımsız olarak 502 Bad Gateway Hatası Nedir ve Nasıl Çözülür? kontrol listesindeki yaklaşım yararlı olabilir. Hata kodu aynı görünse de web sunucusunun upstream’i ile SMTP sunucusunun bağlantısını ayrı ayrı incelemek gerekir.
SMTP gönderimi çalışmıyorsa nereden başlanır?
Benim kullandığım sıra şu:
- Hostname ve DNS: SMTP hostname’i doğru mu, DNS doğru IP’ye mi dönüyor?
dig +short A smtp.ornek.comve gerekiyorsadig +short AAAA smtp.ornek.comile kontrol edin. - Port erişimi: VPS sağlayıcısı port 25 çıkışını kısıtlıyor mu? 587 veya 465’e
ncile erişilebiliyor mu? - TLS modu: 465 için implicit TLS, 587 için STARTTLS seçilmiş mi? Sertifika hostname ile eşleşiyor mu?
- Kimlik bilgileri: Kullanıcı adı tam adres mi, parola güncel mi, SMTP AUTH etkin mi?
- Gönderen politikası:
MAIL FROMveFrom:adresleri hizmetin izin verdiği alan adlarıyla uyumlu mu? - Sunucu logları: Uygulamanın logu ile SMTP sunucusunun logunu aynı zaman aralığında karşılaştırın.
- DNS kimlik doğrulama kayıtları: SPF, DKIM ve DMARC kayıtları alıcı sunucuların mesajı reddetmesine veya spam klasörüne taşımasına neden olabilir.
SPF, DKIM ve DMARC SMTP komutları değildir. Bunlar alan adının gönderim yetkisini ve mesajın bütünlüğünü değerlendiren ek mekanizmalardır. SMTP oturumu başarıyla tamamlandığı halde mesaj gelen kutusuna düşmüyorsa sorun bu katmanda yaşanabilir.
Mesaj kuyrukta bekliyorsa hemen servisi yeniden başlatmak yerine hata kodunu okuyun. 4xx yanıtları çoğunlukla geçici sorun veya erteleme, 5xx yanıtları kalıcı ret anlamına gelir; kesin yorum sunucunun açıklama satırıyla yapılmalıdır.
Benim eski alışkanlığım kuyruğu temizlemek için servisi yeniden başlatmaktı. Logu okumadan yapılan bu hareket bazen sorunu çözmez, yalnızca teşhisi zorlaştırır. Önce kayıt, sonra müdahale.
SMTP sunucusu kurarken kritik ayarlar
Kendi Postfix veya başka bir MTA sunucunuzu kuruyorsanız yalnızca portu dinlemek yeterli değildir. Sunucunun kendi alan adı için yetkili olması, relay izinlerinin sınırlanması, TLS sertifikasının doğru tanımlanması ve DNS kayıtlarının uyumlu olması gerekir.
- Port 25’te açık relay bırakmayın. Kimliği doğrulanmamış herkesin başka alan adlarına mesaj gönderebilmesi ciddi kötüye kullanım riskidir.
- Submission için 587’yi ayrı bir politikayla çalıştırın ve kimlik doğrulamayı zorunlu tutun.
- 465 kullanıyorsanız doğrudan TLS yapılandırmasını, 587 kullanıyorsanız STARTTLS politikasını test edin.
- PTR, A veya AAAA, MX ve gerektiğinde SPF kayıtlarının birbiriyle çelişmediğini kontrol edin.
- Mail kuyruğunu, başarısız teslimatları ve disk kullanımını izleyin. Biriken kuyruk çoğu zaman sorunun kendisi değil belirtisidir.
- Yedekleri yalnızca almakla kalmayın; posta kutusu ve yapılandırma geri dönüşünü de test edin.
SMTP sunucusu internete açık bir hizmettir. SSH için fail2ban ve nftables kullanmak iyi bir başlangıç olabilir; mail servisinin kendi rate limit, relay ve kimlik doğrulama kurallarını ayrıca yapılandırmanız gerekir. SSH portunu değiştirmek tek başına güvenlik sayılmadığı gibi SMTP portunu değiştirmek de spam sorununu çözmez.
Şifreli bağlantı tarafında sertifika kurulumunu incelemek isterseniz VPS’te SSL Sertifikası Kurulumu: Let’s Encrypt Rehberi başlangıç için uygun bir referanstır. SMTP sertifikası web sunucusunun sertifikasıyla aynı olabilir; fakat her servis için dosya yolu ve yenileme sonrası reload davranışı ayrı kontrol edilmelidir.
SMTP ile e-posta gönderiminin nasıl çalıştığını öğrendikten sonra, gelen mesajların farklı cihazlarda nasıl eşitlendiğini merak ediyorsanız IMAP nedir ve nasıl erişilir? rehberime de göz atabilirsiniz. Bu yazıda IMAP bağlantısı, portları ve hesap kurulum adımlarını pratik şekilde anlattım.
Sık Sorulan Sorular
SMTP portu olarak 25 mi, 587 mi kullanılmalı?
Bir uygulama veya e-posta istemcisi mesaj gönderecekse genellikle 587 ve STARTTLS tercih edilir. Port 25 daha çok posta sunucuları arasındaki teslimat için kullanılır ve VPS sağlayıcıları bu portun çıkışını kısıtlayabilir.
465 ve 587 arasındaki temel fark nedir?
465 numaralı portta TLS bağlantının en başında kurulur. 587 numaralı portta bağlantı SMTP olarak başlar ve STARTTLS komutuyla TLS’ye geçer. Uygulamanın seçtiği güvenlik modu portla uyumlu olmalıdır.
SMTP ile e-posta okunabilir mi?
Hayır. SMTP mesaj göndermek için, IMAP veya POP3 ise gelen mesajlara erişmek için kullanılır. Bir hesabın gönderme ayarlarının çalışması, gelen posta ayarlarının da doğru olduğu anlamına gelmez.
SMTP bağlantısı başarılı olduğu halde e-posta neden gelmez?
SMTP sunucusunun mesajı kabul etmesi teslimatın tamamlandığını garanti etmez. SPF, DKIM, DMARC, alıcı sunucunun spam politikası, kuyrukta yaşanan gecikme veya gönderen alan adının itibarı sonraki aşamada etkili olabilir. İlgili SMTP yanıtı ve sunucu logları birlikte incelenmelidir.
Kaynaklar
- RFC 5321 – Simple Mail Transfer Protocol — rfc-editor.org
- RFC 6409 – Message Submission for Mail — rfc-editor.org
- RFC 8314 – Cleartext Considered Obsolete — rfc-editor.org
- IANA – Service Name and Transport Protocol Port Number Registry — iana.org
Türkçe
English
فارسی
Русский