SMTP AUTH 535 5.7.139 Hatası: Cihazlar E-posta Gönderemiyor (2026)

Özet (TL;DR): Bir yazıcı, tarayıcı veya iş uygulaması Exchange Online üzerinden e-posta gönderirken 535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled for the Tenant ya da 535 5.7.3 Authentication unsuccessful hatası alıyorsa, sorun neredeyse her zaman kimlik doğrulama katmanındadır — parolanın kendisinde değil. En yaygın üç neden: (1) ilgili posta kutusunda veya kiracıda SMTP AUTH kapalı, (2) posta kutusunda MFA / Güvenlik Varsayılanları / Koşullu Erişim eski (legacy) kimlik doğrulamayı engelliyor, (3) cihaz yalnızca TLS 1.0/1.1 destekliyor ve reddediliyor. Doğru sıra: önce Get-CASMailbox ile SMTP AUTH durumunu doğrulayın, gerekiyorsa etkinleştirin; ardından kimlik doğrulama engellerini kontrol edin; kalıcı çözüm olarak da OAuth (modern kimlik doğrulama), High Volume Email veya Azure Communication Services'a geçin. Microsoft, SMTP AUTH için Temel Kimlik Doğrulama'yı (Basic Auth) 2026 Aralık sonu / 2027 Ocak itibarıyla mevcut kiracılarda varsayılan olarak kapatmaya başlıyor; bu yüzden geçici düzeltme yerine OAuth'a geçiş planı şart.

Belirti ve tam hata mesajları

Cihazdan veya uygulamadan gelen e-posta gönderim hataları, son kullanıcıya net görünmez — çoğu zaman yalnızca cihaz günlüğünde (log) ya da geri dönen ileti (NDR) içinde bir SMTP yanıt kodu görürsünüz. En sık karşılaşılan hata kodları ve anlamları:

Bu yazı ağırlıklı olarak en kritik ve en yaygın senaryoyu — SMTP AUTH kimlik doğrulama hatalarını (535 5.7.139 / 535 5.7.3 / 5.7.57) — çözer. İlgili spam kaynaklı gönderim engelleri (550 5.1.8) ve alıcı limitleri ayrı konulardır; bunlar için Exchange Online e-posta gönderilemiyor (5.1.8) çözümü yazımıza bakabilirsiniz.

Kök neden: sistem neden "aniden" kırıldı?

Yıllardır sorunsuz e-posta gönderen bir yazıcının veya ERP/muhasebe uygulamasının bir gün aniden gönderememesinin arkasında genellikle güvenlik politikalarındaki bir değişiklik yatar. Dört ana neden vardır:

• SMTP AUTH varsayılan olarak kapalı: Ocak 2020'den sonra oluşturulan kiracılarda kimlik doğrulamalı SMTP gönderimi (SMTP AUTH) varsayılan olarak devre dışıdır. Yeni bir posta kutusu oluşturulduğunda veya kiracı ayarı yenilendiğinde cihaz gönderemez hale gelir.
• Temel Kimlik Doğrulama (Basic Auth) kullanımdan kaldırılıyor: Microsoft, Exchange Online'daki diğer eski protokoller için Temel Kimlik Doğrulama'yı çoktan kapattı; şimdi sıra SMTP AUTH istemci gönderiminde. Kiracınızda bu değişiklik uygulandığında Basic Auth ile gönderen cihazlar durur.
• Güvenlik Varsayılanları (Security Defaults) veya MFA: Microsoft Entra ID'de Güvenlik Varsayılanları açıksa SMTP AUTH zaten Basic Auth ile çalışmaz. Posta kutusunda MFA zorunluysa, uygulama parolası olmadan bağlanan cihaz reddedilir.
• Koşullu Erişim (Conditional Access) eski kimlik doğrulama engeli: "Legacy authentication'ı engelle" politikası devredeyse, SMTP gibi eski protokoller kapsam içindeki kullanıcılar için bloklanır.

