WooCommerce Sipariş E-Postaları Gitmiyor: Adım Adım Teşhis

Sipariş e-postası gelmiyorsa sorunu üç halkadan birine yerleştirin. Birincisi WooCommerce: e-posta yalnız sipariş durumu belirli geçişlerden geçince tetiklenir, "Ödeme bekliyor" durumunda kalan bir sipariş için hiçbir e-posta oluşmaz. İkincisi gönderim yolu: WordPress e-postayı varsayılan olarak PHP mail() ile sunucuya bırakır, SMTP eklentisi varsa kimlik doğrulamalı bir posta sunucusuna verir. Üçüncüsü teslim: sunucu iletiyi gönderdi ama alıcı reddetti ya da spam klasörüne aldı. Sipariş notları, WooCommerce'in e-posta günlüğü ve panelin teslim kaydı (cPanel Track Delivery, Plesk Track Email Delivery) hangi halkada koptuğunu gösterir.

Önce halkayı bulun

"E-postalar gitmiyor" şikâyetinin arkasında birbirinden çok farklı sorunlar olabilir. Mağaza sahibine yeni sipariş bildirimi gelmiyor ama müşteri onay e-postasını alıyorsa sorun büyük olasılıkla alıcı adresinde ya da sizin posta kutunuzdadır. Hiç kimseye hiçbir şey gitmiyorsa gönderim yolu kopmuştur. Yalnız belirli ödeme yöntemlerinde sorun varsa e-posta hiç tetiklenmiyor olabilir. Aşağıdaki tablo ilk bakılacak yeri gösterir.

WooCommerce e-postayı oluşturdu mu?

E-posta ayarları

WooCommerce → Ayarlar → E-postalar ekranında her e-postanın kendi satırı vardır. İlgili e-postayı açıp Bu e-posta bilgilendirmesini etkinleştir kutusunun işaretli olduğunu kontrol edin. Yönetici bildirimlerinde (Yeni sipariş, İptal edilen sipariş, Başarısız sipariş) Alıcı(lar) alanına bakın. Bir harf hatası ya da artık kullanılmayan eski bir adres, bildirimin sessizce boşluğa gitmesine yeter. Aynı ekranın altındaki E-posta gönderici seçenekleri bölümünde "Gönderen" adı ve adresi tanımlanır. Bu adres sizin alan adınıza ait olmalı, nedenini birazdan açıklayacağız.

Sipariş durumu geçişleri

WooCommerce e-postaları zamana göre değil, sipariş durumunun bir değerden diğerine geçmesine göre gönderilir. Bu yüzden ilk soru "sipariş hangi durumda?" olmalı.

Tablodan iki pratik sonuç çıkar. Birincisi, "Ödeme bekliyor" durumunda takılı kalan bir sipariş için ne size ne müşteriye e-posta gider. Kartla ödemelerde sipariş, ödeme kuruluşunun sitenize gönderdiği bildirimle (geri çağrı, IPN, web kancası) ilerler. Bu bildirim bir güvenlik kuralına, bakım moduna ya da yanlış adrese takılırsa sipariş beklemede kalır ve e-posta sorunu gibi görünür. Siparişin notlarında ödeme eklentisinin bıraktığı satırlara ve WooCommerce → Durum → Günlükler ekranındaki eklenti günlüğüne bakın. İkincisi, havale/EFT gibi yöntemlerde sipariş önce Beklemede'ye düşer ve yönetici bildirimi o anda gider. Ödemeyi onaylayıp Hazırlanıyor'a aldığınızda müşteri yeni bir e-posta alır ama size ikinci bir "Yeni sipariş" gelmez. Bu bir hata değil, tasarım.

Sipariş notları ve e-posta günlüğü

WooCommerce 10.9'dan itibaren işlem e-postaları çekirdekte kayda geçiyor. Sipariş düzenleme ekranındaki notlarda o sipariş için denenen e-postaları ve sonucunu görürsünüz. Ayrıntılı kayıt transactional-emails kaynağıyla WooCommerce → Durum → Günlükler ekranına ya da kullandığınız günlük ayarına göre wp-content/uploads/wc-logs/ klasöründeki dosyalara yazılır. Her deneme sent, failed, disabled ya da skipped olarak işaretlenir. Başarısız gönderimlerde WordPress'in wp_mail_failed kancasından gelen hata metni de kayda girer, "SMTP connect() failed" ya da "Could not authenticate" gibi. Alıcı adresleri günlüğe yazılmaz, kullanıcı adına ya da "guest" ifadesine çevrilir. Ayrıntılar WooCommerce geliştirici blogundaki e-posta günlüğü duyurusunda.

