Çoğu kişi e-posta gitmediğinde ilk suçlu olarak kullandığı e-pin scriptini görür. Panelde sipariş yeşil, ödeme onaylı, kod stoktan düşmüş; ama müşteri on dakika sonra "kod gelmedi" diye yazıyor. Bu noktada çoğu işletme sahibi yazılımı değiştirmeyi düşünür, halbuki gerçek şu: e-posta göndermek bir yazılım özelliği değil, bir altyapı zinciridir. Zincirin bir halkası kopmuşsa, dünyanın en iyi dijital ürün satış scripti bile o maili teslim edemez.
Bu yazıda o zinciri baştan sona söküyoruz. Hangi katmanın konuştuğunu nasıl anlarsın, hangi tek satırlık test sana saatler kazandırır, hangi ayar sessizce her şeyi durdurur ve en önemlisi: teslimatı neden hiçbir zaman tek başına e-postaya emanet etmemelisin. Sonunda elinde, her mail sorununda sırayla uygulayabileceğin bir teşhis sırası olacak.
Sipariş tamamlandı ama kutuya hiçbir şey düşmedi: asıl suçlu kim?
Bir teslimat mailinin yolculuğu dört ayrı durakta ilerler: yazılımın mail üretme adımı, gönderim kütüphanesinin SMTP'ye bağlanması, sunucunun dışarı çıkış izni ve alıcı tarafın kabulü. "Hiç gitmiyor" tablosunda sorun neredeyse her zaman ilk üç durakta olur; dördüncü durak bozulduğunda mail gider ama spam klasörüne düşer, bu bambaşka bir arızadır ve karıştırılmamalıdır.
Ayrımı yapmanın en hızlı yolu, yazılımın gönderim kaydına bakmaktır. İyi kurulmuş bir e-pin satış yazılımı her denemeyi "üretildi", "kuyruğa alındı", "SMTP kabul etti", "hata" gibi durumlarla işaretler. Kayıtta hiç satır yoksa mail hiç üretilmemiştir: tetikleyici, yani ödeme onayı kancası çalışmamıştır. Satır var ama durum "hata" ise bağlantı katmanı konuşuyordur. Satır "kabul edildi" diyorsa artık iş sunucudan çıkmış, teslim edilebilirlik tarafına geçmiştir.
Teşhisi bu üç kovaya ayırmadan hiçbir ayara dokunma. Rastgele SMTP şifresi değiştirmek, sunucu yeniden başlatmak veya şablonları silmek, çalışan tarafı da bozup arızayı bulanıklaştırır. Sıra şu: kayıt oku, kovayı belirle, sadece o kovanın testini yap.
PHP'nin kendi mail fonksiyonuna hâlâ güveniyor musun?
Paylaşımlı barındırmada çalışan pek çok e-pin scripti kurulum sırasında varsayılan olarak sunucunun dahili mail fonksiyonunu kullanır. Bu yöntem hızlı kurulur, hiçbir şifre istemez ve ilk gün sorunsuz çalışır gibi görünür. Problem şu: bu fonksiyon maili bir yere teslim eder ve arkasına bakmaz. Sunucu kuyruğu maili sessizce çöpe atsa bile yazılıma "başarılı" döner. Yani panelde her şey yeşil, gerçekte hiçbir şey gitmiyor olabilir.
Çözüm, gönderimi kimlik doğrulamalı SMTP üzerinden yapmaktır. Kendi alan adının mail hesabını, kurumsal bir mail servisini veya işlemsel mail sağlayıcısını kullanabilirsin; önemli olan yazılımın sunucudan bağımsız bir kanaldan, kullanıcı adı ve şifreyle bağlanıp sağlayıcının verdiği yanıt kodunu görmesidir. Reddedildiğinde reddedildiğini bilmek, sahte başarıdan bin kat değerlidir.
Pinova'da mail çıkışı tek bir yapılandırma ekranından yönetilir; sunucu, port, şifreleme ve gönderen kimliği girildikten sonra test butonu ham SMTP diyaloğunu ekrana basar. Böylece "535 kimlik doğrulama başarısız" ile "bağlantı reddedildi" arasındaki farkı tahminle değil, sağlayıcının kendi cümlesiyle görürsün.
| Belirti | Muhtemel katman | Doğrulama yolu | Tipik çözüm |
|---|---|---|---|
| Gönderim kaydında hiç satır yok | Tetikleyici / ödeme kancası | Sipariş durumunu elle "ödendi" yapıp izle | Bildirim kancasını yeniden bağla |
| Kayıt "başarılı" ama mail yok | Sunucu dahili mail kuyruğu | SMTP'ye geçip test maili at | Kimlik doğrulamalı SMTP'ye taşı |
| 535 / 534 kodu | Kimlik doğrulama | Şifreyi webmailde dene | Uygulama şifresi üret, yeniden gir |
| Bağlantı zaman aşımı | Ağ / güvenlik duvarı | 587 ve 465 portunu ayrı ayrı sına | Sağlayıcıdan çıkış portu aç |
| Bazı siparişte gidiyor bazısında gitmiyor | Kuyruk işçisi | Cron son çalışma zamanına bak | Zamanlanmış görevi yeniden kur |
| 550 "gönderen doğrulanamadı" | Gönderen kimliği | From adresi ile SMTP hesabını karşılaştır | Aynı alan adında adres kullan |
Kuyruk sistemi sessizce durduğunda kimse alarm çalmıyor mu?
Ciddi hacimde satış yapan hiçbir dijital ürün satış yazılımı maili sipariş anında, müşteri ekrana bakarken göndermez. Gönderim kuyruğa yazılır, arka planda çalışan bir işçi kuyruğu boşaltır. Bu tasarım doğrudur: SMTP birkaç saniye yavaşladığında ödeme sayfası kilitlenmez. Ama bir bedeli var: kuyruğu boşaltan zamanlanmış görev durursa hiçbir hata ekranı çıkmaz. Sistem sessizce birikir.
Zamanlanmış görevler en çok üç durumda durur: barındırma paketi değişikliğinde cron tanımının silinmesi, PHP sürümü yükseltmesinde çalıştırılabilir yolun bozulması ve güvenlik amaçlı anahtarın değiştirilip görev satırına yansıtılmaması. Üçü de sunucu tarafında olur, senin yazılımına dokunulmaz.
Kalıcı çözüm izlemedir. Kuyrukta belirli bir süreden uzun bekleyen kayıt varsa yönetici paneline kırmızı uyarı düşmeli, tercihen sana ayrı bir kanaldan bildirim gitmeli. "Son başarılı çalışma" damgasını panelde görünür tutmak, gecikmeyi müşteriden önce fark etmenin en ucuz yoludur.
"Mail hiç gitmiyor" vakalarının kök neden dağılımı
- SMTP yapılandırma ve kimlik doğrulama 45%
- Duran kuyruk / zamanlanmış görev 25%
- Port ve güvenlik duvarı engeli 20%
- Şablon, kodlama ve tetikleyici hatası 10%
Port 587 açık mı, yoksa barındırma sağlayıcın seni sessizce susturdu mu?
Paylaşımlı barındırma sağlayıcıları istismarı önlemek için giden mail portlarını sıklıkla kapatır. En yaygın senaryo şu: 25 tamamen kapalı, 465 açık ama sadece kendi mail sunucusuna, 587 ise dışarıya kapalı. Sen üçüncü taraf bir mail servisini 587 üzerinden denerken bağlantı hiç kurulamaz ve yazılım sana yalnızca "zaman aşımı" der. Bu, script arızası değil ağ politikasıdır.
Testi hızlı yapmanın yolu portları teker teker denemektir. Bir port bağlantı kuruyor, diğeri zaman aşımına düşüyorsa tablo nettir. Bazı sağlayıcılar da sadece kendi mail sunucusu üzerinden çıkışa izin verir; o durumda ya kendi alan adının hesabını SMTP olarak tanımlarsın ya da e-posta çıkışını HTTP tabanlı bir arayüzle yapan bir sağlayıcıya geçersin. İkinci yol mail portlarını tamamen devre dışı bırakan sunucularda tek çalışan çözümdür.
Sunucu mail portlarını kapatmışsa HTTP arayüzü üzerinden gönderim yapan bir mail servisi tek pratik çıkıştır; 443 portu her yerde açıktır ve sağlayıcıdan izin beklemeden aynı gün devreye alırsın.
Tek bir e-posta bile gitmiyorsa log dosyaları neyi saklıyor?
Kayıtlara bakmayı öğrenmek, mail sorunlarını tahminden bilime çevirir. Üç yerde iz vardır: yazılımın kendi gönderim kaydı, PHP hata kaydı ve sunucunun mail kaydı. Yazılım kaydı "ne yapmaya çalıştım" der, PHP kaydı "nerede çöktüm" der, mail kaydı "karşı taraf ne cevap verdi" der. Üçünü aynı zaman aralığı için yan yana okuduğunda arıza neredeyse kendi kendini anlatır.
Sık rastlanan bir tuzak: gönderim hatası yakalanıyor ama yazılım bunu sessizce yutuyor. Ödeme akışını bozmamak için konulmuş iyi niyetli bir koruma, arızayı görünmez yapar. Doğru davranış hatayı yutmak değil, siparişi "teslimat beklemede" olarak işaretleyip yöneticiye bildirmek ve tekrar deneme sırasına almaktır. Müşteri kodunu panelden alabilirken sen arızayı sakin sakin çözersin.
Bir de karakter kodlaması meselesi var. Türkçe karakterli gönderen adı veya konu satırı yanlış kodlandığında bazı alıcı sunucular maili tümden reddeder. Belirti kafa karıştırıcıdır: bir müşteriye gider, diğerine gitmez. Gönderen adını sade tutmak ve şablonları tek kodlamada standartlaştırmak bu sınıfı tamamen kapatır.
Teslimatı e-postaya mahkûm etmek en büyük hatan olabilir mi?
En kritik ders bu: e-posta hiçbir zaman tek teslimat kanalı olmamalıdır. Mail, kontrolünün olmadığı üçüncü tarafların insafına bağlı bir kanaldır. Sağlam kurulmuş bir e-pin satış scriptinde kod her zaman müşterinin hesabındaki sipariş detayında da görünür; mail yalnızca bir bildirim, asıl teslimat noktası ise paneldir.
Bunun üstüne ikinci kanal eklenir: ödeme sonrası yönlendirilen sayfada kodun anında ekranda görünmesi, isteğe bağlı SMS veya mesajlaşma bildirimi, ve misafir alışverişlerinde tek kullanımlık erişim bağlantısı. Böyle kurulmuş bir yapıda mail servisi tamamen çöktüğünde bile satışın aksamaz, sadece bildirimler gecikir. Fark, kriz ile küçük bir aksaklık arasındaki farktır.
Pinova'nın teslimat mimarisi tam olarak bu prensiple kurulur: kod önce hesapta kalıcı olarak durur, sonra bildirim kanallarına dağılır. Ayrıntılı mimariyi özellikler bölümünde, paket farklarını ise fiyatlandırma sayfasında inceleyebilirsin.
| Kontrol adımı | Nasıl bakılır | Beklenen sonuç | Öncelik |
|---|---|---|---|
| Gönderim kaydı satırı var mı | Panel mail kayıtları ekranı | Her sipariş için en az bir satır | Yüksek |
| SMTP kimlik doğrulaması | Test maili gönder, yanıt kodunu oku | 250 kabul yanıtı | Yüksek |
| Çıkış portu erişimi | 587 ve 465'i ayrı ayrı dene | En az biri bağlanıyor | Yüksek |
| Kuyruk işçisi çalışıyor mu | Son başarılı çalışma damgası | Beş dakikadan yeni | Yüksek |
| Gönderen adresi uyumu | From adresi ile SMTP hesabı | Aynı alan adı | Orta |
| Şablon kodlaması | Türkçe karakterli test konusu | Bozulma yok | Orta |
| Panelden kod erişimi | Müşteri hesabı sipariş detayı | Kod mailsiz de görünüyor | Kritik |
| Gecikme uyarısı | Bekleyen kuyruk eşiği | Yöneticiye bildirim gidiyor | Orta |
Teslimatı şansa bırakmayı bırak
Kodun panelde garanti, bildirimin çok kanallı, mail çıkışının izlenebilir olduğu bir altyapıya geç. Mail arızası artık satış kaybı olmasın.
Mail gitmiyor derken önce neye bakmalıyım?
Yazılımın gönderim kaydına. Hiç satır yoksa tetikleyici, "hata" satırı varsa bağlantı, "kabul edildi" satırı varsa teslim edilebilirlik sorunu vardır. Bu ayrım yapılmadan yapılan her müdahale körlemedir.
Sunucunun dahili mail fonksiyonu neden güvenilmez?
Çünkü maili yerel kuyruğa bırakıp "başarılı" döner, kuyruk maili sessizce düşürse bile bunu sana bildirmez. Kimlik doğrulamalı SMTP kullandığında sağlayıcının gerçek yanıt kodunu görürsün.
Barındırma sağlayıcım mail portlarını kapattıysa ne yaparım?
HTTP arayüzü üzerinden gönderim yapan bir mail servisine geçersin. 443 portu üzerinden çalıştığı için kapatılmış 25, 465 ve 587 portlarından etkilenmez ve aynı gün devreye alınır.
Mail tamamen çöktüğünde müşteri kodunu nasıl alır?
Doğru kurulmuş bir sistemde kod müşterinin hesabındaki sipariş detayında kalıcı olarak durur ve ödeme sonrası sayfada da görünür. Mail yalnızca bildirim kanalıdır, teslimatın kendisi değildir.
Mail arızası aslında bir mimari testidir: sistemin tek bir dış servise ne kadar bağımlı olduğunu acımasızca ölçer. Bu bağımlılığı kırmış bir e-pin yazılımında mail sorunu bir sabah meselesidir, kurmamış olanda ise iade dalgasıdır. Kodun panelde garanti durduğu, bildirimlerin çok kanallı dağıldığı ve her gönderimin izlenebildiği yapıyı kendi gözünle görmek istersen canlı demo üzerinden bir test siparişi oluşturup teslimat akışını baştan sona takip edebilirsin.