SMTP Kimlik Doğrulama Hatası: Şifre Doğru Ama Mail Gitmiyor

Mail hesabınızı kurdunuz, gelen kutusu sorunsuz doluyor, ama gönder tuşuna bastığınız anda ekrana bir kutu çıkıyor: "Kullanıcı adı veya parola kabul edilmedi" ya da doğrudan İngilizcesiyle SMTP authentication failed. Parolayı üç kez kontrol ediyorsunuz, webmail'e aynı parolayla giriyorsunuz, sorun yok. SMTP kimlik doğrulama hatası tam olarak bu noktada başlar ve Türkçe kaynakların neredeyse tamamı tek bir öneri verir: "şifrenizi yeniden girin". Oysa gelen maillerin çalışıp giden maillerin çalışmaması, parolanın yanlış olmadığının en güçlü kanıtıdır — çünkü ikisi de aynı parolayı kullanır.

Bu yazıda, doğru parolaya rağmen SMTP'nin reddetmesinin gerçek nedenlerini sırasıyla ele alacağız: kimlik doğrulama kutucuğunun kapalı olması, kullanıcı adının tam e-posta adresi olarak yazılmaması, 465 ile 587 portlarının farklı şifreleme türü istemesi, sunucu adı ile sertifika uyuşmazlığı, sunucu tarafındaki saatlik gönderim kilidi ve arka planda unutulmuş bir cihazın tetiklediği IP bloklaması. Her adımda ne kontrol edeceğinizi, hangi ekranda hangi kutucuğa bakacağınızı ve terminalden nasıl doğrulayacağınızı bulacaksınız. Sıralamayı bozmadan gidin; üstteki maddeler vakaların büyük çoğunluğunu kapsar.

Hata Mesajı Aslında Ne Söylüyor#

Ekrandaki Türkçe metin genelleştirilmiştir; asıl bilgi arkasındaki SMTP kodundadır ve üç farklı kod tamamen farklı sorunlara işaret eder.

Bu ayrım kritiktir: 530 ve 550 5.7.1 aldığınızda parolayı değiştirmenin hiçbir faydası yoktur, çünkü sunucuya parola hiç gönderilmemiştir. Yalnızca 535 gerçekten "gönderdiğin bilgiyi beğenmedim" demektir. Kod ailelerinin tamamı için SMTP hata kodları ve anlamları yazısına bakabilirsiniz.

Kodu göremiyorsanız, mail programınızın günlük kaydını açmadan da terminalden birkaç saniyede üretebilirsiniz; bunu aşağıda göstereceğim.

Adım 1: Kullanıcı Adı Tam E-posta Adresi Olmalı#

Yıllardır gördüğüm en yaygın tek sebep budur: kullanıcı adı alanına muhasebe yazılması. Çoğu posta sunucusu sanal posta kutularını alan adıyla birlikte tutar ve yalnızca [email protected] biçimini tanır.

Bu hatanın kafa karıştırıcı yanı, webmail'e girerken çoğu panelin kısa adı da kabul etmesidir. Kullanıcı webmail'e muhasebe ile girer, çalıştığını görür, aynı bilgiyi Outlook'a yazar ve 535 alır. İkisi farklı doğrulama yolları kullandığı için bu tutarsızlık normaldir.

Kontrol edin:

• Kullanıcı adında @ işareti ve alan adı var mı?
• Alan adı doğru yazılmış mı? ornekfirma.com ile ornekfirma.com.tr ayrı hesaplardır.
• Büyük/küçük harf sorunu var mı? Adresin tamamını küçük harfle yazın.
• Kullanıcı adı alanına yanlışlıkla adınız-soyadınız yazılmış olabilir; bazı istemciler "Görünen ad" ile "Kullanıcı adı" alanlarını yan yana gösterir.

Hesabın gerçek adını cPanel'de E-posta → E-posta Hesapları ekranında görebilirsiniz; listede yazan tam adres, kullanıcı adı olarak kullanmanız gereken değerdir. Hesabın nasıl oluşturulduğunu ve hangi bilgilerin nereden alındığını cPanel'de e-posta hesabı oluşturma yazısında bulabilirsiniz.

Adım 2: "Giden Sunucum Kimlik Doğrulama Gerektiriyor" Kutucuğu#

