SMTP 535 Authentication Failed Hatası Nasıl Çözülür?

535 5.7.8 yanıtı, sunucunun SMTP oturumunda gönderdiğiniz kimlik bilgilerini reddettiği anlamına gelir. RFC 4954 bu kodu "geçersiz kimlik bilgisi" olarak tanımlar ve hatanın kullanıcı adında mı parolada mı olduğunu bilerek söylemez. Çoğu vakada neden şunlardan biridir: kullanıcı adına tam e-posta adresi yazılmamıştır, parola değişmiş ama cihazda ya da yapılandırma dosyasında eskisi kalmıştır, istemci başka bir sunucuya bağlanıyordur ya da hesap kaba kuvvet korumasına takılmıştır. Microsoft 365'te SMTP AUTH'un kapalı olması, Google Workspace'te uygulama şifresi gerekmesi de aynı kodu üretir. İlk adım, aynı bilgilerle web postasına girebildiğinizi denemektir.

535 ne söyler, ne söylemez?

Hata mesajları birbirine çok benzer ve yanlış kod yanlış yere baktırır. RFC 4954'ün durum kodları bölümü SMTP kimlik doğrulamasıyla ilgili yanıtları ayrı ayrı tanımlar. Elinizdeki kodu önce bu tabloyla eşleştirin:

Tablodaki son satır önemli. 454 geçici bir sunucu sorunudur ve RFC, istemcinin bu durumda kullanıcıdan yeni parola istememesini söyler. 535'te ise sunucu bilgileri gerçekten kabul etmemiştir. Ama bu, parolanın kesinlikle yanlış olduğunu da göstermez. Pek çok sunucu kilitlenmiş ya da girişi kapatılmış bir hesabı saldırgana ipucu vermemek için aynı genel mesajla reddeder. cPanel belgeleri cPHulk'un engellediği kullanıcıya yalnızca genel bir giriş hatası gösterildiğini açıkça yazar.

Sunucunun eklediği metin de ipucu taşır. Exim çoğu kurulumda 535 Incorrect authentication data, Postfix 535 5.7.8 Error: authentication failed yazar. Bu metinler yazılıma göre değişir. Kodun kendisi esas alınmalı.

Önce istemciden bağımsız bir deneme yapın

Sorunun nerede olduğunu en hızlı ayıran test şu: aynı e-posta adresi ve parolayla tarayıcıdan web postasına girmeyi deneyin. Giriş başarılıysa parola doğrudur ve sorun istemcinin, sitenin ya da uygulamanın ayarındadır. Giriş başarısızsa sorun hesaptadır: parola yanlıştır, değiştirilmiştir ya da hesap kilitlenmiştir.

Bu ayrımı yapmadan istemci ayarlarıyla oynamak saatler kaybettirir. Üstelik her başarısız deneme kaba kuvvet korumasının sayacını artırır. Yanlış parolayla otomatik olarak tekrar tekrar bağlanan bir telefon, siz ayarlarla uğraşırken hesabı kilitleyebilir.

Kullanıcı adı ve parola tarafı

Paylaşımlı hostingde kullanıcı adı neredeyse her zaman tam e-posta adresidir: ad@ornek.com.tr, yalnızca ad değil. Outlook ve telefon kurulumundaki bu ve benzeri ayrıntıları cPanel'de e-posta hesabı oluşturma ve istemci kurulumu yazısında adım adım anlattık.

Parola tarafında en sık rastladığımız tablo şu: parola panelden değiştirilmiş, bilgisayardaki Outlook yeni parolayı almış, ama telefon, tablet, ofisteki tarayıcı ve sitenin iletişim formu hâlâ eskisini kullanıyor. Her biri arka planda bağlanmayı denediği için hem 535 alırlar hem de hesabın kilitlenmesine katkıda bulunurlar. Parola değişikliğinden sonra hesabı kullanan her yeri bir listeye yazıp tek tek güncelleyin.

Yapılandırma dosyasındaki özel karakterler

Parola doğru, web postası açılıyor, ama site 535 alıyor mu? Parolayı bir yapılandırma dosyasına yazdıysanız özel karakterlere bakın. Birkaç tipik tuzak var:

• PHP'de tek tırnaklı dizgide yalnızca \' ve \\ özel anlam taşır. Parolada tek tırnak ya da sondaki ters eğik çizgi varsa kaçırılmalıdır. Çift tırnak kullanılırsa $ ile başlayan kısım değişken sanılır.
• .env dosyalarında boşluk, # ya da $ içeren değerler tırnak içine alınmazsa kesilebilir ya da başka bir değerle değiştirilebilir. Davranış kullanılan kütüphaneye göre değişir.
• smtp://kullanici:parola@sunucu:587 biçimindeki bağlantı dizelerinde kullanıcı adındaki @ ve paroladaki :, /, @, # gibi karakterler URL kodlamasıyla yazılmalıdır, örneğin @ yerine %40.
• Kopyala-yapıştır sırasında başa ya da sona eklenen görünmez boşluk.

Hızlı bir teşhis yolu, hesap parolasını geçici olarak yalnızca harf ve rakamdan oluşan uzun bir parolayla değiştirip denemektir. Hata kaybolursa sorun kaçış kurallarındadır. Sonra güçlü bir parolaya dönüp doğru kaçışı yazın.

Sunucu adı, port ve şifreleme

Giden sunucu adını ve portu tahmin etmeyin. Netx hizmetlerinde bu değerleri panelinizdeki bağlantı ayarlarından alın, emin değilseniz destek ekibimize sorun. Genel kural şöyle: 587 numaralı gönderim portunda bağlantı düz başlar ve STARTTLS komutuyla şifrelenir, 465 numaralı portta ise TLS bağlantının ilk anından başlar (örtük TLS). İstemcideki şifreleme seçeneği porta uymazsa karşınıza genellikle zaman aşımı ya da TLS el sıkışma hatası çıkar.

Bazı istemciler şifreleme kurulamayınca kimlik doğrulamayı düz bağlantıda dener. Pek çok sunucu şifresiz bağlantıda AUTH'u hiç sunmaz. Sonuç "sunucu kimlik doğrulamayı desteklemiyor" gibi bir mesaj ya da 530 olur. Şifreleme ayarını düzeltmek ikisini birden çözer.

Sunucu adı yanlışsa iş daha sinsi bir hâl alır. Diyelim ki siteyi yeni bir hosting firmasına taşıdınız, e-posta eski yerinde kaldı ve mail.ornek.com.tr adı artık yeni web sunucusunu gösteriyor. İstemciniz hâlâ bu adı kullanıyorsa kimlik bilgilerinizi kutunuzun hiç bulunmadığı bir sunucuya gönderir ve 535 alır. Bu senaryoda hosting değişikliğinden sonra bozulan diğer e-posta ayarlarını da gözden geçirin. Sertifika uyarısı da sıklıkla aynı nedenden gelir: istemcideki ad, sunucunun sertifikasındaki adla eşleşmiyordur.

Kimlik doğrulama yöntemi

Outlook'ta "Güvenli Parola Kimlik Doğrulaması (SPA) gerektir" kutusu işaretliyse istemci Windows'a özgü bir yöntem dener. Linux tabanlı posta sunucularının çoğu bunu desteklemez. Kutuyu kaldırın ve normal parola doğrulamasını seçin, bağlantı zaten TLS ile şifrelendiği için parola açıkta gitmez. Bazı uygulamalarda yöntem listesi açıkça sunulur: CRAM-MD5 ya da NTLM yerine PLAIN veya LOGIN seçin. Sunucunun hangi yöntemleri kabul ettiğini aşağıdaki testte EHLO yanıtındaki AUTH satırında görebilirsiniz.

Parola doğruysa: kilit ve kısıtlamalar

Web postasına girebiliyorsunuz, ayarlar doğru, ama SMTP hâlâ 535 diyorsa hesabın ya da IP'nin bir korumaya takıldığını düşünün. Burada iki farklı mekanizma var ve belirtileri farklı.

