WooCommerce Sipariş Maili Müşteriye Gitmiyor: Adım Adım Teşhis

Saat 14:20'de panele bakıyorsunuz: sipariş orada, tutar doğru, ödeme alınmış görünüyor. Ama sizin telefonunuza "Yeni sipariş" bildirimi düşmemiş. On dakika sonra müşteri arıyor: "Ödeme yaptım ama bana hiçbir mail gelmedi, sipariş geçti mi?" Spam klasörüne bakmasını söylüyorsunuz, orası da boş. Kendinize test siparişi veriyorsunuz — bu sefer mail geliyor. Ertesi gün aynı şikâyet tekrar ediyor.

Bu tablo tek bir arıza gibi görünse de aslında üç ayrı arızanın ortak belirtisidir: mail hiç üretilmemiş olabilir, üretilmiş ama sunucudan çıkamamış olabilir, ya da çıkıp alıcıya ulaşmış ama spam klasörüne veya doğrudan çöpe düşmüş olabilir. Bu üçü tamamen farklı yerlerde çözülür. Ayrım yapılmadan atılan her adım — hemen bir SMTP eklentisi kurmak, sunucuyu değiştirmek, alan adını beyaz listeye aldırmaya çalışmak — kör atıştır ve çoğu zaman sorunu olduğu yerde bırakır.

Bu rehberde önce bu ayrımı teslimat kayıtlarından kesin olarak yapacağız. Sonra WooCommerce'in hangi e-postayı hangi sipariş durumunda ürettiğini tabloyla göreceğiz — çünkü "mail gitmiyor" vakalarının şaşırtıcı bir kısmında mail zaten hiç üretilmemesi gereken bir siparişten beklenmektedir. Ardından WordPress'in mail katmanını, ertelenmiş gönderim kuyruğunu ve kalıcı çözüm olan kimlik doğrulamalı SMTP kurulumunu sırayla ele alacağız.

Önce Şu Ayrımı Yapın: Hiç Gönderilmedi mi, Spam'e mi Düştü?#

Teşhisin tamamı bu soruya verilen cevaba bağlıdır. Üç olası durum ve her birinin anlamı:

Üçüncü satırın en sinsi varyantı şudur: Gmail veya Outlook maili kabul eder, spam klasörüne bile koymaz, doğrudan siler. Alıcı hiçbir şey görmez, sizin logunuzda "sent" yazar. Bu yüzden "müşteri spam klasörüne baktı, orada da yok" ifadesi tek başına "gönderilmedi" anlamına gelmez.

Ayrımı yapmanın tek güvenilir yolu tahmin değil, sunucunun teslimat kaydıdır.

Teslimat Kaydından Doğrulama: cPanel, Exim ve Postfix#

cPanel kullanıyorsanız en hızlı yol Track Delivery (Teslimat İzleme) aracıdır. Müşterinin adresini yazıp aratın; her satır bir gönderim denemesini, sonucunu ve karşı sunucunun döndürdüğü mesajı gösterir. Hiç satır çıkmıyorsa mail sunucudan hiç çıkmamıştır — yani birinci satırdaki senaryodasınız ve sorun mail altyapısında değil, WordPress tarafındadır.

Kök erişiminiz varsa doğrudan loglara bakın:

# cPanel / Exim
grep -i "[email protected]" /var/log/exim_mainlog | tail -40
exigrep "[email protected]" /var/log/exim_mainlog | tail -60

# Plesk / Debian-Ubuntu üzerinde Postfix
grep -i "[email protected]" /var/log/mail.log | tail -40

# Kuyrukta bekleyen mail var mı
exim -bpc          # Exim: kuyruktaki mesaj sayısı
mailq | tail -20   # Postfix: kuyruk özeti

Çıktıyı okurken üç anahtar kelimeye bakın:

• status=sent veya Exim'de => işareti: karşı sunucu maili kabul etti. Artık sorun sizde değil, teslimat itibarındadır. Maillerin spam'e düşmesi yazısındaki adımlara geçin.
• status=bounced veya ** işareti: reddedildi. Aynı satırda karşı sunucunun sebebi yazar. Kodun anlamını SMTP hata kodları yazısında bulabilirsiniz.
• status=deferred veya == işareti: geçici hata, kuyrukta bekliyor. Genelde alıcı sunucunun greylisting uygulaması veya sizin IP'nizin bir kara listede olmasıdır.
• Hiç kayıt yok: mail hiç oluşturulmadı. Bundan sonrası WordPress tarafıdır.