İkinci en yaygın sebep, gönderim tarafında kimlik doğrulamanın hiç açılmamış olmasıdır. Gelen posta ayarlarında kullanıcı adı ve parola zaten zorunludur, bu yüzden mail okumak çalışır; giden posta tarafında ise bu ayar ayrıdır ve varsayılan olarak kapalı gelebilir.

Outlook (masaüstü):

1. Dosya → Hesap Ayarları → Hesap Ayarları.
2. Hesabı seçin → Değiştir → Diğer Ayarlar.
3. Giden Sunucu sekmesine geçin.
4. "Giden sunucum (SMTP) kimlik doğrulaması gerektiriyor" kutucuğunu işaretleyin.
5. Altındaki "Gelen posta sunucumla aynı ayarları kullan" seçeneğini seçin.

Thunderbird:

1. Hesap Ayarları → en alttaki Giden Sunucu (SMTP).
2. Kullandığınız sunucuyu seçip Düzenle.
3. Kimlik doğrulama yöntemi: Normal parola.
4. Kullanıcı adı alanına tam e-posta adresini yazın.

iPhone / iPad:

1. Ayarlar → Uygulamalar → Mail → Mail Hesapları → hesabınız.
2. Hesap satırına dokunun → SMTP → birincil sunucu.
3. Kullanıcı adı ve parola alanlarını doldurun; iOS bu alanları "İsteğe bağlı" diye gösterir ve kullanıcılar bu yüzden boş bırakır. Boş bırakılırsa gönderim çalışmaz.

Android (Gmail uygulaması ile kurulan diğer hesaplar):

Hesap ayarlarında "Giden sunucu ayarları" altında "Oturum açmayı gerektir" seçeneği işaretli olmalıdır.

iOS'taki "isteğe bağlı" ifadesi, bu maddeyi tek başına yaygın bir arıza kaynağı hâline getirir. Bir iPhone kullanıcısı "şifre doğru ama gitmiyor" diyorsa ilk bakılacak yer burasıdır. İstemci kurulumunun tamamı için Outlook ile e-posta istemci kurulumu yazısındaki ekran adımlarını izleyebilirsiniz.

Adım 3: Port ile Şifreleme Türü Eşleşmeli#

Üçüncü sebep, port ile şifreleme türünün çaprazlanmasıdır. Bu durumda oturum kimlik doğrulama aşamasına gelmeden koptuğu için istemci size çoğu zaman yine "parola hatalı" der — hâlbuki parola hiç gönderilmemiştir.

Fark şudur: 587 portunda bağlantı şifresiz başlar, istemci STARTTLS komutuyla şifrelemeye geçer, sonra parola gönderilir. 465 portunda bağlantı daha ilk saniyeden şifrelidir, TLS el sıkışması olmadan tek bir komut bile konuşulmaz.

Bu yüzden 465 portunu seçip şifreleme türünü "STARTTLS" bırakırsanız istemci düz metin göndermeye çalışır, sunucu anlamaz ve bağlantı düşer. Tersi de aynı şekilde başarısız olur. Hangi portun hangi durumda kullanılacağını ayrıntılı olarak mail portları hangisi kullanılır yazısında bulabilirsiniz.

Dördüncü bir olasılık da 25 portunun kullanılmasıdır. Türkiye'de ve dünyada birçok internet servis sağlayıcısı, ev ve mobil bağlantılarda 25 portuna giden trafiği engeller. Bu engel spam kaynaklı bir güvenlik önlemidir ve kaldırılamaz; istemci gönderimi için 587 veya 465 kullanılmalıdır. Ofiste çalışan bir kurulumun evden çalışmaması çoğu zaman tam olarak bu yüzdendir.

Adım 4: Sunucu Adı ve Sertifika Uyumu#

Dördüncü sebep, doğru parolayla yanlış kapıyı çalmaktır. Gönderim sunucusu adı olarak alan adınızın kendisini (ornekfirma.com.tr) yazdığınızda, o alan adı bir web sunucusuna işaret ediyorsa posta servisi orada olmayabilir.

