E-Pin Scriptinde E-Posta Gönderimi Çalışıyor Sanıyorsun Ama Kodların Yarısı Spam Klasöründe: SMTP Kurulumunun Kimsenin Anlatmadığı Teslim Edilebilirlik Tarafı

Çoğu işletme sahibi e-posta gönderimini ikili bir durum sanır: ya çalışıyordur ya çalışmıyordur. Panelde test maili gönderirsin, kendi adresine düşer, "tamam" der geçersin. Oysa e-posta dünyasında üçüncü ve en tehlikeli durum vardır: mail gönderilmiştir, sunucu kabul etmiştir, hiçbir hata dönmemiştir ama mesaj müşterinin gelen kutusuna hiç girmemiştir. Spam klasöründe ya da doğrudan sessiz filtrede kaybolmuştur.

Bu durum e-pin işinde diğer sektörlerden çok daha maliyetlidir, çünkü senin sattığın şey fiziksel bir kutu değil bir kod. Kod e-postayla gitmiyorsa müşteri parasını ödemiş ama ürünü almamıştır ve bu on dakika içinde bir destek talebine, bir saat içinde bir itiraza dönüşür. Bu yazıda bir e-pin scripti üzerinde SMTP kurulumunu yalnızca bağlantı ayarı olarak değil, teslim edilebilirlik mimarisi olarak ele alıyorum: port ve şifreleme seçimi, gönderen kimliği, kimlik doğrulama kayıtları, kuyruk yapısı ve izlemenin nasıl kurulacağı.

Sunucunun yerleşik mail fonksiyonu neden yetmiyor?

Paylaşımlı barındırmada çalışan yerleşik mail gönderimi, mesajı sunucunun kendi IP adresinden yollar. O IP'yi seninle birlikte yüzlerce hesap kullanır ve içlerinden birinin spam davranışı hepsinin itibarını düşürür. Üstelik bu gönderimlerde çoğu zaman DKIM imzası yoktur ve gönderen alan adı ile gerçek gönderen sunucu birbirini doğrulamaz.

Sonuç, dışarıdan bakıldığında şüpheli bir mesajdır: kimliği kanıtlanamayan bir kaynaktan, itibarı bilinmeyen bir IP üzerinden gelen, içinde kod ve bağlantı barındıran bir e-posta. Filtreler için bu tanımın tam karşılığı vardır. Bu yüzden ciddi bir e-pin satış yazılımı kurulumunda ilk hamle, yerleşik fonksiyonu kapatıp kimliği doğrulanmış bir SMTP hattına geçmektir.

Doğru hat, ister kendi mail sunucun ister bir gönderim servisi olsun, üç şeyi sağlar: sabit ve izlenebilir bir gönderim kaynağı, her mesajda geçerli bir imza ve teslimat sonuçlarını gösteren bir kayıt. Bu üçü yoksa gönderim yapıyorsun ama neyin olduğunu bilmiyorsun.

Hangi port ve şifreleme kombinasyonu doğru?

Bu konuda sahada büyük bir kafa karışıklığı var, çünkü eski belgeler hâlâ dolaşımda. Basit kural şudur: gönderim için 587 ve STARTTLS kullan. Eğer sağlayıcın açıkça istiyorsa 465 ve doğrudan TLS de geçerlidir. Port 25 sunucular arası aktarım içindir ve çoğu barındırma ortamında giden yönde kapalıdır; ona bağlanmaya çalışmak zaman aşımı hatalarının en sık sebebidir.

Şifrelemeyi kesinlikle kapatma. "Bağlantı kurulmuyor, şifrelemeyi kaldırdım çalıştı" cümlesi, SMTP kimlik bilgilerinin ağ üzerinde açık gittiği anlamına gelir ve bu bilgiler ele geçtiğinde alan adın toplu spam gönderiminde kullanılır. Bir e-pin panelinde bunun bedeli sadece itibar kaybı değil, gönderim hattının tamamen kapanmasıdır.

SPF, DKIM ve DMARC olmadan ne kadar yol gidilir?

Çok az. Bu üç kayıt, alan adının adına mail göndermeye kimin yetkili olduğunu ve mesajın yolda değiştirilip değiştirilmediğini kanıtlar. SPF, hangi sunucuların senin adına gönderebileceğini listeler. DKIM, her mesaja kriptografik bir imza ekleyerek içeriğin bütünlüğünü kanıtlar. DMARC ise bu ikisi başarısız olduğunda ne yapılacağını söyler ve sana rapor gönderilmesini sağlar.

Sıralamayı doğru yapmak gerekir. Önce SPF ve DKIM'i kur, birkaç gün gerçek gönderim yap, DMARC raporlarını izle. Her şey uyumlu görünüyorsa politikayı kademeli olarak sıkılaştır. Baştan katı politika yayınlarsan, henüz imzalanmayan bir kaynaktan çıkan işlemsel mailler reddedilir ve teslimat kodları hiç ulaşmaz.