Daha eski bir sürüm kullanıyorsanız aynı bilgiyi bir SMTP eklentisinin gönderim günlüğünden ya da ayrı bir e-posta günlüğü eklentisinden alırsınız. Bir uyarı: wp_mail() işlevinin true döndürmesi e-postanın alıcıya ulaştığı anlamına gelmez. WordPress'in kendi açıklamasına göre bu yalnız gönderim yönteminin isteği hatasız işlediğini gösterir. "Gönderildi" kaydı, teslim edildi demek değildir.

Ertelenmiş e-postalar

WooCommerce e-postayı varsayılan olarak durumu değiştiren isteğin içinde gönderir. woocommerce_defer_transactional_emails filtresiyle ya da güncel sürümlerde WooCommerce → Ayarlar → Gelişmiş → Özellikler ekranındaki Ertelenmiş e-postalar seçeneğiyle bu iş arka plana alınabilir. Kaynak koduna göre WooCommerce 10.8'den beri ertelenen her e-posta, woocommerce-emails grubunda woocommerce_send_queued_transactional_email adlı bir Action Scheduler eylemi olarak sıraya giriyor. Bu ayar açıksa ve e-postalar gecikiyorsa sorun posta tarafında değil kuyruktadır. Araçlar → Zamanlanmış eylemler ekranında bu kancayı aratın, bekleyen ya da başarısız eylem varsa Action Scheduler'da bekleyen işlemlerin neden biriktiğini çözmeden e-postalar düzelmez.

E-posta sunucuya nasıl teslim ediliyor?

WordPress e-postayı wp_mail() ile gönderir. Arkada PHPMailer çalışır ve bir eklenti aksini söylemedikçe PHP'nin mail() işlevini kullanır. Bu işlev iletiyi sunucunun yerel posta programına bırakır, oradan sonrası sunucunun posta yapılandırmasına bağlıdır. Kimlik doğrulama yoktur, hata durumunda geri bildirim çok sınırlıdır. Bazı barındırma ortamları PHP üzerinden gönderimi kısıtlar ya da tamamen kapatır.

Bir SMTP eklentisi kurduğunuzda ileti, kimliği doğrulanmış bir posta kutusu üzerinden posta sunucusuna verilir. İşin pratiğinde bunun üç faydası var: alıcı sunucular kimliği doğrulanmış gönderimi daha az şüpheyle karşılar, bağlantı hatası açık bir iletiyle günlüğe düşer ve gönderilenler posta kutusunun gönderilmiş klasöründe iz bırakabilir. Ayarlarda dikkat edilecekler şunlar:

• Sunucu adı: panelinizde ya da sağlayıcınızın belgesinde yazan adı birebir kullanın. cPanel'de bu değerler e-posta hesabının Connect Devices ekranında, istemci kurulumu için verilen bağlantı ayarlarında yer alır.
• Port ve şifreleme: 587 ile STARTTLS ya da 465 ile doğrudan TLS (SSL). Şifrelemesiz bağlantı kurmayın.
• Kimlik doğrulama açık, kullanıcı adı tam e-posta adresi.
• Gönderen adresi, kimliği doğrulanan posta kutusuyla aynı ya da o kutunun göndermeye yetkili olduğu bir adres.

Eklentinin test gönderimi "535" ya da "authentication failed" ile dönüyorsa sorun kullanıcı adı, parola, port ya da hesabın kendisindedir. SMTP 535 kimlik doğrulama hatasının kontrol adımları ayrı bir konu, burada ayrıntıya girmiyoruz. Bağlantı hiç kurulamıyorsa (zaman aşımı) giden portun sunucu ya da ağ tarafında kapalı olması olasıdır. Bazı ortamlar dışarıya 25 numaralı porttan bağlantıyı engeller, uygulama gönderimleri için 587 ya da 465 kullanın.

Gönderen adres neden önemli?