Sunucu loguna erişemiyorsanız aynı bilgiyi bir e-posta günlüğü eklentisiyle de alabilirsiniz. WP Mail SMTP, FluentSMTP gibi eklentilerin günlük özelliği her wp_mail çağrısını, konusunu, alıcısını ve gönderim sonucunu kaydeder. Bu kayıt "WordPress maili üretti mi?" sorusunu tek başına cevaplar ve teşhis süresini yarıya indirir.

WooCommerce E-posta Tipleri Hangi Sipariş Durumunda Tetiklenir?#

WooCommerce tek bir "sipariş maili" göndermez; her biri belirli bir durum geçişine bağlı ayrı e-postalar vardır. Beklediğiniz mail, siparişin geçmediği bir duruma bağlıysa hiçbir zaman gelmez ve bu bir arıza değildir.

Tablodan çıkan iki kritik sonuç var. Birincisi: "Ödeme bekliyor" durumunda kalan bir sipariş için tek bir mail bile üretilmez — ne yöneticiye ne müşteriye. İkincisi: havale/EFT ile verilen bir sipariş "Beklemede" durumuna geçer, dolayısıyla müşteriye giden mail "Sipariş işleniyor" değil "Sipariş beklemede" maildir. Müşteri "sipariş onay maili gelmedi" derken çoğu zaman aradığı maili yanlış adlandırıyordur; o e-posta tipi WooCommerce ayarlarında kapalıysa gerçekten hiç gitmez.

Ayarları görmek için WooCommerce → Ayarlar → E-postalar ekranını açın. Her satırın sağındaki "Yönet" düğmesi, o e-postanın etkin olup olmadığını, alıcısını ve konu başlığını gösterir.

Sipariş "Ödeme Bekliyor"da Kalıyorsa Mail Zaten Üretilmez#

Şikâyetin en sık gerçek sebebi budur ve mail altyapısıyla hiç ilgisi yoktur. Müşteri kart bilgilerini girer, banka 3D Secure ekranına yönlendirir, ödeme onaylanır — ama ödeme sağlayıcısının sitenize gönderdiği doğrulama isteği (callback / IPN) sitenize ulaşmaz. WooCommerce ödemeyi doğrulanmış saymaz, sipariş "Ödeme bekliyor" durumunda asılı kalır, hiçbir e-posta tetiklenmez. Müşteri parasının çekildiğini görür ve haklı olarak arar.

Bu senaryoyu iki dakikada doğrulayabilirsiniz:

1. Şikâyet edilen siparişi açın, durumuna bakın. "Ödeme bekliyor" ise teşhis tamamlandı.
2. Aynı siparişi elle İşleniyor durumuna alın ve kaydedin. Mail geliyorsa mail altyapınız sağlamdır; sorun ödeme akışındadır.
3. Sipariş notlarını okuyun. Ödeme eklentisi genelde "IPN doğrulanamadı", "imza eşleşmedi" gibi bir not bırakır.

Callback isteğinin sitenize ulaşamamasının yaygın sebepleri: güvenlik duvarının ödeme sağlayıcısının IP'lerini engellemesi, ModSecurity kuralının POST isteğini 403 ile reddetmesi, sağlayıcı panelinde yanlış yazılmış bildirim URL'si ve alan adı değişikliği sonrası güncellenmemiş callback adresi. Sunucu erişim kayıtlarında sağlayıcının isteğini arayın; hiç görünmüyorsa istek hiç gelmemiş, 403/404 görünüyorsa sizin tarafınızda engellenmiş demektir.

Bir siparişin bildirimini elden yeniden göndermek isterseniz sipariş düzenleme ekranındaki Sipariş işlemleri kutusunu kullanın: "Yeni sipariş bildirimini yeniden gönder" ve "Sipariş detaylarını müşteriye e-postayla gönder" seçenekleri tam olarak bu iş içindir.

WooCommerce Ayarlarında Kontrol Edilecek Beş Şey#

