Güvenlik·
6 Nisan 2026
Her gün milyarlarca e-posta gönderilirken bu mesajların gerçekten iddia ettikleri kaynaktan gelip gelmediğini nasıl bilebiliriz? SMTP protokolü 1982 yılında tasarlandığında kimlik doğrulama mekanizması içermiyordu; bu boşluk onlarca yıl boyunca spam ve kimlik sahtekarlığının önünü açtı. SMTP Auth, bu açığı kapatan temel güvenlik mekanizmasıdır ve günümüzde kurumsal e-posta altyapısının vazgeçilmez bir parçasıdır.
SMTP (Simple Mail Transfer Protocol), e-posta iletiminin omurgasını oluşturur. İlk RFC'si olan RFC 821 (1982, sonradan RFC 2821 ve ardından RFC 5321 olarak güncellendi) temel bir tasarım eksikliği barındırıyordu: herhangi bir sunucu, herhangi bir adresten e-posta gönderebiliyordu. Kimlik doğrulama zorunlu değildi.
Bu açık, yıllar içinde spam ve phishing saldırılarının temel istismar vektörü hâline geldi. 1990'lı yılların sonlarında gelişen İnternet'te "açık röle" (open relay) sunucular, dünyanın her yerinden spam gönderimlerine aracılık etti. Çözüm olarak SMTP AUTH uzantısı geliştirildi ve 2007 yılında RFC 4954 ile standartlaştırıldı.
SMTP Auth, istemcinin sunucuya bağlandıktan sonra AUTH komutuyla kimliğini kanıtlamasını zorunlu kılar. Sunucu, desteklediği kimlik doğrulama mekanizmalarını EHLO yanıtında listeler; istemci bu listeden birini seçer ve kimlik bilgilerini sunar.
Tipik bir SMTP Auth el sıkışması şu adımlardan oluşur:
EHLO komutu gönderir.250-AUTH LOGIN PLAIN CRAM-MD5 gibi desteklenen mekanizmaları bildirir.AUTH LOGIN gibi bir mekanizma seçer.235 Authentication successful döner; aksi hâlde 535 hata kodu ile reddeder.RFC 4954 birden fazla kimlik doğrulama mekanizmasını tanımlar. Aşağıdaki tablo başlıca mekanizmaları güvenlik açısından karşılaştırmaktadır:
| Mekanizma | Güvenlik Düzeyi | Şifre İletimi | TLS Gerekliliği | Kullanım Durumu |
|---|---|---|---|---|
| PLAIN | Düşük (tek başına) | Base64 (şifresiz) | Zorunlu | TLS üzerinde yaygın kullanım |
| LOGIN | Düşük (tek başına) | Base64 (şifresiz) | Zorunlu | Eski istemci uyumluluğu |
| CRAM-MD5 | Orta | Hash (challenge-response) | Önerilir | Eski sistemler |
| DIGEST-MD5 | Orta | Hash (challenge-response) | Önerilir | Büyük ölçüde kullanım dışı |
| SCRAM-SHA-256 | Yüksek | Salted hash, sunucu kanıtı | Önerilir | Modern kurumsal sistemler |
| XOAUTH2 | Çok yüksek | OAuth 2.0 token | Zorunlu | Google Workspace, Microsoft 365 |
Önemli not: PLAIN ve LOGIN mekanizmaları, kimlik bilgilerini yalnızca Base64 ile kodlar; şifrelemez. Bu nedenle bu mekanizmalar yalnızca TLS (Transport Layer Security) tüneli içinde kullanılmalıdır. RFC 4954, bölüm 9'da bu zorunluluk açıkça belirtilmiştir.
SMTP Auth, e-posta güvenliğinin tek ayağı değildir; SPF, DKIM ve DMARC ile birlikte çalışan bir ekosistem oluşturur:
Bülten ve kampanya e-postaları gönderen işletmeler için SMTP Auth kritik bir işlevsel zorunluluktur. E-posta servis sağlayıcıları (ESP), müşterilerine ayrı SMTP kimlik bilgileri atayarak:
Bu denetim izlenebilirliği, Türk hukukunda da doğrudan karşılık bulmaktadır.
Türkiye'de ticari e-posta gönderimi, iki temel kanunla düzenlenmiştir:
Sistem yöneticileri ve geliştiriciler için SMTP Auth yapılandırmasında dikkat edilmesi gereken başlıca noktalar şunlardır:
smtpd_tls_auth_only = yes ayarı, TLS tüneli kurulmadan kimlik doğrulama girişimlerini engeller.Teknik olarak mümkündür; port 25 üzerinden sunucular arası iletimde AUTH kullanılmaz. Ancak son kullanıcı veya uygulama kaynaklı gönderimlerde (port 587/465) modern e-posta sunucularının neredeyse tamamı SMTP Auth zorunlu kılar. Auth olmadan gönderilen e-postalar büyük ihtimalle spam olarak işaretlenir veya reddedilir.
PLAIN ve LOGIN mekanizmaları kimlik bilgilerini yalnızca Base64 ile kodlar; bu bir şifreleme değil, yalnızca bir dönüştürme işlemidir. Ağ trafiği ele geçirildiğinde kimlik bilgileri kolayca çözülebilir. Bu nedenle RFC 4954, bu mekanizmaların yalnızca TLS tüneli içinde kullanılmasını şart koşar.
SMTP Auth, gönderici istemcinin sunucuya olan kimliğini doğrular (gönderim yetkisi). SPF, gönderen IP'nin alan adı tarafından yetkilendirilip yetkilendirilmediğini kontrol eder. DKIM, mesajın değiştirilmediğini kriptografik imzayla kanıtlar. DMARC ise bu iki kontrolü bir politikaya bağlar. Dört mekanizma birbirini tamamlar; birinin varlığı diğerlerinin gereksizliğini doğurmaz.
Evet. Toplu gönderimde (bülten, kampanya, işlemsel e-posta) SMTP Auth, hesap kimliğinizi ve gönderim itibarınızı korur. Kimlik doğrulama olmadan sisteminiz açık röle olarak kötüye kullanılabilir; bu durum IP'nizin kara listelere girmesine ve tüm e-posta teslimatınızın çökmesine yol açar.
Port 587, RFC 6409 ile tanımlanan "mail submission" (posta gönderim) portunun standart numarasıdır. Son kullanıcı ve uygulama kaynaklı gönderimlerde bu port kullanılır ve SMTP Auth burada zorunludur. Port 25 ise MTA'lar arası iletim için ayrılmıştır ve birçok ISP tarafından son kullanıcılara kapatılmaktadır.
Geleneksel SMTP Auth kullanıcı adı ve şifre kullanırken, XOAUTH2 mekanizması OAuth 2.0 erişim token'ı kullanır. Token'lar belirli bir süre ve kapsam için geçerlidir; çalınsa bile sınırlı hasar verir. Microsoft 365 ve Google Workspace, 2022'den itibaren temel kimlik doğrulamayı (Basic Auth) aşamalı olarak devre dışı bırakarak OAuth 2.0'a geçişi zorunlu kılmıştır.
Evet. 6563 sayılı ETK ve bağlı yönetmelik, ticari elektronik ileti gönderen tarafların kimliğinin doğrulanabilir olmasını şart koşar. SMTP Auth, teknik düzeyde bu doğrulamayı sağlar. Ayrıca 6698 sayılı KVKK kapsamında kimlik bilgilerinin şifreli kanallar (TLS) üzerinden iletilmesi, kişisel verilerin korunması için alınması gereken teknik tedbirler arasında değerlendirilebilir.
RFC 4954 kapsamında 535 ("Authentication credentials invalid") kodu, geçersiz kimlik bilgisi girişinde dönen standart hata kodudur. 534 kodu ise seçilen mekanizmanın sunucu politikasıyla uyumsuz olduğunu bildirir. 530 kodu, kimlik doğrulama yapılmadan gönderim girişiminde döner.
Türk hukukunda genel log saklama süresi için tek bir zorunluluk yoktur; ancak BTK'nın trafik/erişim log saklama yükümlülükleri (5651 sayılı Kanun kapsamında) bazı servis sağlayıcılar için 1-2 yıl olarak belirlenmiştir. Kurumsal BT politikaları ve veri ihlali bildirimi gibi KVKK yükümlülükleri göz önüne alındığında, SMTP Auth loglarının en az 1 yıl saklanması önerilir.
Komut satırında openssl s_client -connect mail.example.com:587 -starttls smtp komutuyla TLS el sıkışması ve AUTH süreci izlenebilir. Alternatif olarak swaks (Swiss Army Knife for SMTP) aracı, SMTP Auth testleri için yaygın kullanılan açık kaynaklı bir araçtır. Python'da smtplib kütüphanesi de test senaryoları için kullanılabilir.
Reklamsız, KVKK uyumlu; kurulum ve geçiş ücretsiz, mailleri biz taşırız.