Sık yapılan hata, "Gönderen" adresine mağaza sahibinin ücretsiz posta servisindeki adresini yazmaktır. İleti sizin sunucunuzdan çıkar ama o servisin alan adı adına konuşur. Alıcı sunucu o alan adının SPF ve DMARC kayıtlarına bakar, sunucunuzu orada bulamaz ve iletiyi reddedebilir ya da spam'e atabilir. Gönderen adresi her zaman kendi alan adınızda olmalı. Yöneticiye giden yeni sipariş bildiriminde WooCommerce yanıt adresini (Reply-To) zaten müşterinin fatura e-postasına ayarlar, yani "Yanıtla" dediğinizde müşteriye yazarsınız. Bunun için gönderen adresini değiştirmeye gerek yok.

Kendi alan adınızı kullanıyorsanız sıra DNS kayıtlarına gelir. Mağazanın gönderdiği sunucu SPF kaydında yer almalı, DKIM imzası etkin olmalı. Kayıtların ne işe yaradığı ve örnek değerleri için SPF, DKIM ve DMARC kurulum rehberine bakın. Kayıt çok sayıda servis içeriyorsa SPF'teki 10 DNS sorgusu sınırını ve PermError sonucunu da kontrol edin. Sınır aşıldığında doğrulama tamamen geçersiz sayılır. Sorun hosting ya da isim sunucusu değişikliğinden hemen sonra başladıysa kayıtlar taşımada kaybolmuş olabilir. Hosting değiştikten sonra e-postaların neden çalışmadığını kontrol listesiyle gözden geçirin.

Sunucu tarafında teslim kaydı

cPanel'de Track Delivery

cPanel'de Email → Track Delivery ekranı, hesabınızdan çıkan iletilerin teslim raporunu gösterir. Recipient Email kutusuna alıcı adresini yazıp raporu çalıştırın. Her satırdaki olay simgesi durumu söyler. Success iletinin karşı sunucuya teslim edildiğini, Deferred geçici bir sorun yüzünden tekrar deneneceğini gösterir. Error teslim hatası, Rejected SMTP aşamasında reddedilip atılan ileti demektir. Filtered ise ileti kabul edildi ama gelen kutusuna konmadı anlamına gelir. Result sütunundaki metin asıl ipucudur: karşı sunucunun ret gerekçesi, bir gönderim sınırına takılma ya da DNS hatası burada yazar. Delivery Host sütunu iletinin hangi sunucuya teslim edildiğini gösterir.

Sipariş e-postası Track Delivery'de hiç görünmüyorsa iki olasılık var. SMTP eklentisiyle başka bir posta sunucusu üzerinden gönderiyorsanız kayıt o sunucudadır, oraya bakın. PHP mail() kullanıyorsanız ileti sunucunun posta programına hiç ulaşmamıştır ve sorun bir önceki halkada, WooCommerce ya da PHP tarafındadır.

Plesk'te Track Email Delivery

Plesk for Linux'ta Websites & Domains altında alan adının Mail sekmesindeki Track Email Delivery o siteden çıkan iletileri durumlarıyla listeler. Ayrıntı simgesi iletiyle ilgili tüm posta günlüğü satırlarını açar, teslim edilmemiş iletileri yeniden göndermek ya da kuyruktan kaldırmak da buradan yapılır. Özellik Postfix ya da Qmail kullanan sunucularda ve Log Browser eklentisi kuruluyken çalışır. Ekranı göremiyorsanız sağlayıcınıza sorun.

Saatlik gönderim sınırları

Paylaşımlı hostingte sağlayıcılar genellikle alan adı ya da hesap başına bir saatlik gönderim sınırı uygular. cPanel sunucularında bu sınırı sunucu yöneticisi belirler. Sınır aşıldığında iletiler bekletilebilir ya da reddedilebilir, teslim kaydında da bu yönde bir ileti görürsünüz. Kampanya bülteninizi aynı hesaptan gönderiyorsanız sipariş e-postalarınız bültenle aynı kotayı paylaşır. Toplu gönderimi ayrı bir servise taşımak hem bu sorunu hem de itibar riskini ayırır. Paketinizdeki sınırı paket ayrıntısından kontrol edin ya da sağlayıcınıza sorun.

Alıcı tarafı: gönderildi ama görünmüyor