Sipariş doğru duruma geçiyor ama mail yine yoksa şu beş noktayı sırayla denetleyin.

1. E-posta tipinin etkin kutusu. Bir tema kurulumu veya toplu ayar içe aktarma sırasında kapatılmış olabilir. WP-CLI ile hepsini tek seferde görebilirsiniz:

wp option get woocommerce_new_order_settings --format=json
wp option get woocommerce_customer_processing_order_settings --format=json
wp option get woocommerce_customer_on_hold_order_settings --format=json

Çıktıdaki "enabled":"no" değeri, o e-postanın hiç üretilmediğinin doğrudan kanıtıdır.

2. Alıcı adresi. Yönetici e-postalarında (yeni sipariş, iptal, başarısız) alıcı alanı serbest metindir ve birden fazla adres virgülle yazılır. Eski bir personel adresi, artık var olmayan bir kutu veya yanlış yazılmış bir karakter tüm bildirimi bounce ettirir. Ayrıca müşteri tarafında billing_email boşsa — özellikle panelden elle oluşturulan siparişlerde sık görülür — müşteri maili hiç gönderilmez.

3. "Kimden" adresi. WooCommerce → Ayarlar → E-postalar altındaki gönderen adresi kendi alan adınızda olmalıdır. Buraya [email protected] yazmak, Gmail'in DMARC politikası gereği maillerin reddedilmesine yol açar; siz Gmail adına mail göndermiş olursunuz ve Gmail buna izin vermez. Doğru kurgu, gönderen adresi [email protected] yapıp bu alan adı için SPF, DKIM ve DMARC kayıtlarını tanımlamaktır.

4. Tema şablon geçersiz kılmaları. Temanız yourtheme/woocommerce/emails/ altında kendi e-posta şablonlarını taşıyabilir. Eski bir WooCommerce sürümüne göre yazılmış bir şablon, güncelleme sonrası ölümcül hata verir ve mail üretimi tam o noktada durur — sipariş kaydedilir, mail gitmez. WooCommerce → Durum → Şablonlar listesinde "güncel değil" işaretli bir şablon varsa şüpheli odur. Test için şablonu geçici olarak yeniden adlandırıp WooCommerce'in kendi varsayılanına düşmesini sağlayın.

5. Eklenti çakışması. Mail gönderimine karışan her eklenti (SMTP eklentileri, e-posta pazarlama entegrasyonları, güvenlik eklentileri, "sipariş bildirimi özelleştirme" eklentileri) wp_mail zincirine girer. Bunlardan biri hatalıysa zincir kopar. Geçici olarak varsayılan temaya geçip diğer eklentileri kapatarak test etmek en hızlı eleme yöntemidir; ayrıntılı yöntem için WordPress eklenti çakışması yazısına bakabilirsiniz.

wp_mail Gerçekten Çalışıyor mu? Sunucu Tarafı Test#

WooCommerce mail göndermez; wp_mail fonksiyonunu çağırır, o da PHPMailer üzerinden işi devreder. Zincirin bu halkasını WooCommerce'ten bağımsız test edin:

wp eval 'var_dump( wp_mail( "[email protected]", "Wp mail testi", "Bu bir testtir." ) );'

bool(true) görüyorsanız WordPress maili PHPMailer'a başarıyla devretmiştir — bu, "mail ulaştı" demek değildir, yalnızca "gönderim denemesi hata vermedi" demektir. bool(false) görüyorsanız zincir WordPress içinde kopuyor ve sebebi yakalamanız gerekir.

Sebebi görmek için mu-plugins klasörüne küçük bir kayıt dosyası bırakın:

<?php
// wp-content/mu-plugins/mail-hata-log.php
add_action( 'wp_mail_failed', function ( $wp_error ) {
    error_log( 'wp_mail hatasi: ' . $wp_error->get_error_message() );
    error_log( 'veri: ' . wp_json_encode( $wp_error->get_error_data() ) );
} );

Bir test siparişi verip PHP hata kaydına bakın. Burada göreceğiniz mesaj — "Could not authenticate", "SMTP connect() failed", "Could not instantiate mail function" — sorunun tam adresini verir. Sonuncusu, barındırma tarafında PHP mail() fonksiyonunun kapalı olduğu anlamına gelir ki bu durumda tek çözüm SMTP'ye geçmektir.