Yani hata mesajı bir "parola sorunu" gibi görünse de, gerçek neden çoğunlukla kimlik ve erişim güvenliği katmanındaki bir politikadır. Bu da kalıcı çözümün "parolayı sıfırla" değil, modern kimlik doğrulamaya geçiş olduğunu gösterir.

Hızlı tanı: sorunu 5 dakikada daraltın

Rastgele ayar değiştirmeden önce sorunu izole edin. Aşağıdaki dört kontrol, hatanın ağ mı, kimlik doğrulama mı yoksa posta kutusu mu kaynaklı olduğunu netleştirir:

1. Bağlantı testi (ağ/port): Cihazla aynı ağdaki bir bilgisayarda Telnet ile 587 portunu test edin. telnet smtp.office365.com 587 komutu 220 ... Microsoft ESMTP MAIL Service ready yanıtı vermiyorsa, güvenlik duvarı ya da ISS 587/25 portunu engelliyordur.
2. Posta kutusu canlı mı? Cihazın kullandığı kullanıcı adı/parola ile Outlook on the web'e (outlook.office.com) giriş yapıp bir test e-postası gönderin. Giriş yapılamıyorsa hesap kilitli veya kısıtlanmış olabilir.
3. SMTP AUTH durumu: Exchange Online PowerShell'de tek komutla posta kutusunun SMTP AUTH ayarını okuyun (aşağıdaki bölümde detay var). Sonuç True ise SMTP AUTH kapalıdır — sorunun büyük olasılıkla nedeni budur.
4. İleti izleme (message trace): Exchange yönetim merkezinde ileti izleme çalıştırın. Gönderim hiç ulaşmıyorsa sorun cihaz/kimlik doğrulama tarafındadır; ulaşıp reddediliyorsa taşıma kuralı veya spam filtresi devrededir.

Çözüm 1: SMTP AUTH posta kutusu ve kiracı düzeyinde etkin mi?

En sık atlanan ve en yaygın neden budur. Önce posta kutusu düzeyinde kontrol edin, gerekirse etkinleştirin. Exchange Online PowerShell'e bağlanın ve şu komutu çalıştırın:

Get-CASMailbox -Identity <EPostaAdresi> | Format-List SmtpClientAuthenticationDisabled

Dönen değer True ise SMTP AUTH bu posta kutusunda kapalıdır. Etkinleştirmek için:

Set-CASMailbox -Identity <EPostaAdresi> -SmtpClientAuthenticationDisabled $false

Değer boş (blank) dönerse, posta kutusu kiracı genelindeki ayarı devralıyordur. Kiracı düzeyindeki ayarı doğrulamak için:

Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled

Bu değer True ise SMTP AUTH tüm kuruluşta kapalıdır. Burada önemli bir güvenlik tercihi vardır: Microsoft'un önerisi SMTP AUTH'u kuruluş genelinde kapalı tutup yalnızca gerçekten ihtiyacı olan posta kutuları için tek tek açmaktır. Bu nedenle Set-TransportConfig -SmtpClientAuthenticationDisabled $false ile herkese açmak yerine, yalnızca ilgili posta kutusunda Set-CASMailbox ile açın (posta kutusu ayarı kiracı ayarını geçersiz kılar).

Yönetim merkezinden yapmak isterseniz: Microsoft 365 yönetim merkezi > Kullanıcılar > Etkin kullanıcılar > ilgili kullanıcı > Posta > E-posta uygulamalarını yönet > Kimliği doğrulanmış SMTP (Authenticated SMTP) kutusunu işaretleyin ve kaydedin.

Çözüm 2: MFA, Güvenlik Varsayılanları ve Koşullu Erişim engelleri

SMTP AUTH açık olduğu halde 535 5.7.3 hatası sürüyorsa, sorun kimlik doğrulama politikalarındadır. Sırayla kontrol edin — ama güvenlik etkisini bilerek hareket edin:

• MFA: Cihazın kullandığı posta kutusunda çok faktörlü kimlik doğrulama zorunluysa, Basic Auth ile bağlanan cihaz reddedilir. Doğru yaklaşım MFA'yı kapatmak değil, cihazı OAuth'a taşımak ya da bu hesabı ayrı bir modern-auth çözümüne geçirmektir (bkz. Çözüm 4).
• Güvenlik Varsayılanları (Security Defaults): Entra ID'de bu açıkken SMTP AUTH Basic Auth ile çalışmaz. Kapatmadan önce riski değerlendirin: Güvenlik Varsayılanları tüm kuruluşun temel korumasıdır. Onu kapatmak yerine Koşullu Erişim ile hedefli istisna yapmak daha güvenlidir.
• Koşullu Erişim eski kimlik doğrulama engeli: "Legacy authentication'ı engelle" politikanız varsa, ilgili servis hesabını Kullanıcılar ve gruplar > Dışla (Exclude) altında hariç tutun. Bu istisnayı yalnızca tek bir servis posta kutusuyla sınırlayın, tüm kullanıcıları değil.

Uyarı: Bu adımlar (MFA kapatma, Güvenlik Varsayılanlarını devre dışı bırakma, Koşullu Erişim istisnası) güvenlik yüzeyini genişletir. Geçici bir köprü olarak görülmeli, kalıcı hedef her zaman OAuth / modern kimlik doğrulama olmalıdır. Ayrıntı için Microsoft'un Güvenlik Varsayılanları belgesine bakın.

Çözüm 3: TLS sürümü ve port ayarları

Microsoft, smtp.office365.com'a TLS 1.0/1.1 ile gelen SMTP AUTH bağlantılarını reddeder. Cihazınız yalnızca eski TLS destekliyorsa, kimlik doğrulama başarılı olsa bile bağlantı kurulamaz. Doğru istemci ayarları:

Cihazınız 465 portunu varsayılan olarak öneriyorsa, çoğu zaman gerekli TLS sürümlerini desteklemiyordur — mümkünse üretici yazılımını (firmware) güncelleyin. Eski cihaz/yazılımı hemen değiştiremeyecekseniz, Microsoft geçici bir kaçış yolu sunar: Set-TransportConfig -AllowLegacyTLSClients $true ile eski TLS istemcilerine izin verip cihazı smtp-legacy.office365.com uç noktasına yönlendirebilirsiniz. Bu yalnızca geçiş dönemine yönelik bir köprüdür; kalıcı çözüm TLS 1.2+ destekleyen bir cihaz/uygulamadır.

Kalıcı çözüm: Basic Auth kapanışına hazır olun

Yukarıdaki adımlar sorunu bugün çözer; ancak SMTP AUTH için Temel Kimlik Doğrulama'nın kapanışı geldiğinde Basic Auth ile bağlanan her cihaz yine duracaktır. Bu yüzden asıl hedef, gönderim yönteminizi kalıcı bir modele taşımaktır. İhtiyaca göre dört seçenek:

• OAuth (modern kimlik doğrulama) ile SMTP AUTH: Cihaz/uygulama OAuth 2.0 destekliyorsa en doğru yol budur. SMTP AUTH protokolü OAuth'u destekler; uygulamanız için Entra ID'de kayıt ve izin yapılandırması gerekir. Ayrıntı: Microsoft'un OAuth ile IMAP, POP veya SMTP kimlik doğrulama rehberi.
• High Volume Email (HVE): Yalnızca kurum içi (dahili) alıcılara yüksek hacimli e-posta gönderiyorsanız (bildirim, uyarı, rapor) ideal. Basic Auth ve OAuth'u destekler; alıcı/mesaj hız limiti yoktur.
• Azure Communication Services (ACS) Email: Hem iç hem dış alıcılara program aracılığıyla e-posta göndermeniz gerekiyorsa, SMTP arabirimli ACS Email modern ve ölçeklenebilir seçenektir.
• SMTP relay (giriş bağlayıcısı) veya Direct Send: Cihaz oturum açamıyorsa, statik IP veya TLS sertifikası ile kimliği doğrulanan bir giriş bağlayıcısı kurup relay kullanabilirsiniz. Yalnızca kurum içi alıcılar yeterliyse Direct Send de bir seçenektir (dış alıcılara gönderemez). Her iki yöntemde de SPF, DKIM ve DMARC kayıtlarını doğru yapılandırmak, iletilerin spam'e düşmemesi için şarttır.