Doğru sunucu adını iki yerden öğrenirsiniz: hosting firmanızın verdiği kurulum bilgileri ya da cPanel'in E-posta Hesapları → Bağlan Aygıtlar ekranındaki otomatik yapılandırma tablosu. Orada yazan sunucu adı genellikle mail.alanadiniz.com biçimindedir.

Sunucu adının bir de sertifika boyutu vardır. Sunucunun TLS sertifikası mail.alanadiniz.com için düzenlenmişse ve siz alanadiniz.com yazarsanız, istemci sertifika uyuşmazlığı görür. Bazı istemciler uyarı gösterip devam eder, bazıları sessizce bağlantıyı keser ve size genel bir kimlik doğrulama hatası verir. Sertifikanın kimin için düzenlendiğini terminalden görebilirsiniz:

openssl s_client -starttls smtp -connect mail.ornekfirma.com.tr:587 -servername mail.ornekfirma.com.tr < /dev/null 2>/dev/null | openssl x509 -noout -subject -dates

Çıktıdaki subject=CN= değeri, istemciye yazmanız gereken sunucu adıdır. Tarih satırları da sertifikanın süresini gösterir; süresi dolmuş bir sertifika, katı yapılandırılmış istemcilerde aynı belirsiz hatayı üretir.

Bir de "otomatik yapılandırma" tuzağı vardır: istemciler hesabı eklerken sunucu adlarını kendileri tahmin eder ve sık sık yanlış tahmin ederler. Hesabı eklerken elle yapılandırma seçeneğini kullanıp tüm alanları kendiniz doldurmak, bu sınıftaki hataların tamamını önler.

Adım 5: Sunucu Tarafındaki Gönderim Kilidi#

Beşinci sebep, Türkçe kaynaklarda neredeyse hiç geçmeyen ama destek kayıtlarında sık görülen bir durumdur: parolanız doğrudur, ayarlarınız doğrudur, ama sunucu sizi bilerek engelliyordur.

Saatlik gönderim kotası. Paylaşımlı hosting sunucularında her alan adı ve çoğu zaman her posta kutusu için saatlik gönderim sınırı vardır. Bu sınırı aştığınızda gönderim reddedilir ve bazı istemciler bunu da "kimlik doğrulama hatası" olarak gösterir. Sunucu tarafındaki gerçek metin şuna benzer:

550 Sorry, you have exceeded your maximum hourly email limit

Kotayı cPanel'de E-posta Hesapları → Yönet ekranındaki "Kısıtlamalar" bölümünde görebilirsiniz. Sınıra takıldıysanız yapılacak tek şey bir sonraki saati beklemektir; sürekli takılıyorsanız gönderim hacminiz paylaşımlı ortamın üzerine çıkmış demektir.

Başarısız giriş kilidi. Sunucular, arka arkaya birkaç başarısız giriş denemesinden sonra kaynak IP'yi geçici olarak engeller. cPanel/WHM tarafında bu görev cPHulk ve güvenlik duvarı katmanına aittir. İşin sinsi tarafı şudur: unuttuğunuz bir cihaz — eski bir telefon, ofisteki ikinci bilgisayar, kapatılmamış bir yazıcı tarama hesabı — eski parolayla dakikada bir denemeye devam eder. O cihaz sizin IP'nizi bloklatır ve doğru parolayla siz de giremezsiniz. "Şifre doğru ama kabul etmiyor" cümlesinin en sinir bozucu sebebi budur.

