# WooCommerce sipariş e-postaları ulaşmıyor

> Sipariş tamamlanıyor ama ne siz ne de müşteri e-posta alıyor: bu, WooCommerce’de en sık karşılaştığım durumlardan biridir ve neden neredeyse hiçbir zaman WooCommerce’in kendisi değildir. Eklenti mesajı çoğu durumda doğru şekilde oluşturur; sorun genellikle mesajın gelen kutusuna ulaştırılmasında yaşanır, çoğu zaman yönetim panelinde herhangi bir hata görünmeden.

- Source canonique : [https://allaux.fr/tr/wordpress-woocommerce/problemes/emails-commande-non-recus](https://allaux.fr/tr/wordpress-woocommerce/problemes/emails-commande-non-recus)
- Langue : TR
- Dernière mise à jour : 2026-09-30

## Doğrudan yanıt

> WooCommerce > Durum > Günlükler ekranını açın ve siparişin verildiği tam saate denk gelen ölümcül bir hata arayın: gönderim kancası çökerse mesaj hiç oluşturulmaz. Aksi hâlde mesaj oluşur ama teslim edilmez. WooCommerce > Ayarlar > E-postalar bölümündeki alıcıyı denetleyin, ardından PHP’nin mail() işlevi yerine kimlik doğrulamalı bir SMTP aktarıcısı kullanın.

## Nasıl ilerliyorum

1. **WooCommerce ayarlarının kontrolü** — WooCommerce > Ayarlar > E-postalar ile başlıyorum: ilgili e-posta türünün (yeni sipariş, hazırlanıyor, tamamlandı…) etkin olduğunu ve “alıcı(lar)” alanında boşluk veya yazım hatası olmadan doğru adresin yer aldığını kontrol ediyorum.
2. **WooCommerce günlüklerinin okunması** — WooCommerce > Durum > Günlükler bölümünü açıyorum. Gönderim kancası sırasında bir eklenti ölümcül bir hataya yol açıyorsa burada görünür: hiçbir e-postanın, spam’e bile gitmediği durumlarda ilk bakılacak yerdir.
3. **Ayrı bir test gönderimi** — Hiç oluşturulmamış bir mesaj (daha nadir) ile oluşturulmuş ama hiç teslim edilmemiş bir mesajı (gördüğüm mağazalarda açık ara en sık rastlanan durum) ayırt etmek için bir test e-postası gönderiyorum.
4. **İletim yönteminin kontrolü** — WordPress varsayılan olarak wp_mail() üzerinden gönderim yapar; bu da PHP’nin mail() fonksiyonuna dayanır. Birçok barındırma sağlayıcısı bunu engeller veya sınırlar; gönderen alan adı için SPF/DKIM hizalaması yoksa mesaj spam’e düşer veya kaybolur.
5. **Kimlik doğrulamalı bir SMTP aktarıcısının kurulması** — Kalıcı çözüm neredeyse her zaman, sunucunun doğrudan göndermesine izin vermek yerine phpmailer_init kancasına bağlanan bir eklenti aracılığıyla, kimlik doğrulamalı SMTP üzerinden bağlanan bir işlemsel e-posta hizmetidir.

## Düzenli olarak ele aldığım durumlar

- Sipariş yönetim panelinde açıkça mevcutken, müşteri hiçbir onay almadığını söylüyor
- Spam klasörünü kontrol etmeme rağmen artık “yeni sipariş” bildirimlerini almıyorum
- Her şey çalışıyordu, sonra bilinen bir değişiklik olmadan bir günden diğerine durdu
- Sipariş onayı çalışırken şifre sıfırlama e-postası hiç ulaşmıyor
- E-postalar sonunda ulaşıyor ama saatlerce gecikmeli

## Aynı belirtinin ardındaki iki farklı sorun

WooCommerce gönderimi kendisi yapmaz: e-posta içeriğini (yeni sipariş, fatura, iade dekontu…) oluşturur ve ardından WordPress’in yerleşik fonksiyonu olan wp_mail()’e devreder. Çoğu paylaşımlı barındırmada wp_mail(), sunucudan kimlik doğrulaması olmadan doğrudan gönderim yapan PHP’nin mail() fonksiyonuna geri döner. Hiç ulaşmayan e-postaların büyük çoğunluğunu açıklayan durum budur.

Gönderen alan adı için düzgün hizalanmış SPF ve DKIM kayıtları olmadan, büyük e-posta sağlayıcıları bu trafiği şüpheli olarak değerlendirir: mesaj spam’e düşer veya site tarafında hiçbir bildirim olmadan doğrudan reddedilir. Bu bir teslim edilebilirlik sorunudur, WooCommerce hatası değildir.

Daha nadir görülen ikinci bir durum ise mesajın hiç oluşturulmamasıdır: “sipariş alındı” sayfasını önbelleğe alan bir önbellek eklentisi, yanlış yapılandırıldığında, gönderimden sorumlu kancayı devre dışı bırakabilir. İki durum da müşteri açısından aynı görünür ama düzeltilme şekilleri tamamen farklıdır.

## Neyi ayardan, neyi geliştirmeden çözebilirsiniz

> Bir e-posta türünün etkin olduğunu ve alıcının doğru olduğunu, doğrudan WooCommerce > Ayarlar > E-postalar üzerinden bir mağaza sahibi veya bir genelci de kontrol edebilir. Bir kanca çakışmasını teşhis etmek, günlüklerdeki ölümcül bir hatayı okumak veya API anahtarlarıyla kimlik doğrulamalı bir SMTP aktarıcısını düzgün şekilde kurmak, benim yaptığım iştir.

## İlgili sayfalar

- **WooCommerce ödeme sorunu** — Engellenen sipariş veya başarısız webhook: aynı sipariş sürecini etkileyen başka bir belirti. ([/wordpress-woocommerce/probleme-paiement](/wordpress-woocommerce/probleme-paiement))
- **WooCommerce bakımı** — Bu tür bir arızanın sessizce tekrarlanmasını önlemek için düzenli izleme ve müdahale. ([/services/maintenance](/services/maintenance))
- **WordPress ve WooCommerce** — Bu platformlarda ele aldığım arızaların ve geliştirmelerin genel görünümü. ([/wordpress-woocommerce](/wordpress-woocommerce))

## FAQ

### Sorunun WooCommerce’den mi yoksa barındırma sağlayıcımdan mı kaynaklandığını nasıl anlarım?

WooCommerce üzerinden bir test e-postası göndererek ve günlükleri (Durum > Günlükler) kontrol ederek. WooCommerce tarafında hiçbir hata görünmüyorsa, sorun neredeyse her zaman e-postanın sunucu tarafından iletilmesindedir.

### Bunu çözmek için ücretli bir eklenti kurmam gerekir mi?

Mutlaka ücretli bir eklenti gerekmez, ama neredeyse her zaman SMTP üzerinden bağlanan üçüncü taraf bir işlemsel e-posta hizmeti gerekir; bunların birçoğunda ortalama bir mağazanın hacmi için yeterli ücretsiz bir plan bulunur.

### Sipariş e-postaları çalışıyor ama şifre e-postaları neden çalışmıyor?

Bunlar iki farklı WordPress kancasıdır. Bir eklenti veya özelleştirme, diğerine dokunmadan yalnızca birine müdahale edebilir; bu da görünüşte mantıksız bu farkı açıklar.

### Düzeltme sırasında sipariş geçmişimi kaybetme riskim var mı?

Hayır. Sorun yalnızca bildirim gönderimi düzeyinde yaşanır, siparişlerin kendisinde asla; siparişler bu süre boyunca veritabanında normal şekilde kayıtlı kalır.