Kullanıcı adına göre kilitleme yapan korumalar, cPanel sunucularındaki cPHulk gibi, belirli sayıda hatalı denemeden sonra hesabı her IP'den gelen girişe bir süre kapatır. Belirti 535'tir, doğru parolayla bile. Belgeye göre kilit süresi dolunca kendiliğinden kalkar. Sunucu yöneticisi kaydı geçmiş raporlarından görebilir.

IP'ye göre engelleyen korumalar, Plesk'teki Fail2Ban hapishaneleri (jail) ya da sunucu güvenlik duvarı gibi, çoğu zaman bağlantıyı tümden keser. Bu durumda istemci bağlantı zaman aşımı verir ve aynı ağdaki herkes etkilenir. Ayırt etmenin pratik yolu: telefonunuzu mobil veriye alıp aynı hesapla deneyin. Orada çalışıyor, ofis ağında çalışmıyorsa engel IP'dedir.

Panel tarafında hesap bazlı kısıtlamalar da var. cPanel'de Email Accounts → Manage ekranındaki kısıtlamalar bölümünde giriş (Logging In) askıya alınabilir, giden posta (Sending Outgoing Mail) ise reddedilebilir ya da kuyrukta bekletilebilir (Hold). Girişi kapalı hesap 535 alır. Giden postası askıdaki hesap ise genellikle kimliği doğrular ama gönderim aşamasında reddedilir. Hesaptan spam çıktığı için sağlayıcınız gönderimi durdurduysa önce spam'in kaynağını bulup durdurmak gerekir.

Microsoft 365 ve Google Workspace'te durum farklı

Kendi alan adınızın postası Microsoft ya da Google'da duruyorsa 535'in nedeni sıklıkla platformun kimlik doğrulama politikasıdır.

Microsoft 365: SMTP AUTH ve temel kimlik doğrulama takvimi

Exchange Online'da SMTP AUTH hem kiracı (tenant) düzeyinde hem posta kutusu düzeyinde kapatılabilir ve posta kutusu ayarı kiracı ayarını ezer. Microsoft Learn'deki SMTP AUTH belgesine göre güvenlik varsayılanları (security defaults) açıksa SMTP AUTH zaten kapalıdır, temel kimlik doğrulamayı engelleyen bir kimlik doğrulama ilkesi de etkisini sürdürür. Bu durumda dönen yanıt çoğu zaman 535 5.7.139 ile başlar ve metinde SmtpClientAuthentication ifadesi geçer. Yönetici bir posta kutusunun durumunu Exchange Online PowerShell'de şöyle görür ve açar:

Get-CASMailbox -Identity ad@ornek.com.tr |
  Format-List SmtpClientAuthenticationDisabled
Set-CASMailbox -Identity ad@ornek.com.tr `
  -SmtpClientAuthenticationDisabled $false

Çıktıda True kapalı, False açık, boş değer ise kiracı ayarının geçerli olduğu anlamına gelir. İkinci komuttaki satır sonu ters tırnağı (`) PowerShell'in satır devam işaretidir, isterseniz komutu tek satırda da yazabilirsiniz.

Takvime gelince: Microsoft, SMTP AUTH'ta temel kimlik doğrulamanın (kullanıcı adı ve parola) kaldırılmasını önce Mart–Nisan 2026 için planlamıştı. Exchange ekibinin 27 Ocak 2026 tarihli güncel duyurusuna göre plan şöyle: Aralık 2026 sonuna kadar davranış değişmiyor. Aralık 2026 sonunda mevcut kiracılarda temel kimlik doğrulama varsayılan olarak kapatılacak, yöneticiler gerekirse yeniden açabilecek. Aralık 2026'dan sonra açılan yeni kiracılarda ise varsayılan olarak hiç bulunmayacak ve desteklenen yöntem OAuth olacak. Kesin kaldırma tarihi 2027'nin ikinci yarısında açıklanacak. Parola ile SMTP gönderen bir yazıcınız, eski bir uygulamanız ya da site eklentiniz varsa onu Aralık 2026 sonundan önce OAuth desteğine geçirmeyi planlayın.

Google Workspace: uygulama şifresi ya da OAuth