Bu şüpheyi test etmenin en hızlı yolu, telefonun mobil verisine geçip (yani farklı bir IP'den) aynı hesapla göndermeyi denemektir. Mobil veride çalışıyorsa sorun parolada değil, ofis IP'nizin bloklanmasındadır. Çözüm sırası:

1. Parolayı değiştirdiyseniz tüm cihazlarda güncelleyin; unutulan cihaz kalmasın.
2. Yazıcı, tarayıcı, kamera, POS gibi mail gönderen cihazları da listeye ekleyin.
3. Bloklama kalkana kadar bekleyin ya da hosting firmanızdan IP'nizin engelini kaldırmasını isteyin.

Hesap askıya alınması. Kutu kotası dolduğunda bazı yapılandırmalar gönderimi de durdurur; ele geçirilmiş hesaplar ise doğrudan kapatılır. Webmail'e girebiliyor ama gönderemiyorsanız kota ekranını mutlaka kontrol edin.

Adım 6: Parolanın Kendisi#

Sıralamada altıncı sıradadır, çünkü ilk beş madde vakaların çoğunu kapsar. Yine de parolanın gerçekten sorunlu olduğu durumlar vardır:

• Kopyala-yapıştır artığı. Parolayı bir belgeden kopyaladığınızda sonuna görünmez bir boşluk veya satır sonu karakteri eklenir. Elle yazarak test edin.
• Özel karakterler. #, %, &, $ gibi karakterler bazı istemcilerde ve özellikle uygulama yapılandırma dosyalarında sorun çıkarır. Bir bağlantı dizesi içine gömülüyorsa kaçış gerektirir.
• E-posta parolası ≠ panel parolası. Posta kutusunun parolası, cPanel giriş parolanızdan tamamen ayrıdır. İkisini karıştırmak yaygın bir hatadır.
• Uygulama parolası. Gönderimi Gmail veya Microsoft hesabı üzerinden yapıyorsanız ve hesapta iki adımlı doğrulama açıksa, normal hesap parolanız SMTP'de çalışmaz; sağlayıcının ürettiği ayrı bir uygulama parolası gerekir.

Parolayı sıfırlayacaksanız, özel karakter yerine uzunluk tercih edin: on altı karakterlik harf-rakam bir parola, sekiz karakterlik karmaşık bir paroladan hem daha güvenli hem de her istemcide sorunsuzdur. Güçlü bir değer üretmek için şifre üretici aracını kullanabilirsiniz.

Elle Doğrulama: Terminalden AUTH LOGIN Testi#

Tahmin etmeyi bırakıp sunucunun ne dediğini görmek istiyorsanız, oturumu elle açın. Bu test hangi adımda takıldığınızı kesin olarak söyler.

Önce kullanıcı adı ve parolanın base64 karşılığını üretin:

printf '[email protected]' | base64
printf 'parolanizburada' | base64

Sonra şifreli oturumu açın:

openssl s_client -starttls smtp -crlf -connect mail.ornekfirma.com.tr:587

Sunucu 220 ile karşıladıktan sonra sırayla yazın:

EHLO test.ornekfirma.com.tr
AUTH LOGIN
<base64 kullanıcı adı>
<base64 parola>

Sonucu şöyle yorumlayın:

• 235 2.7.0 Authentication successful → Kimlik doğrulama çalışıyor. Sorun parolada değil; ayarlarınızın başka bir yerinde ya da sunucu kotasında.
• 535 5.7.8 → Sunucu bilgileri gerçekten reddediyor. Kullanıcı adı biçimini ve hesap kilidini kontrol edin.
• EHLO cevabında 250-AUTH LOGIN PLAIN satırı yoksa → Sunucu o bağlantıda kimlik doğrulamaya izin vermiyor; büyük olasılıkla şifrelenmemiş bir kanaldasınız ve önce STARTTLS gerekiyor.
• Bağlantı hiç kurulmuyorsa → Port engellidir; 465 veya 2525 deneyin.

465 portunu test etmek için komut farklıdır, çünkü orada STARTTLS yoktur:

openssl s_client -crlf -connect mail.ornekfirma.com.tr:465

Bu ayrım, üçüncü adımdaki port/şifreleme farkının somut hâlidir: -starttls smtp parametresini 465 ile kullanırsanız komut da hata verir.

Port ve TLS uyumunu elle hesaplamak istemiyorsanız SMTP test aracı seçtiğiniz porta göre doğru komutları hazır üretir ve olası uyumsuzlukları önceden uyarır.

Site ve Uygulamalardan Gönderimde Ek Kontroller#

Hata bir mail programında değil de sitenizin iletişim formunda ya da e-ticaret bildirimlerinde çıkıyorsa, kontrol listesi biraz farklıdır:

1. Kimlik doğrulama açık mı? PHPMailer benzeri kütüphanelerde SMTPAuth değeri açık olmalıdır; kapalıyken tam olarak 550 5.7.1 alınır.
2. Şifreleme türü doğru mu? SMTPSecure değeri 587 için STARTTLS, 465 için doğrudan TLS olmalıdır.
3. Gönderen adresi kimliği doğrulanan hesapla aynı mı? Formdan gelen ziyaretçinin adresini From alanına yazmak, 550 5.7.1 Sender address rejected üretir. Ziyaretçinin adresi Reply-To alanına yazılmalı, From her zaman sizin hesabınız olmalıdır.
4. Zaman aşımı yeterli mi? Kısa zaman aşımlarında bağlantı el sıkışması tamamlanmadan kopar ve hata mesajı yine belirsiz olur.

WordPress kullanıyorsanız bu ayarların tamamı bir SMTP eklentisi üzerinden yapılır; yapılandırma adımları WordPress SMTP e-posta ayarları yazısında anlatılıyor. Sitenizden çıkan bildirimlerin hiç ulaşmaması durumunda ise sorun kimlik doğrulamadan çok teslimat tarafında olabilir; o zaman geri dönen bildirimi okumak gerekir ve bunun için bounce mesajı nasıl okunur yazısındaki satır anatomisi işinizi görür.

Sıkça Sorulan Sorular#

Gelen mailler çalışıyor ama giden çalışmıyor, sebebi nedir#

Bu tablo neredeyse her zaman gönderim tarafındaki kimlik doğrulama ayarının kapalı olduğunu gösterir. Gelen posta ayarları kullanıcı adı ve parolayı zorunlu tutar, ancak giden sunucu ayarları ayrı bir bölümdür ve varsayılan olarak kimlik doğrulamasız gelebilir. Mail programınızda giden sunucu ayarlarını açıp "kimlik doğrulaması gerektiriyor" seçeneğini işaretleyin ve gelen sunucuyla aynı bilgileri kullanmasını söyleyin. İkinci olasılık, giden port ile şifreleme türünün eşleşmemesidir.

465 ile 587 arasındaki fark nedir, hangisini seçmeliyim#

587 portunda bağlantı şifresiz başlar ve STARTTLS komutuyla şifrelemeye geçer; 465 portunda ise bağlantı ilk saniyeden itibaren şifrelidir. İkisi de güvenlidir ve doğru yapılandırıldığında aynı sonucu verir. Genel öneri 587 kullanmaktır, çünkü istemci gönderimi için standart olarak belirlenmiş porttur. Ancak asıl önemli olan, seçtiğiniz portla şifreleme ayarının uyuşmasıdır: 465 seçip STARTTLS işaretlerseniz bağlantı kurulamaz ve istemci size yanıltıcı biçimde parola hatası gösterir.

Kullanıcı adı olarak ne yazmalıyım#

Kullanıcı adı olarak tam e-posta adresinizi yazın, yani [email protected] biçiminde. Yalnızca hesap adını (muhasebe) yazmak sunucuların çoğunda reddedilir, çünkü sanal posta kutuları alan adıyla birlikte kaydedilir. Webmail arayüzü kısa adı kabul ettiği için kullanıcılar bu ayrımı fark etmez; webmail ile istemci farklı doğrulama yolları kullanır. Adresin tamamını küçük harfle yazmanız da iyi bir alışkanlıktır.

Parolam doğru olduğu hâlde 535 hatası alıyorum#

Bu durumda ilk şüphelenmeniz gereken şey, IP adresinizin başarısız giriş denemeleri nedeniyle geçici olarak engellenmiş olmasıdır. Genellikle sebep, eski parolayla sürekli deneme yapan unutulmuş bir cihazdır: ikinci bir telefon, ofisteki eski bir bilgisayar ya da tarama sonuçlarını mail atan bir yazıcı. Test etmek için telefonunuzu mobil veriye alıp farklı bir IP'den gönderim deneyin; orada çalışıyorsa teşhis kesindir. Çözüm, parolayı tüm cihazlarda güncellemek ve engelin kalkmasını beklemek ya da hosting firmanızdan kaldırılmasını istemektir.

Ofiste çalışıyor ama evden çalışmıyor#

Bu ayrım büyük olasılıkla port engellemesinden kaynaklanır. Birçok internet servis sağlayıcısı ev ve mobil bağlantılarda 25 portuna giden trafiği spam önlemi olarak engeller; ofis bağlantılarında bu engel çoğu zaman yoktur. Mail programınızın giden sunucu portu 25 ise 587 veya 465 olarak değiştirin ve şifreleme ayarını buna göre eşleyin. İkinci olasılık, ev bağlantınızın IP'sinin sunucu tarafında bloklanmış olmasıdır; bu durumda başka bir ağdan test etmek ayrımı netleştirir.

iPhone'da mail gönderilmiyor, ne yapmalıyım#

iPhone'da bu sorunun kaynağı genellikle boş bırakılan SMTP kullanıcı adı ve parola alanlarıdır. Ayarlar → Mail → Mail Hesapları yolundan hesabınızı açın, hesap satırına dokunun, SMTP bölümüne girin ve birincil sunucuyu seçin. iOS burada kullanıcı adı ve parola alanlarını "İsteğe bağlı" etiketiyle gösterir, bu yüzden kullanıcıların çoğu doldurmaz; ancak bu alanlar boşken gönderim yapılamaz. Kullanıcı adına tam e-posta adresinizi, parolaya da hesabın parolasını girin ve SSL seçeneğinin porta uygun olduğundan emin olun.

Sunucu saatlik gönderim limitine takıldığımı nasıl anlarım#

Sunucu tarafındaki hata metninde "exceeded your maximum hourly email limit" benzeri bir ifade geçer ve kod genellikle 550 ailesindendir. cPanel kullanıyorsanız E-posta Hesapları ekranındaki "Kısıtlamalar" bölümünde hesabın saatlik sınırını ve mevcut kullanımını görebilirsiniz. Limite takıldıysanız yapılacak tek şey bir sonraki saati beklemektir; parola değiştirmek ya da ayar oynamak sonucu değiştirmez. Bu duruma düzenli olarak giriyorsanız gönderim hacminiz paylaşımlı ortamın kapasitesinin üzerine çıkmış demektir ve ayrı bir gönderim altyapısına geçmeniz gerekir.

Gmail hesabımı SMTP olarak kullanıyorum ama parolayı kabul etmiyor#

Hesapta iki adımlı doğrulama açıksa normal hesap parolanız SMTP bağlantılarında çalışmaz. Bu durumda sağlayıcının ürettiği ayrı bir uygulama parolası oluşturmanız ve mail programına onu girmeniz gerekir. Aynı kural Microsoft hesapları için de geçerlidir. Uygulama parolaları hesaba özel ve tek amaçlıdır; birini iptal etmek diğer cihazları etkilemez, bu yüzden her cihaz için ayrı bir tane üretmek iyi bir uygulamadır. Kurumsal gönderim yapıyorsanız üçüncü taraf bir hesap yerine kendi alan adınıza ait bir posta kutusu kullanmak hem teslimat hem de yönetim açısından daha sağlıklıdır.

Kapanış#

SMTP kimlik doğrulama hatası, adı üstünde parolayı işaret ediyor gibi görünse de vakaların büyük çoğunluğunda parolayla ilgisi yoktur. Sıralamayı hatırlayın: önce kullanıcı adının tam e-posta adresi olduğunu, sonra giden sunucu kimlik doğrulama kutucuğunun açık olduğunu, ardından port ile şifreleme türünün eşleştiğini, sunucu adının sertifikayla uyuştuğunu ve son olarak sunucu tarafında bir kota veya IP bloğu bulunmadığını kontrol edin. Bu beş adım bitmeden parolayı sıfırlamak, çoğu zaman çalışan bir yapılandırmayı da bozmaktan başka işe yaramaz. Emin olmak isterseniz terminalden AUTH LOGIN testi yapın; sunucunun döndüğü kod tahmin bırakmaz.

Kurumsal posta altyapınızı sıfırdan doğru kurmak ya da mevcut kurulumu düzgün bir zemine taşımak istiyorsanız kurumsal e-posta paketleri hesap oluşturma, kayıt tanımlama ve istemci yapılandırmasını birlikte kapsar. Saatlik gönderim sınırlarına düzenli olarak takılıyor ve yüksek hacimli bildirim/duyuru gönderiyorsanız SMTP sunucu paketleri kimlik doğrulaması, DKIM imzalama ve rDNS tanımı yapılmış hâlde teslim edilir. Site ve posta trafiğini tek panelden yönetmeyi tercih eden firmalar için kurumsal hosting paketleri, teslimat izleme araçlarıyla birlikte gelir.