Teslim kaydı Success diyor, müşteri "gelmedi" diyorsa ileti büyük olasılıkla spam ya da promosyon klasöründedir veya alıcı sunucu kabul edip filtrelemiştir. Müşteriden spam klasörüne bakmasını isteyin, bir kopyayı da farklı sağlayıcılardaki kendi test adreslerinize gönderin. Gelen iletinin kaynağında spf=pass, dkim=pass ve dmarc=pass satırlarını arayın. Kimlik doğrulama geçiyor ama iletiler yine spam'e düşüyorsa e-postaların spam'e düşme nedenlerini sırayla eleyin. Geri dönen iletide sunucu IP'nizin bir kara listede olduğu yazıyorsa kara listeye giren IP'nin nasıl doğrulanıp temizleneceği farklı bir iştir.

Test ve uçtan uca deneme

Ayarı değiştirdikten sonra gerçek bir sipariş beklemeyin. Güncel WooCommerce sürümlerinde e-posta ayarlarındaki önizleme bölümünden Test e-postası gönder ile şablonu kendinize yollayabilirsiniz. Bu yalnız gönderim yolunu sınar. Tetikleme zincirini sınamak için test siparişi gerekir.

1. Banka havalesi/EFT gibi çevrimdışı bir yöntemle ya da ödeme eklentisinin test kipinde bir sipariş verin. Fatura adresine farklı bir sağlayıcıdaki kendi adresinizi yazın.
2. Siparişin durumunu ve notlarını kontrol edin: hangi e-postalar denendi, sonuç ne?
3. WooCommerce → Durum → Günlükler ekranında transactional-emails kaydına ya da SMTP eklentisinin günlüğüne bakın.
4. Panelin teslim kaydında iletiyi bulun ve Delivery Host ile sonucu not edin.
5. Gelen kutusunda iletinin kaynağını açıp kimlik doğrulama sonuçlarını okuyun.

Sorunu giderdikten sonra kaçırılan bildirimleri tek tek tamamlayabilirsiniz. Sipariş düzenleme ekranındaki Sipariş eylemleri listesinde "Yeni sipariş bildirimini tekrar gönder" ve "Sipariş ayrıntılarını müşteriye gönder" seçenekleri bulunur.

E-postaların yeniden aktığını doğrulamak

Test siparişinin notlarında e-postalar gönderildi olarak görünmeli, günlükte failed satırı olmamalı. Teslim kaydında ileti Success durumunda, karşı tarafın posta sunucusu Delivery Host sütununda yazmalı. Farklı sağlayıcılardaki test adreslerinde ileti gelen kutusuna düşmeli ve üç kimlik doğrulama sonucu pass olmalı. Ertesi gün gerçek siparişlerin notlarına ve günlükteki failed sayısına bir kez daha bakın. Sorun yalnız yoğun saatte tekrarlıyorsa gönderim sınırından şüphelenin.

Ne zaman destek ekibine yazmalı?

Teslim kaydında sunucu düzeyinde bir ret görüyorsanız, gönderim sınırına takıldığınızı düşünüyorsanız, giden port kapalı görünüyorsa ya da Plesk'te teslim takibi ekranına erişemiyorsanız iş sağlayıcı tarafındadır. Netx müşteri panelinden açacağınız destek talebine sipariş numarasını, gönderimin tarih ve saatini (saat dilimiyle), alıcının alan adını, günlükteki hata satırını ve PHP mail() mi SMTP mi kullandığınızı ekleyin. Teslim kaydındaki Result metnini kopyalamak teşhisi en çok hızlandıran bilgidir.

Mağazanın kendisi Netx'teyse WordPress hosting paketleri cPanel sunucularında çalışır. Track Delivery ekranını cPanel'in Email bölümünde arayın, göremiyorsanız destek ekibimize sorun. Sipariş e-postalarını web sitesinden ayrı, alan adınıza bağlı bir posta kutusu üzerinden SMTP ile göndermek isterseniz kurumsal hosting paketleri Plesk panelli e-posta sunar. Hesap sayısı limitsizdir, toplam disk pakete bağlıdır. Mağaza tarafındaki diğer gereksinimleri WooCommerce için hosting gereksinimleri yazısının e-posta teslimatı bölümünde bulabilirsiniz.