Bir WooCommerce mağazasında sipariş bildirimleri SMTP sunucusundan başarıyla geçiyor ve sağlayıcı tarafından kabul ediliyor. Buna rağmen Gmail iletilerin önemli bölümünü spam klasörüne ayırıyor. Ekip, sorun gönderimden sonra ortaya çıktığı hâlde WordPress eklentilerini değiştirmeyi sürdürüyor.
İletinin gelen kutusuna düşmesi kimlik doğrulama, itibar, alıcılar, içerik ve gönderim düzenine bağlıdır. WordPress iletinin üretildiğini ve sağlayıcıya aktarıldığını gösterebilir, ancak alıcı sistemdeki klasörü belirleyemez.
Bu konu ne anlama gelir?
Bir iletinin spam klasörüne düşmesi, alıcı sistemin mesajı kabul ettiği ancak ana gelen kutusuna yerleştirmediği anlamına gelir. SPF, DKIM ve DMARC uyumu; alan adı ve IP itibarı; şikâyet ve bounce geçmişi; hacim değişiklikleri, içerik, bağlantılar, alıcı etkileşimi ve kişisel posta kutusu kuralları bu kararı etkileyebilir.
- Sağlayıcının iletiyi kabul etmesiyle gelen kutusu yerleşimini birbirinden ayırın.
- Gerçek bir işlem iletisinin gelen kutusu ve spam örneklerini Authentication-Results üstbilgisiyle birlikte karşılaştırın.
- Özel ileti içeriğini saklamadan olay, gönderen, sağlayıcı kimliği ve alıcı alan adını kaydedin.
Gerçekçi bir WordPress örneği
Mağazanın sipariş bildirimleri SMTP ve DKIM kontrollerini geçiyor, ancak görünen From alan adıyla kimliği doğrulanan Return-Path uyuşmadığı için DMARC başarısız oluyor. Eski müşteri listesi de çok sayıda kalıcı bounce üretiyor. Ekip alan adlarını uyumlu hâle getirip geçersiz adresleri çıkarıyor ve gönderim hacmini sabit tutuyor. Birkaç gün içinde yerleşim iyileşiyor; WordPress eklentisi değiştirmeye gerek kalmıyor.
Neden önemlidir ve ne zaman kullanılır?
Gönderen alan adı, sağlayıcı, paylaşımlı IP havuzu, ileti şablonu veya gönderim hacmi değiştiğinde yerleşimi yeniden inceleyin. Sağlayıcının kabul ettiği işlem iletileri normal gelen kutularında görünmüyorsa da aynı kontrol gerekir. Tek ekran görüntüsü yeterli değildir; posta hizmetleri farklı karar verir ve itibar zamanla değişir.
Yeni başlayanlar için anlaşılır yol
- WordPress’in gerçek işlem iletisini oluşturduğunu ve sağlayıcının bu iletiyi kabul ettiğini doğrulayın.
- Sağlayıcının onayladığı, sabit ve kolay tanınan bir From adresi kullanın.
- Birbiriyle çakışan birden fazla SPF politikası oluşturmadan sağlayıcının SPF kaydını yayımlayın.
- DKIM imzalamayı açın ve ulaşan bir örnekte imzayı doğrulayın.
- Mevcut kimlik doğrulama durumuna uygun DMARC politikası seçin ve raporları inceleyin.
- Geçersiz alıcıları çıkarın; kalıcı bounce, şikâyet ve engelleme listelerine uyun.
- Ani hacim artışından kaçının; yeni alan adı veya sağlayıcıyı kendi yönergelerine göre kademeli kullanıma alın.
- Göndereni, konusu, içeriği ve bağlantıları açık, tutarlı ve siteyle uyumlu tutun.
- İşlem iletileriyle pazarlama e-postalarını ayırın; gereken yerlerde onay ve abonelikten çıkış sunun.
- WordPress’in ürettiği temsilî iletileri farklı posta kutusu sağlayıcılarındaki test hesaplarında yeterli bir süre boyunca sınayın.
İleri teknik yol
Gelen kutusu ve spam örneklerinde From, Return-Path, Message-ID, Authentication-Results, Received zinciri ve imza alan adını karşılaştırın. Sağlayıcı olaylarını, şikâyet geri bildirimlerini, bounce sınıflarını, gönderen IP ile alan adı geçmişini, URL itibarını ve paylaşımlı IP havuzundan kaynaklanabilecek sorunları inceleyin.
Sonuçları olay türüne ve alıcı hizmetine göre ayırın. Parola sıfırlama ve sipariş bildirimleri farklı şablon ya da gönderen ayarı kullanabilir. Yalnızca bir tür sorunluysa bütün alan adını değiştirmek veya aynı pasif adreslere tekrar göndermek yerine o akışı düzeltin.
Riskler, sık hatalar ve geri dönüş planı
- Etkileşim satın almayın, sahte açılma üretmeyin ve kullanıcılardan toplu iletileri spamden çıkarmalarını istemeyin.
- Şikâyetlerden kaçmak için alan adını değiştirmeyin; liste veya içerik sorunu devam eder.
- Sağlayıcının engelleme listesini aşmayın ve kalıcı bounce veren adreslere göndermeyi sürdürmeyin.
- Genel test e-postası, sipariş veya parola sıfırlama iletisinin hangi klasöre düşeceğini göstermez.
- Gelen kutusu garantisi vermeyin; son kararı alıcı posta hizmeti verir.
Şikâyet veya kalıcı bounce artarsa, kimlik doğrulama eksik ya da uyumsuzsa veya alıcıların kaynağı açıklanamıyorsa ilgili gönderimi durdurun. Sorun düzeltilene kadar son kabul edilen göndereni ve şablonu kullanın; ardından izlenen işlem iletileriyle hacmi kademeli artırın.
AIOWS nasıl yardımcı olur?
AIOWS SMTP Yöneticisi
AIOWS SMTP Yöneticisi, spam yerleşimini incelemeden önce gereken WordPress tarafı bilgilerini sağlar. Modülde onaylı tek sağlayıcı yolu ve gönderen kullanın; deneme gönderimleri ve günlükler üzerinden WordPress’in gerçek bir parola sıfırlama, form veya sipariş iletisi oluşturup sağlayıcıya aktardığını doğrulayın.
İletiyi sağlayıcı kaydıyla eşleştirin ve test hesaplarına ulaşan kopyanın kimlik doğrulama üstbilgilerini inceleyin. Böylece WordPress’teki gönderim sorunu ile itibar, sağlayıcı politikası veya posta kutusu sınıflandırması birbirinden ayrılır. Eklentiler göndereni değiştirebildiği için birden fazla olay türünü sınayın.
SMTP Yöneticisi DNS kaydı yayımlayamaz, itibarı tek başına düzeltemez ve gelen kutusu yerleşimini zorlayamaz. SPF, DKIM, DMARC, sağlayıcı kuralları, liste kalitesi, paylaşımlı altyapı ve alıcı kuralları modülün dışındadır. Temsilî gönderimler kararlı hâle gelene kadar önceki onaylı gönderen yolunu koruyun ve yalnızca inceleme için gereken kimlikleri kaydedin.
AIOWS SMTP Yöneticisi özelliğini inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress E-posta Göndermiyor: Nedenleri ve Çözümleri
- WordPress E-posta Teslimatı İçin SPF Nasıl Ayarlanır?
- WordPress E-postaları İçin DKIM Nasıl Ayarlanır?
Sonuç ve önerilen yol
Önce WordPress’in iletiyi oluşturduğunu ve sağlayıcının kabul ettiğini kanıtlayın. Ardından kimlik doğrulama, liste kalitesi, gönderim düzeni ve içerikteki asıl sorunu düzeltin. Sonucu tek bir test e-postasıyla değil, farklı posta hizmetlerindeki gerçek işlem iletileriyle ve yeterli bir zaman aralığında değerlendirin.