Kimlik doğrulama hatası alıyorsanız kullanıcı adı, parola ve şifreleme kombinasyonunu SMTP kimlik doğrulama hatası yazısındaki kontrol listesiyle karşılaştırın.

Ertelenmiş Mailler ve Action Scheduler Kuyruğu#

WooCommerce, işlem e-postalarını isteğin sonunda göndermek yerine bir kuyruğa alacak şekilde yapılandırılabilir; bazı performans eklentileri ödeme sayfasını hızlandırmak için bunu açar. Ertelenmiş mailler Action Scheduler kuyruğuna düşer ve gerçekten gönderilmeleri için kuyruğun işlenmesi gerekir.

Kuyruğun durumunu WooCommerce → Durum → Zamanlanmış Eylemler ekranından görebilirsiniz. "Beklemede" sekmesinde biriken ve zamanı geçmiş yüzlerce kayıt varsa mailleriniz üretilmiş ama hiç gönderilmemiş demektir. Komut satırından:

wp action-scheduler run --batch-size=50
wp cron event list --fields=hook,next_run_relative | head -20
wp cron event run --due-now

Kuyruğun tıkanmasının bir numaralı sebebi WP-Cron'un çalışmamasıdır. wp-config.php içinde şu satır varsa:

define( 'DISABLE_WP_CRON', true );

WordPress artık ziyaretçi trafiğiyle zamanlanmış görev tetiklemez; bunun yerine sunucuda gerçek bir cron tanımlanmış olmalıdır. Yoksa kuyruk sonsuza kadar bekler:

# Her 5 dakikada bir WP-Cron tetikle
*/5 * * * * cd /home/kullanici/public_html && /usr/local/bin/php wp-cron.php >/dev/null 2>&1

Bu tablo düşük trafikli mağazalarda özellikle yanıltıcıdır: siz panele girdiğinizde cron tetiklenir ve bekleyen mailler toplu hâlde gider. Müşteri maili altı saat gecikmeli alır, siz de "gitmiş görünüyor" diye sorunu kapatırsınız.

Kalıcı Çözüm: Kimlik Doğrulamalı SMTP ve Gönderici Kimliği#

Loglarda mailin sunucudan çıktığını ama alıcıya ulaşmadığını gördüyseniz ya da PHP mail() kapalıysa, kalıcı çözüm kimlik doğrulamalı SMTP'dir. PHP mail() ile gönderilen mailde kimlik doğrulama yoktur; alıcı sunucu göndereni doğrulayamaz ve maili ya spam'e atar ya da sessizce düşürür. Bu katmanın genel mantığını siteden otomatik mailler gitmiyor yazısında bulabilirsiniz; burada WooCommerce'e özgü noktalara odaklanalım.

Bir SMTP eklentisi kurup şu değerleri girin:

Kurulumdan sonra üç doğrulama yapın: eklentinin test maili gerçekten ulaşıyor mu, gerçek bir test siparişinin maili ulaşıyor mu, ve ulaşan mailin kaynak kodunda SPF=pass ile DKIM=pass yazıyor mu. Gmail'de bir maili açıp üç noktadan "Orijinali göster" dediğinizde bu üç satırı görebilirsiniz. DKIM imzası doğrulanmıyorsa nedenini DKIM doğrulaması başarısız yazısıyla karşılaştırın.

Toplu gönderim yapan mağazalarda ek bir katman daha vardır: büyük sağlayıcılar artık gönderici kimliği ve şikâyet oranı konusunda daha katı kurallar uyguluyor. Sipariş mailleriniz işlem maili olduğu için bu eşiklerin altında kalır, ama aynı alan adından pazarlama maili de gönderiyorsanız ikisi birbirini etkiler. Kuralların özetini Gmail ve Yahoo gönderici kuralları yazısında bulabilirsiniz. Harici bir gönderim servisi kullanıyorsanız, servisin bounce/suppression listesini de kontrol edin: bir kez sert bounce alan adres kalıcı olarak bastırma listesine girer ve o adrese giden tüm mailler sessizce iptal edilir — logunuzda hata görünmez, müşteri hiçbir zaman mail almaz.

