E-Pin Scripti Kurdun Ama Sipariş Mailleri Ulaşmıyor: SPF, DKIM ve DMARC'ın Perde Arkası ve Sağlayıcıların Sana Hiç Anlatmadığı Teslim Edilebilirlik Dosyası

Çoğu satıcı, müşterisi "kodum gelmedi" yazdığında ilk olarak paneli suçlar. Siparişi açar, bakar: durum "tamamlandı", kod atanmış, stok düşmüş, log temiz. Yazılım işini yapmıştır. Ama mail, müşterinin gelen kutusunda yoktur. Buradan sonra genelde yanlış bir yola girilir: farklı bir e-pin scripti aranır, sunucu değiştirilir, tema kurcalanır. Oysa sorun kodda değil, alan adının kimlik doğrulama zincirindedir.

Gerçek şu: e-posta dünyasında bir mailin gönderilmesi ile kabul edilmesi iki ayrı olaydır. Senin dijital ürün satış yazılımın mesajı SMTP sunucusuna teslim eder ve görevini bitirir. Gmail, Outlook ya da Yandex ise o mesajı almadan önce üç soru sorar: "Bu IP bu alan adı adına gönderim yapmaya yetkili mi?", "İçerik yolda değiştirilmiş mi?" ve "Alan adı sahibi, bu iki testten biri başarısız olursa ne yapmamı istiyor?" Bu üç sorunun cevabı sırasıyla SPF, DKIM ve DMARC'tır. Üçünü de yanıtlamadığın her gün, satışını yaptığın kodun müşteriye ulaşma şansını kumara bırakıyorsun.

Mailin Gitmiyor mu, Gidiyor Ama Kimse Görmüyor mu?

Bu ayrım her şeyin başlangıcı. Eğer mail hiç çıkmıyorsa sunucu loglarında bir hata satırı vardır ve bu teknik bir arızadır. Ama e-pin satış scriptinin kuyruğunda "gönderildi" yazıyorsa mesaj çıkmıştır; alıcı tarafında sessizce çöpe atılmış ya da spam klasörüne düşmüştür. İkinci senaryo daha tehlikelidir çünkü sana hiçbir uyarı gelmez. Satış olur, para hesabına geçer, müşteri kodu göremez ve bir saat sonra ödeme sağlayıcısına itiraz açar.

Teşhisi kendin yapabilirsin. Kendine ait bir Gmail adresine test siparişi geç, mail ulaştığında mesajı aç, "orijinali göster" seçeneğiyle başlıkları oku. Orada spf=pass, dkim=pass, dmarc=pass üçlüsünü arıyorsun. Biri "fail" ya da "none" ise sorunun adresi bellidir. Bu testi her sunucu taşımasından, her alan adı ekinden ve her mail sağlayıcısı değişikliğinden sonra yeniden yapmak gerekir; çünkü bu üç kayıt tek seferlik bir kurulum değil, yaşayan bir yapılandırmadır.

SPF Kaydı Tam Olarak Neyi Onaylar, Neyi Onaylamaz?

SPF, alan adının DNS'ine yazdığın ve "benim adıma mail göndermeye yetkili sunucular şunlardır" diyen bir izin listesidir. Alıcı sunucu, mesajı getiren IP'yi bu listeyle karşılaştırır. Listede yoksa güven puanı anında düşer. Buradaki en yaygın hata, hosting paketi dışında bir gönderim yolu eklendiğinde listenin güncellenmemesidir: kurumsal mail için ayrı bir sağlayıcı kullanırsın, bülten için bir servis bağlarsın, sipariş maillerini sunucunun SMTP'siyle atarsın; üç farklı kaynak vardır ama SPF'te bir tanesi yazılıdır.

İkinci hata çoğaltmadır. Alan adına iki ayrı SPF TXT kaydı eklersen standart gereği sonuç "permerror" olur ve test tamamen çöker. Doğrusu, tüm yetkili kaynakları tek bir kayıtta include mekanizmasıyla birleştirmektir. Üçüncü hata ise kaydı +all ya da aşırı gevşek biçimde bırakmaktır; bu, "herkes benim adıma mail atabilir" demekle eşdeğerdir ve koruma sağlamaz. Unutma: SPF yalnızca gönderen sunucunun yetkisini onaylar, mesajın içeriğinin değişmediğini kanıtlamaz. İçerik bütünlüğü DKIM'in işidir.

DKIM İmzası Olmayan Sipariş Maili Neden Baştan Şüpheli Sayılır?

DKIM, gönderim anında mesaja özel anahtarla atılan bir imzadır. Alıcı, DNS'te yayınladığın açık anahtarı okur, imzayı doğrular ve konu satırından gövdeye kadar hiçbir şeyin yolda değiştirilmediğini matematiksel olarak görür. E-pin satışında bu ayrıntı sıradan bir teknik detay değil, doğrudan ticari güvenliktir; çünkü senin gönderdiğin mailin içinde tek kullanımlık bir değer vardır. İmzasız bir mesaj, araya girip içeriği değiştiren birine karşı hiçbir kanıt sunmaz.

