ERP veya muhasebe programınız Microsoft 365 üzerinden e-posta gönderirken “535 5.7.3 Authentication unsuccessful” hatası veriyorsa, sorun mutlaka yanlış parola değildir. Kullanılan gönderim yöntemi, OAuth izinleri ve Exchange tarafındaki yetkilendirme birlikte kontrol edilmelidir. Güvenlik ayarlarını topluca kapatmak yerine önce hatanın hangi aşamada oluştuğunu belirleyin.
Outlook çalışıyor, ERP neden gönderemiyor?
Outlook'ta oturum açabilmeniz, arka planda çalışan bir uygulamanın aynı yöntemle yetkilendirildiğini göstermez. Çalışan etkileşimli giriş yaparken ERP hizmeti kullanıcı olmadan çalışıyor olabilir. Ayrıca yazılım ekranında “OAuth” seçeneğinin bulunması, gerekli izinlerin doğru kaynak için alındığını kanıtlamaz.
İlk görüşmede yazılım firmasından şu bilgileri isteyin: Uygulama sürümü, kullanılan protokol, kimlik doğrulama akışı, tam hata kodu ve hatanın zamanı. Parola, uygulama sırrı veya erişim belirtecini destek kaydına eklemeyin. Bunlar teşhis için herkese gönderilmesi gereken bilgiler değildir.
SMTP OAuth, Graph ve relay arasındaki fark
| Yöntem | Hangi ihtiyaca bakılır? | Kritik kontrol |
|---|
| SMTP AUTH + OAuth | SMTP ile çalışan ve OAuth destekleyen uygulama. | Doğru OAuth akışı, izinler ve posta kutusu yetkisi. |
| Microsoft Graph | API entegrasyonu geliştirilebilen yazılım. | Graph izinleri, erişim kapsamı ve hata yönetimi. |
| SMTP relay | Koşulları karşılayan cihaz veya uygulama altyapısı. | Connector, sertifika veya IP koşulları ve ağ erişimi. |
| Direct Send | Belirli kurum içi gönderim senaryoları. | İnternetteki dış alıcılara relay yapmaz. |
Örneğin müşterilere teklif gönderen bir ERP için yalnızca kurum içi alıcılara uygun bir yöntem seçmek çözüm olmaz. Yazıcıda çalışan ayarı ERP'ye kopyalamadan önce alıcı kapsamını ve barındırma koşullarını karşılaştırın. Microsoft: cihaz ve uygulamalar için gönderim seçenekleri.
535 hatasında OAuth tarafında nerelere bakılır?
SMTP için kullanıcı etkileşimli yetkilendirme ile uygulamanın kendi kimliğiyle çalıştığı client credentials akışını ayırın. Uygulama kimliğiyle SMTP gönderiminde SMTP.SendAsApp, yönetici onayı ve Exchange tarafında service principal kaydı gibi adımlar bulunur. Graph için alınmış izin veya belirteç, SMTP için otomatik olarak doğru değildir.
Özellikle Exchange service principal kaydındaki Object ID, uygulamanın Enterprise applications bölümündeki nesne kimliği olmalıdır; App registrations nesne kimliğiyle karıştırılması kimlik doğrulama hatasına yol açabilir. SMTP client credentials akışında kullanılan kaynak kapsamı https://outlook.office365.com/.default olarak belgelenmiştir. Microsoft: SMTP OAuth ve uygulama izinleri.
Teknik ekip; tenant ve uygulama eşleşmesini, belirtecin süresini, hedef kaynağını ve gönderici kutusu yetkisini bu akışa göre incelemeli. Bir aşamanın doğru olması diğerlerinin de doğru olduğunu göstermez. MailKit gibi bir kütüphanenin hata vermesi de tek başına kütüphane hatası kanıtı değildir.
SMTP AUTH kapalıysa hemen açmak doğru mu?
SMTP AUTH, Exchange Online'da kuruluş ve posta kutusu seviyesinde denetlenebilir. Security Defaults da kullanılabilirliğini etkileyebilir. Dolayısıyla OAuth yapılandırılmış olması, protokolün o ortamda kullanılabildiği anlamına gelmez. Microsoft: SMTP AUTH ayarları.
Bu tespitin çözümü “MFA'yı kapatalım” olmamalı. Önce Graph veya uygun başka bir gönderim yöntemi değerlendirilmeli. Güvenlik modelinde değişiklik gerekiyorsa mevcut korumaların yerine ne konacağı, etkilenecek hesaplar ve geri dönüş planı belirlenmeli. Sadece e-posta göndermek için bütün şirkete geniş istisna tanımlamayın.
Gönderildi mesajı, teslim edildi anlamına gelmez
Kimlik doğrulama düzeldikten sonra ikinci kontrol başlar: Mesaj alıcıya ulaşıyor mu? Örneğin Microsoft Graph sendMail çağrısındaki 202 Accepted, isteğin kabul edildiğini söyler; teslimatın tamamlandığını garanti etmez. Microsoft Graph: sendMail yanıtı.
ERP'de gönderim kuyruğu, yeniden deneme ve hata kaydı olmalı. Aynı faturanın art arda gönderilmesini engelleyecek kayıt düzenini de yazılım firmasıyla konuşun. Bağlantı zaman aşımında “gitmedi” diye tekrar gönderilen bir mesajın ilk denemede kabul edilmiş olabileceğini hesaba katın.
Canlıya geçiş için küçük bir test planı
- Gerçek müşteri verisi içermeyen bir örnek teklif veya fatura oluşturun.
- Kurum içi ve izinli bir kurum dışı test alıcısına gönderim yapın.
- Görünen göndereni, yanıt adresini, Türkçe karakterleri ve eki kontrol edin.
- Uygulama yeniden başladıktan ve belirteç yenilendikten sonra tekrar deneyin.
- Başarısız denemenin sorumlu kişiye nasıl bildirildiğini doğrulayın.
Son madde önemlidir: Bir ay boyunca çalışan entegrasyon, kimlik bilgisi süresi dolduğunda sessizce durmamalı. Kimlik bilgisi yaşam döngüsünün sahibi, yenileme prosedürü ve alarm kanalı teslim dosyasında yer almalı.
Sık sorulan sorular
535 hatası kesin olarak yanlış şifre mi?
Hayır. OAuth izinleri, yanlış kaynak, uygulama nesnesi veya Exchange yapılandırması gibi farklı nedenler olabilir.
OAuth açınca yüksek hacimli kampanya gönderimi yapabilir miyim?
OAuth kimlik doğrulama yöntemidir; gönderim limitlerini kaldırmaz. Toplu pazarlama ile işlem e-postası ihtiyaçlarını ayrı değerlendirin.
Yazılım firması mı, Microsoft 365 yöneticisi mi ilgilenmeli?
İkisi birlikte. Yazılım tarafı akışı ve hata kaydını, yönetici tarafı izinleri ve hizmet yapılandırmasını doğrulamalıdır.
ERP e-posta entegrasyonunuzu değerlendirelim
Micro Bilgi'ye başvururken yazılım adını, gönderim yöntemini ve hassas bilgileri ayıklanmış hata kodunu paylaşın. Exchange Online hizmetleri kapsamında ihtiyacınızın lisans, yapılandırma veya yazılım entegrasyonu tarafında olup olmadığı değerlendirilebilir.
Hazırlanma ve kaynak kontrol tarihi: 25 Eylül 2026. Ürün hakları ve özellikler değişebileceğinden uygulama öncesinde güncel belgeler kontrol edilmelidir.