Google, Workspace hesaplarında yalnızca kullanıcı adı ve parolayla oturum açan "daha az güvenli uygulamalar" erişimini 14 Mart 2025'te tüm hesaplar için kapattı. IMAP, POP ve SMTP'de parola ile oturum açma artık yalnızca uygulama şifreleriyle mümkün. Google'ın uygulama şifresi yardım sayfasına göre uygulama şifresi ancak iki adımlı doğrulama açık hesaplarda kullanılabilir, yönetici kısıtlamasına bağlı olarak iş hesaplarında seçenek hiç görünmeyebilir ve hesap parolası değiştiğinde tüm uygulama şifreleri iptal edilir. Bu son madde sık atlanır: parolayı değiştirdiğiniz gün yazıcının ve sitenin gönderimi durur. Uygulamanız destekliyorsa OAuth ile bağlamak bizce daha kalıcı çözüm.

WordPress ve uygulamalarda SMTP

WordPress varsayılan olarak postayı sunucunun yerel posta işleviyle gönderir. WP Mail SMTP, FluentSMTP gibi eklentiler bunu kimliği doğrulanmış SMTP'ye çevirir. 535 aldığınızda eklentinin test ekranındaki ayrıntılı günlüğü açın, sunucunun tam yanıtı oradadır. Birkaç noktaya özellikle bakın: kullanıcı adı alanında tam adres var mı, şifreleme seçimi portla uyumlu mu, eklenti Microsoft 365 ya da Google için OAuth bağlantısı sunuyorsa parola yerine onu mu kullanıyorsunuz?

Parolayı veritabanında tutmak yerine wp-config.php içinde sabit olarak tanımlamaya izin veren eklentiler var. Bunu kullanıyorsanız yukarıdaki PHP kaçış kurallarına dikkat edin. Bir de şu ayrımı aklınızda tutun: gönderen adresi kimliği doğrulanan hesaptan farklıysa bazı sunucular postayı reddeder, ama bu reddin kodu 535 değildir. Genellikle gönderim aşamasında 5.7.1 ya da benzeri bir kodla gelir. Gönderim yalnızca mağaza bildirimlerinde bozuluyorsa WooCommerce sipariş e-postalarının teşhisi SMTP ayarından önce sipariş durumuna ve e-posta tetikleyicisine bakmayı gerektirir.

swaks ve openssl ile elle test

İstemciyi aradan çıkarıp sunucuyla doğrudan konuşmak, tartışmayı bitirir. Bu testleri mümkünse bir test hesabıyla yapın. Gerçek hesap kullanacaksanız parolayı komut satırına yazmayın, çünkü kabuk geçmişine ve ekran kayıtlarına düşer.

swaks parolayı vermezseniz sizden ister. --auth-hide-password parolayı ekran çıktısından siler, -q AUTH da kimlik doğrulamadan sonra posta göndermeden bağlantıyı kapatır:

swaks --server mail.ornek.com.tr --port 587 --tls \
  --auth LOGIN --auth-user ad@ornek.com.tr \
  --auth-hide-password -q AUTH

465 portunda --tls yerine --tls-on-connect kullanın. Çıktıda EHLO yanıtındaki 250-AUTH satırı sunucunun kabul ettiği yöntemleri listeler. Başarılı denemenin sonunda 235, başarısızında 535 görürsünüz.

swaks kurulu değilse openssl ile aynı testi yapabilirsiniz. Önce AUTH PLAIN için gereken tek satırlık değeri, parolayı ekrana yazdırmadan üretin:

read -r -s -p 'Parola: ' P; echo
printf '\0%s\0%s' 'ad@ornek.com.tr' "$P" | base64 -w0; echo
unset P

Sonra bağlanın ve sırasıyla EHLO test.ornek.com.tr ile AUTH PLAIN <üretilen değer> satırlarını yazın:

openssl s_client -starttls smtp \
  -connect mail.ornek.com.tr:587 -crlf -quiet

-quiet burada önemli. Onsuz openssl etkileşimli komut kipinde çalışır ve satır başındaki bazı harfleri, örneğin R ile başlayan RCPT komutunu, kendi komutu sanabilir. Üretilen base64 değeri şifreleme değildir, parolayı herkes geri çözebilir. Testten sonra terminali temizleyin ve değeri hiçbir yere yapıştırmayın.