Pratikte iki kritik nokta var. Birincisi anahtar uzunluğu: artık 1024 bit yerine daha güçlü anahtar tercih edilir, ama bazı DNS panelleri uzun TXT değerini bölerken hata yapar ve imza sessizce geçersiz olur. İkincisi selector yönetimidir; her gönderim kaynağının kendi selector'ı olur ve birini iptal ettiğinde DNS'ten temizlemeyi unutursan eski anahtar açıkta kalır. Bir e-pin scripti kurulumunda doğru alışkanlık, SMTP ayarını yaptıktan sonra ilk test mailinin başlıklarından imzanın gerçekten "pass" döndüğünü gözle teyit etmektir.

DMARC'ı "p=none" Konumunda Bırakan Herkes Aynı Tuzağa Düşüyor

DMARC iki iş yapar: SPF ve DKIM sonuçlarının, mailde görünen "kimden" adresiyle aynı alan adına hizalanıp hizalanmadığına bakar ve hizalama başarısız olursa alıcıya ne yapması gerektiğini söyler. Politikanın üç kademesi vardır: izle, karantinaya al, reddet. Herkes izleme modunda başlar, çünkü güvenlidir. Sorun, orada kalmaktır. İzleme modunda alan adını taklit eden biri, senin markanın adıyla müşterine "bakiye yüklemesi" maili atabilir ve alıcı sunucu bunu engellemek için bir talimat bulamaz.

Doğru sıra kademelidir. Önce izleme moduyla rapor topla, gönderim kaynaklarının tamamının hizalandığını gör, ardından karantinaya geç ve son olarak reddetmeye çık. Rapor adresini işleyecek bir yere yönlendirmezsen bu süreç kördür; XML raporlar bir yerde birikmeli ve okunmalıdır. Bu disiplini kuran işletmelerde teslim edilebilirlik sorunu bir daha gündeme gelmez, çünkü artık tahmin değil ölçüm vardır.

Paylaşımlı Hosting'in Yerleşik Mail Fonksiyonu Neden Sessiz Bir Kayıptır?

PHP'nin yerleşik mail fonksiyonu, geliştirme ortamında iş görür ama üretimde iki temel açığı vardır: gönderim kuyruğu ve kimlik. Kuyruk yoktur, yani sunucu o an meşgulse mesaj kaybolabilir; kimlik ise sunucunun paylaşımlı IP'sine bağlıdır. Aynı IP'yi seninle paylaşan bir hesap kötü gönderim yaparsa, senin dijital ürün satış scriptinin ürettiği sipariş maili de aynı kara listenin gölgesinde kalır. Bunu çözmenin yolu, gönderimi kimlik doğrulamalı bir SMTP üzerinden yapmaktır.

Kimlik doğrulamalı SMTP'ye geçtiğinde üç kazanç elde edersin: gönderim denemeleri loglanır, başarısızlıklar iade bildirimi olarak geri döner ve DKIM imzası sağlayıcı tarafında tutarlı biçimde eklenir. İyi yapılandırılmış bir e-pin yazılımı, SMTP bağlantısı koptuğunda mesajı kaybetmez; kuyruğa alır, belirli aralıklarla yeniden dener ve son durumu siparişin geçmişine yazar. Satıcı olarak senin görmek istediğin tablo tam olarak budur: her siparişin yanında mailin gerçekten kabul edildiğine dair bir iz.

Yeni Alan Adıyla İlk Günden Toplu Mail Atmak Neden Geri Teper?

Alan adının bir geçmişi vardır ve bu geçmiş sıfırdan başlar. Yeni kurduğun sistemin ilk haftasında bin kişilik bir duyuru gönderirsen, alıcı sunucular bunu ani bir davranış değişikliği olarak okur. Doğru yaklaşım ısıtmadır: önce yalnızca işlemsel mailler, yani sipariş onayı ve kod teslimi gitsin. Bu mailler açılma oranı en yüksek gönderim türüdür ve alan adının itibarını en hızlı biçimde olumlu yönde besler.

Ardından hacmi kademeli artırırsın. Bu süreçte iade bildirimlerini temizlemek, geçersiz adresleri listeden çıkarmak ve şikayet oranını izlemek zorunludur. Çünkü teslim edilebilirlik tek bir ayarın sonucu değil, sürekli bir bakım kalemidir. Pinova gibi bütünleşik bir e-pin satış yazılımı kullanmanın avantajı da burada ortaya çıkar: gönderim kaynağı tek, şablonlar tutarlı ve her mailin akıbeti sipariş kaydının içinde izlenebilir olur. Özellikler tarafındaki bildirim ve kuyruk yapısı tam olarak bu gürültüyü ortadan kaldırmak için vardır.

Özetle teslim edilebilirlik, satın aldığın dijital ürün satış scriptinin değil, alan adının kimliğinin meselesidir; ama iyi bir yazılım bu kimliği görünür kılar ve her gönderimin izini bırakır. Kendi kurulumunda bunun nasıl çalıştığını görmek istersen canlı demo üzerinden sipariş akışını ve bildirim geçmişini adım adım dene, sonra fiyat tarafında sana uygun lisansı seç.