Karar kuralı basit: Sadece iç alıcı → HVE; iç + dış alıcı ve program erişimi → ACS Email veya OAuth ile SMTP AUTH; eski cihaz, oturum açamıyor → sertifika/IP tabanlı SMTP relay.

Zaman çizelgesi: ne zaman ne olacak?

Microsoft, SMTP AUTH için Temel Kimlik Doğrulama'nın kaldırılma takvimini birkaç kez güncelledi. Güncel (2026 başı itibarıyla açıklanan) plan:

• 2026 Aralık sonuna kadar: Mevcut kiracılarda SMTP AUTH ile Basic Auth davranışı değişmez — çalışmaya devam eder.
• 2026 Aralık sonu / 2027 Ocak: Microsoft, mevcut kiracılarda SMTP AUTH için Basic Auth'u varsayılan olarak devre dışı bırakmaya başlar. Yöneticiler gerektiğinde bu engeli geri alıp yeniden etkinleştirebilir.
• 2026 Aralık sonundan itibaren oluşturulan yeni kiracılar: SMTP AUTH ile Basic Auth kullanılamaz; yalnızca OAuth desteklenir.
• 2027'nin ikinci yarısı: Microsoft, Basic Auth'un tamamen kaldırılacağı nihai tarihi duyuracak.
• High Volume Email (HVE): Mart 2026'da genel kullanıma sunulması hedeflendi; HVE için Basic Auth'un Eylül 2028'e kadar destekleneceği belirtildi.

Kaynak: Microsoft Exchange Team Blog — Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline. Tarihler Microsoft tarafından revize edilebildiği için, üretim ortamınızı planlamadan önce Microsoft 365 Message Center duyurularınızı kontrol edin.

Önleyici kontroller ve izleme

Aynı hatanın kuruluşunuzun başka noktalarında tekrarlamaması için proaktif bir envanter çıkarın:

• SMTP AUTH'un açık olduğu tüm posta kutularını listeleyin: Get-CASMailbox -ResultSize unlimited | Where {$_.SmtpClientAuthenticationDisabled -eq $false}. Bu liste, Basic Auth kapanışından etkilenecek "riskli" hesaplarınızdır.
• Her bir SMTP AUTH kullanan cihazı/uygulamayı bir tabloya yazın: hangi cihaz, hangi posta kutusu, iç mi dış mı gönderiyor, OAuth destekliyor mu. Bu envanter geçiş planınızın temelidir.
• Entra ID oturum açma günlüklerinde "Legacy Authentication" / "Other clients" istemci uygulamalarını filtreleyerek hâlâ eski protokol kullanan bağlantıları tespit edin.
• Microsoft 365 Message Center ve Service Health duyurularını izleyin; SMTP AUTH ve Basic Auth ile ilgili takvim değişiklikleri buradan bildirilir.

Sıkça Sorulan Sorular (SSS)

"535 5.7.139 SmtpClientAuthentication is disabled for the Tenant" hatası tam olarak ne demek?

Bu hata, cihazın/uygulamanın kimlik doğrulaması başarılı olsa bile, SMTP AUTH protokolünün kiracı ya da posta kutusu düzeyinde kapalı olduğunu söyler. Çözüm, ilgili posta kutusunda Set-CASMailbox -SmtpClientAuthenticationDisabled $false ile SMTP AUTH'u etkinleştirmektir. Hata mesajındaki aka.ms/smtp_auth_disabled bağlantısı da Microsoft'un resmi açıklamasına yönlendirir.