Sunucu yöneticisi için günlükler

Kendi VPS ya da VDS'inizi yönetiyorsanız tahmin yerine günlüğe bakın. cPanel sunucularında Exim günlüğünde başarısız doğrulama şöyle aranır:

grep 'authenticator failed' /var/log/exim_mainlog | tail -20

Satırda bağlanan IP'yi ve set_id= ile denenen kullanıcı adını görürsünüz. Kullanıcı adı yanlış yazılmışsa burada belli olur. Plesk gibi Postfix kullanan sunucularda aynı bilgi posta günlüğündeki SASL satırlarındadır. Red Hat ailesinde dosya /var/log/maillog, Debian ve Ubuntu'da /var/log/mail.log olur:

grep 'SASL' /var/log/maillog | tail -20

Aynı IP'den farklı kullanıcı adlarıyla yüzlerce satır görüyorsanız karşınızdaki bir istemci hatası olamaz, bu bir parola deneme saldırısıdır. Saldırının hedefindeki hesaplar için kurumsal e-posta güvenliğindeki hesap önlemlerini gözden geçirin. Tek bir kullanıcı adının birkaç IP'den sürekli hata alması ise çoğu zaman eski parolayla kalmış cihazlara işaret eder. Kilitleri cPanel'de WHM'deki cPHulk geçmiş raporlarından, Plesk'te Tools & Settings → IP Address Banning (Fail2Ban) ekranındaki yasaklı IP listesinden kontrol edin. Paylaşımlı hostingde bu günlüklere erişiminiz yoktur, o durumda destek ekibine sorun.

Düzeldi mi? Kontrol ve destek talebi

İstemciden kendinize değil, dışarıdaki bir adrese test postası gönderin. Gönderim başarılıysa bir de hesabı kullanan diğer cihazları ve uygulamaları sırayla kontrol edin. Eski parolayla kalmış tek bir telefon, birkaç saat sonra hesabı yeniden kilitleyebilir. Sunucu yöneticisiyseniz günlükte o kullanıcı adı için yeni hata satırı düşmediğini de doğrulayın.

Sorun sürüyorsa destek talebinize hatanın tam metnini, hatanın görüldüğü zamanı (saat dilimiyle), kullanılan istemci ya da uygulamayı, e-posta adresini ve bağlandığınız ağın genel IP adresini ekleyin. Parolayı talebe asla yazmayın. E-postanız Netx'in Plesk panelli kurumsal hosting paketlerinden birindeyse talebi Netx müşteri panelinden açabilirsiniz.

Sık sorulan sorular

Bilgisayardan gönderebiliyorum, telefondan 535 alıyorum. Neden?

İki cihaz büyük olasılıkla farklı ayar kullanıyor. Telefonlardaki otomatik kurulum sihirbazları sunucu adını tahmin eder ve yanlış tahmin edebilir. Bir de telefonda eski parola kalmış olabilir. Hesabı telefondan silip panelde yazan değerlerle elle yeniden kurmak çoğunlukla en kısa yoldur.

535 aldıktan sonra hemen tekrar denemek sorun olur mu?

Olabilir. Kaba kuvvet korumaları hatalı denemeleri sayar ve birkaç başarısız denemeden sonra hesabı ya da IP'nizi bir süre engeller. Ayarı düzeltmeden art arda deneme yapmayın. Uygulamaların otomatik yeniden deneme özelliğini de sorun çözülene kadar kapatın.

Parola sıfırladım, hâlâ aynı hata. Ne kaçırıyorum?

Üç olasılık var. Hesap hâlâ kilitli olabilir ve kilit süresinin dolmasını beklemek gerekir. İstemci yeni parolayı değil, işletim sisteminin anahtar zincirinde saklı eski parolayı kullanıyor olabilir. Ya da hesap Google'da ise parola değişikliği bütün uygulama şifrelerini iptal etmiştir ve yeni bir uygulama şifresi üretmeniz gerekir.