Bir başka sık hata, birden fazla SPF kaydı yayınlamaktır. Alan adının yalnızca tek bir SPF kaydı olabilir; iki kayıt tanımladığında doğrulama tamamen geçersiz hale gelir. Tüm gönderim kaynaklarını aynı kayıt içinde birleştirmek zorundasın.

Gönderen adresi ve mesaj içeriği filtreye ne söylüyor?

Gönderen adresi tahmin edilenden çok daha belirleyicidir. Ücretsiz bir posta servisinin adresini gönderen olarak kullanmak, alan adı doğrulamasını baştan imkansız kılar; SPF ve DKIM senin alan adın için geçerliyken gönderen başka bir alan adını gösteriyorsa uyumsuzluk oluşur. Gönderen her zaman kendi alan adın altında, gerçek ve yanıt alınabilir bir adres olmalı.

İçerik tarafında e-pin işine özgü bir risk var: teslimat maili doğası gereği kod, uzun karakter dizisi ve indirme bağlantısı içerir. Bu yapı kolayca şüpheli görünür. Riski azaltmak için mesajı sadeleştir, tek bir net eylem bağlantısı bırak, kısaltma servisi kullanma, yönlendirme zinciri kurma ve mutlaka düz metin alternatifi ekle. Marka adını, sipariş numarasını ve destek yolunu net yaz; belirsiz ve genel ifadeler güven sinyali düşürür.

Ayrıca işlemsel ve pazarlama maillerini ayrı alt alan adları üzerinden gönder. Kampanya mailinin yarattığı şikayet oranı, aynı hattan çıkan teslimat mailini de aşağı çeker. Bu ayrımı yapmak, bir dijital ürün satış scripti kurulumunda en yüksek getirili yapısal kararlardan biridir.

Kuyruk ve yeniden deneme olmadan ne kaybediyorsun?

Mailleri sipariş anında, istek bitmeden senkron biçimde göndermek iki soruna yol açar. Birincisi hız: SMTP sunucusu yavaşladığında ödeme sonrası sayfa da yavaşlar ve kullanıcı işlemin başarısız olduğunu düşünüp tekrar dener. İkincisi dayanıklılık: geçici bir bağlantı hatasında mesaj tamamen kaybolur, çünkü yeniden denenecek bir kayıt yoktur.

Doğru mimari, gönderilecek her mesajı önce bir kuyruğa yazmak ve arka planda çalışan bir işleyiciye teslim etmektir. Başarısız denemeler artan aralıklarla tekrarlanır, kalıcı hatalar işaretlenir ve yönetim panelinde görünür hale gelir. Böylece hem ödeme akışı hızlı kalır hem de hiçbir teslimat maili sessizce kaybolmaz. Kritik siparişlerde e-postayı tek kanal olarak bırakmamak, kodu panel içinde de erişilebilir tutmak ek bir güvenlik katmanı sağlar.

Kurulumdan sonra neyi izlemeye devam etmelisin?

E-posta teslim edilebilirliği bir kurulum işi değil, süreklilik işidir. Bir ay sorunsuz çalışan hat, IP itibarı değiştiğinde veya bir kampanya sonrası şikayet oranı yükseldiğinde sessizce zayıflar. Bu yüzden üç metriği düzenli izlemek gerekir: geri dönen mail oranı, şikayet oranı ve kuyrukta bekleyen mesaj sayısı.

Hatalı adres biriktirmemek de önemli. Sürekli geri dönen adreslere gönderim yapmaya devam etmek, sağlayıcılar açısından liste kalitesinin düşük olduğunun göstergesidir. Bu adresleri otomatik olarak pasife alan bir mekanizma kur. Ayrıca yönetim panelinde son gönderimlerin durumunu görebildiğin bir ekran bulundur; "müşteri kodu almadı" dediğinde tahmin yürütmek yerine kaydı açıp ne olduğunu görmek istersin. Özellikler bölümünde gönderim kayıtlarının nasıl tutulduğuna mutlaka bak.

E-posta gönderimi, e-pin işinde teslimat kanalının kendisidir; bu yüzden onu bir ayar kutusu değil, işletmenin taşıyıcı altyapısı gibi kurmak gerekir. Doğru port, kimliği kanıtlanmış bir gönderen, üç DNS kaydı, ayrılmış gönderim hatları ve izlenebilir bir kuyruk; bu beş parça yerindeyse destek yükünün önemli bir bölümü kendiliğinden kaybolur. Gönderim kayıtlarının ve şablon yönetiminin gerçek bir panelde nasıl göründüğünü incelemek için canlı demo üzerinden mail ayarları ekranını aç, ardından paketleri karşılaştır.