Belirti – Sebep – Çözüm Tablosu#

Sıra bu tablodaki gibi izlendiğinde vakaların büyük çoğunluğu ilk iki adımda çözülür. Atlanmaması gereken tek disiplin, her müdahaleden sonra gerçek bir test siparişi verip teslimat kaydına yeniden bakmaktır; ayarı değiştirip "herhalde düzelmiştir" demek, bu konudaki en pahalı alışkanlıktır.

Sıkça Sorulan Sorular#

Test maili ulaşıyor ama sipariş maili gitmiyor, sebebi ne olabilir?#

Test maili WordPress'in mail katmanını doğrular, WooCommerce'in tetikleyicilerini değil. İkisi ayrı halkalardır. Test maili ulaşıyorsa SMTP tarafı sağlamdır; sorun siparişin beklediğiniz duruma hiç geçmemesi, o e-posta tipinin ayarlardan kapalı olması, alıcı adresinin boş olması veya tema şablonunun hata vermesidir. Sipariş durumunu elle değiştirip mailin gelip gelmediğine bakarak bu ayrımı hemen yapabilirsiniz.

Müşteri "sipariş onay maili gelmedi" diyor ama sipariş beklemede görünüyor, normal mi?#

Havale/EFT gibi manuel ödeme yöntemlerinde sipariş "Beklemede" durumuna geçer ve WooCommerce "Sipariş işleniyor" değil "Sipariş beklemede" e-postasını gönderir. Bu e-posta tipi ayarlarda kapalıysa müşteriye gerçekten hiçbir bilgi gitmez. Ayarlar ekranından bu tipi etkinleştirin ve içeriğine havale bilgilerini ekleyin; müşteri o zaman ne beklediğini bilir.

Mailler bazen altı saat gecikmeli geliyor, bu neden oluyor?#

Büyük ihtimalle ertelenmiş gönderim ve tıkanmış bir zamanlanmış görev kuyruğu söz konusudur. WordPress varsayılan olarak zamanlanmış görevleri ziyaretçi trafiğiyle tetikler; düşük trafikli bir mağazada kuyruk saatlerce beklerken siz panele girdiğinizde topluca işlenir. Sunucuda gerçek bir cron tanımlayıp wp-config.php içinde dahili tetiklemeyi kapatmak bu davranışı düzeltir.

Gönderen adresine kendi Gmail adresimi yazsam olmaz mı?#

Olmaz. Gmail, kendi alan adı için sıkı bir DMARC politikası yayınlar; sizin sunucunuzun Gmail adına mail göndermeye yetkisi yoktur ve alıcı sunucular bu maili reddeder veya spam'e atar. Gönderen adresi mutlaka sitenizin alan adında olmalı ve o alan adı için SPF ile DKIM tanımlanmalıdır. Yanıtların kişisel kutunuza düşmesini istiyorsanız "yanıtla" adresini ayrıca ayarlayabilirsiniz.

Sunucu logunda "sent" yazıyor ama müşteri maili bulamıyor, ne yapmalıyım?#

"sent" yalnızca alıcı sunucunun mesajı kabul ettiğini gösterir; kutuya koyduğunu göstermez. Bu noktadan sonrası teslimat itibarı meselesidir. Sırasıyla şunları kontrol edin: alan adınızın SPF ve DKIM kayıtları geçerli mi, sunucu IP'niz bir kara listede mi, gönderdiğiniz içerik agresif spam filtrelerini tetikliyor mu ve harici bir gönderim servisi kullanıyorsanız alıcı adres bastırma listesine girmiş mi.

Sipariş maillerini kaydeden bir günlük tutmalı mıyım?#

Kesinlikle tavsiye edilir. Bir e-posta günlüğü eklentisi her gönderimi konu, alıcı ve sonuç bilgisiyle kaydeder; müşteri "mail gelmedi" dediğinde tahmin yürütmek yerine kaydı açıp bakarsınız. Kayıtta gönderim görünmüyorsa sorun WooCommerce tarafındadır, görünüyorsa teslimat tarafındadır. Bu tek başına teşhis süresini dakikalara indirir. Günlükleri belirli bir süre sonra otomatik temizleyecek şekilde ayarlamayı da unutmayın.