Uygulama parolası (app password) kullanabilir miyim?

Uygulama parolaları Temel Kimlik Doğrulama'ya dayanır. SMTP AUTH için Basic Auth kapatıldığında uygulama parolaları da çalışmayı durdurur. Bu yüzden uygulama parolası kalıcı bir çözüm değildir; OAuth'a, HVE'ye veya ACS Email'e geçmelisiniz.

SMTP AUTH'u tüm kuruluşta açsam sorun biter mi?

Biter ama önerilmez. Set-TransportConfig -SmtpClientAuthenticationDisabled $false ile herkese açmak saldırı yüzeyini genişletir. Microsoft'un önerisi kuruluş genelinde kapalı tutup yalnızca gerçekten ihtiyacı olan posta kutuları için Set-CASMailbox ile tek tek açmaktır.

Yazıcım/tarayıcım OAuth desteklemiyor; ne yapmalıyım?

Üç seçeneğiniz var: (1) yalnızca iç alıcılara gönderiyorsa Direct Send veya High Volume Email; (2) iç+dış alıcı gerekiyorsa statik IP/sertifika ile SMTP relay bağlayıcısı; (3) mümkünse cihaz yazılımını OAuth destekleyen bir sürüme güncellemek. Basic Auth ile SMTP AUTH kalıcı bir yol değildir.

MFA'yı kapatmadan sorunu çözebilir miyim?

Evet — ve tercih edilen yol budur. MFA'yı kuruluş genelinde kapatmak yerine, ilgili servis hesabını OAuth'a taşıyın ya da Koşullu Erişim'de yalnızca o hesabı hedefli olarak istisna edin. Böylece diğer tüm kullanıcılarınız MFA korumasında kalır.

Basic Auth ne zaman tamamen kalkacak?

Microsoft mevcut kiracılarda SMTP AUTH Basic Auth'u 2026 Aralık sonu / 2027 Ocak'ta varsayılan olarak kapatmaya başlıyor (yöneticiler geri alabiliyor). Tam kaldırma tarihi 2027'nin ikinci yarısında açıklanacak. Bu yüzden geçişi ertelemek yerine şimdiden planlamak en güvenli yaklaşımdır.

Sonuç: geçici düzeltme değil, kalıcı geçiş

535 5.7.139 ve 535 5.7.3 hataları neredeyse her zaman bir kimlik doğrulama politikası sorunudur — parola değil. Doğru teşhis sırası: önce SMTP AUTH durumunu Get-CASMailbox ile doğrulayın, gerekiyorsa posta kutusu düzeyinde etkinleştirin; ardından MFA / Güvenlik Varsayılanları / Koşullu Erişim engellerini kontrol edin; son olarak TLS 1.2+ ve doğru port (587) ayarlarını teyit edin.

Ancak bu adımların çoğu geçici köprülerdir. Microsoft'un SMTP AUTH için Basic Auth'u kapatma takvimi göz önüne alındığında, kalıcı ve güvenli çözüm OAuth, High Volume Email veya Azure Communication Services'a geçmektir. SMTP AUTH kullanan cihaz envanterinizi bugün çıkarır ve geçiş planınızı yaparsanız, kapanış tarihi geldiğinde e-posta akışınız kesintiye uğramaz. Bu geçiş aynı zamanda Microsoft 365 ortamınızın genel kimlik güvenliğini de güçlendirir.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun SMTP AUTH ve modern kimlik doğrulama geçişinde cihaz envanteri, OAuth/HVE/Azure Communication Services yapılandırması ve Exchange Online posta akışı optimizasyonunda uçtan uca destek sağlıyoruz. İletişim sayfamızdan bize ulaşın.