Microsoft 365 güvenlik politikası değiştirildikten sonra bir WooCommerce mağazasının sipariş iletileri gönderilemez hâle geliyor. Posta kutusu duruyor, ancak WordPress artık oturum açamıyor. Üstelik hesabın görünen gönderen adresi adına ileti yollama yetkisi olup olmadığı da bilinmiyor.
Sağlam bir çözüm için bu sorunları birbirinden ayırmak gerekir. Önce kiracıda izin verilen gönderim yöntemi, gönderici hesabının sorumlusu ve bu hesabın seçilen adresi kullanma yetkisi belirlenir. Ardından gerçek bir WordPress olayı, oluşturulduğu andan teslim edilene kadar izlenir.
Bu konu ne anlama gelir?
Microsoft 365 üzerinden SMTP gönderiminde uygulama, iletileri Microsoft’un gönderim hizmetine teslim eder. Kurulumda Microsoft’un belgelediği sunucu adresi, TLS ve kiracının desteklediği bir kimlik doğrulama yöntemi kullanılır.
Üç koşulun birlikte sağlanması gerekir: Kiracı ilgili protokole ve oturum açma yöntemine izin vermeli, posta kutusu bunları kullanabilmeli ve oturum açan kimlik görünen gönderen adresi adına ileti yollayabilmelidir. Başarılı bir oturum açma, gönderen yetkisinin de doğru olduğunu tek başına göstermez.
Gerçekçi bir WordPress örneği
Örneğin WordPress, magaza-posta@example.comhesabıyla oturum açarken gönderen alanına siparisler@example.comyazabilir. İlk hesap ikinci adres adına gönderim yetkisine sahip değilse oturum açılsa bile Microsoft 365 iletiyi reddedebilir veya göndereni değiştirebilir.
Bu nedenle sıradan bir deneme e-postası yeterli değildir. Bir sipariş ya da parola sıfırlama iletisi oluşturun, zamanını Microsoft ileti izleme kaydıyla eşleştirin ve hem oturum açan hesabı hem de alıcının gördüğü adresi kontrol edin.
Neden önemlidir ve ne zaman kullanılır?
E-posta gönderimindeki aksaklıklar parola sıfırlama iletilerini, sipariş bildirimlerini ve yönetim uyarılarını kesintiye uğratabilir. Benzer görünen sorunların kaynağı farklıdır: WordPress ayarı, kiracı politikası, gönderen izni ve gelen kutusuna teslim ayrı ayrı incelenmelidir.
Kuruluş gönderim hesabını sürekli yönetiyorsa, kiracı gerekli kimlik doğrulama yöntemini destekliyorsa ve sitenin ileti hacmi hizmete uygunsa Microsoft 365 kullanılabilir. Bu koşullar sağlanmıyorsa genel bir güvenlik istisnası açmak yerine Microsoft’un desteklediği başka bir yöntem veya işlem e-postası hizmeti seçilmelidir.
Yeni başlayanlar için anlaşılır yol
- Değişiklikten önce mevcut WordPress e-posta ayarlarını kaydedin ve daha önce çalışan dönüş yolunu belirleyin.
- Kiracı ve posta kutusu için onaylanan gönderim ve kimlik doğrulama yöntemini Microsoft 365 yöneticisine doğrulatın.
- Kuruluşa ait özel bir hesap, belgelenen sunucu ve port, TLS ve yalnız gerekli gönderen izniyle ilerleyin.
- Gerçek bir sipariş, form veya parola sıfırlama iletisi gönderip sonucu hem WordPress’te hem Microsoft 365’te denetleyin.
- Alıcının gördüğü göndereni, teslim sonucunu ve alan adının SPF, DKIM ve DMARC uyumunu kontrol edin.
İleri teknik yol
Oturum açma başarısızsa kuruluş genelindeki SMTP AUTH politikasını, ilgili posta kutusunun ayarını, seçilen kimlik doğrulama iznini, Conditional Access kurallarını ve Security Defaults durumunu ayrı ayrı inceleyin. Ortak adreslerde Send As veya Send on Behalf yetkileri ayrıca doğrulanmalıdır.
Hatanın hangi aşamada oluştuğunu kesin SMTP yanıtı ve Microsoft ileti izleme kaydıyla belirleyin. Yalnız ilk bağlantıyı değil, belirteç ya da parolanın yenilenmesini ve yoğun gönderim sırasında uygulanan kısıtları da sınayın.
Uzun vadeli bakım için posta kutusundan kimin sorumlu olduğu, onaylı gönderen adresi, kimlik doğrulama yöntemi ve erişimi iptal etme adımları açıkça kaydedilmelidir. Böylece ileride güvenlik politikası sıkılaştırılırken WordPress için belirsiz bir istisna bırakılmaz.
Riskler, sık hatalar, yedek ve geri dönüş
Tek bir site gönderim yapamıyor diye SMTP AUTH’u bütün kiracı için açmayın. Kişisel yönetici hesapları, gereğinden geniş OAuth izinleri, doğrulanmamış ortak adresler, korumasız parolalar ve devreye girdiği belli olmayan alternatif rotalar güvenlik riskini artırır.
Gönderen yetkisi belirsizse, sertifika doğrulaması başarısızsa, önemli iletiler kayboluyorsa veya çözüm kuruluş politikasına aykırıysa geçişi durdurun. Önceki çalışan rotayı geri yükleyin ya da yeni rotayı kapatın, geçici erişimleri iptal edin ve tanı kayıtlarında gizli bilgileri maskeleyin.
AIOWS nasıl yardımcı olur?
AIOWS SMTP Yöneticisi
AIOWS SMTP Yöneticisi, WordPress tarafındaki sağlayıcı ayarlarını, gönderen bilgilerini, kontrollü testleri ve gönderim günlüklerini tek yerde toplar. Microsoft 365 için yalnız kiracı yöneticisinin onayladığı sunucu, şifreleme ve kimlik doğrulama bilgileri kullanılmalı; gizli bilgiler korumalı ayarlarda tutulmalıdır.
Deneme gönderiminden sonra, parola sıfırlama veya sipariş bildirimi gibi WordPress’in gerçekten ürettiği bir iletiyi de aynı rota üzerinden gönderin. WordPress günlüğünü Microsoft ileti izleme kaydıyla karşılaştırarak iletinin WordPress’te oluşturulması, Microsoft 365 SMTP hizmeti tarafından kabul edilmesi ve alıcının posta kutusuna ulaşması aşamalarını ayrı ayrı doğrulayın.
AIOWS; Microsoft 365 yetkisi veremez, kiracı politikasını değiştiremez, DNS kaydı yayımlayamaz veya bir iletiyi gelen kutusuna zorla yerleştiremez. Bu alanlar Microsoft 365’in, alan adı yöneticisinin ve alıcı sistemin sorumluluğundadır. Modül burada WordPress yapılandırmasını düzenli tutar ve sağlayıcı kayıtlarıyla karşılaştırılabilecek tanı bilgilerini sunar.
AIOWS SMTP Yöneticisi özelliğini inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress SMTP Ayarları: Kapsamlı Kurulum Rehberi
- Microsoft 365 SMTP AUTH Devre Dışı: WordPress Çözümleri
- SMTP 25, 465 ve 587 Portlarından Hangisi WordPress İçin Doğru?
Sonuç ve önerilen yol
Microsoft 365 SMTP’yi ancak kiracı politikası, posta kutusu erişimi ve gönderen yetkisi netleştikten sonra kullanın. En dar kapsamlı desteklenen rotayı kurun, gerçek bir WordPress iletisini Microsoft kayıtlarıyla doğrulayın ve kuruluşun genel güvenliğini zayıflatmadan çalışan bir dönüş yolu bırakın.
