E-postalarımız Spam'e Düşüyor: SPF, DKIM ve DMARC Nedir?
Gönderdiğiniz e-postalar karşı tarafın gereksiz klasörüne düşüyorsa sorun genellikle içerikte değil, alan adınızın kimlik kayıtlarındadır. Üç kaydın ne işe yaradığı ve nasıl kurulduğu.
Teklifiniz müşteriye ulaşmıyor. Aradığınızda "gelmedi" diyorlar, sonra gereksiz klasöründe buluyorlar. Bazen de hiç gelmiyor. Bu, kurumsal e-postada en sık karşılaştığımız şikâyet ve neredeyse hiçbir zaman yazdığınız metinle ilgili değil.
Sorun genellikle şu: alan adınız adına e-posta göndermeye kimin yetkili olduğunu belirten kayıtlar eksik ya da yanlış. Alıcı sunucu bunu kontrol ediyor, doğrulayamıyor ve mesajı şüpheli sayıyor.
Neden böyle bir doğrulama var?
E-posta protokolü, gönderen adresinin doğruluğunu kendiliğinden kontrol etmiyor. Yani teknik olarak herkes "info@sizinfirmaniz.com" adresinden mesaj göndermiş gibi görünebilir. Sahte fatura ve dolandırıcılık e-postalarının çoğu tam olarak bunu yapıyor.
Bu açığı kapatmak için üç kayıt geliştirildi. Üçü birlikte çalışıyor: SPF hangi sunucuların gönderebileceğini söylüyor, DKIM mesajın yolda değişmediğini imzayla kanıtlıyor, DMARC ise doğrulama başarısız olursa ne yapılacağını söylüyor.
SPF: kimler benim adıma gönderebilir?
SPF kaydı, alan adınızın DNS ayarlarına eklenen bir metin satırı. İçinde sizin adınıza e-posta göndermeye yetkili sunucuların listesi var. Alıcı sunucu mesajı aldığında bu listeye bakıyor: gönderen sunucu listede yoksa mesaj şüpheli hâle geliyor.
En sık yapılan hata, göndericilerden birini listeye eklemeyi unutmak. Şirketler tek yerden e-posta göndermiyor: posta sunucusu bir tarafta, web sitesindeki iletişim formu başka bir sunucuda, e-bülten servisi üçüncü bir yerde, muhasebe programının fatura gönderimi dördüncü bir yerde. Hepsinin SPF kaydında olması gerekiyor.
İkinci sık hata: birden fazla SPF kaydı oluşturmak. Standart tek kayda izin veriyor; ikinci bir kayıt eklendiğinde doğrulama tamamen başarısız oluyor. Yeni bir gönderici eklerken yeni satır açmak yerine mevcut satırı genişletmek gerekiyor.
DKIM: mesaj gerçekten benden mi geldi?
DKIM, giden her mesaja görünmez bir dijital imza ekliyor. İmzayı posta sunucunuz özel bir anahtarla atıyor; alıcı, DNS'te yayımladığınız açık anahtarla imzayı doğruluyor. İmza tutuyorsa iki şey kanıtlanmış oluyor: mesaj gerçekten sizin sunucunuzdan çıkmış ve yolda değiştirilmemiş.
SPF sunucuya bakıyor, DKIM mesajın kendisine. Fark önemli: bir e-posta yönlendirildiğinde SPF kontrolü bozulabiliyor çünkü mesajı ileten sunucu artık sizin listenizde değil. DKIM imzası ise yönlendirmede korunuyor. Bu yüzden ikisi birlikte kuruluyor.
DMARC: doğrulama başarısız olursa ne olsun?
SPF ve DKIM kontrol yapıyor ama sonucunda ne olacağını söylemiyor. Alıcı sunucu "doğrulanamadı" durumunda ne yapacağına kendi karar veriyor — bazısı spam'e atıyor, bazısı geçiriyor. DMARC bu kararı sizin vermenizi sağlıyor.
DMARC kaydında üç politikadan biri seçiliyor:
- none — hiçbir şey yapma, sadece rapor gönder. Başlangıç için doğru ayar.
- quarantine — doğrulanamayan mesajları gereksiz klasörüne at.
- reject — doğrulanamayan mesajları hiç kabul etme.
DMARC'ın en değerli tarafı raporlama. Politika "none" iken bile, alan adınız adına kimin nereden e-posta gönderdiğine dair günlük raporlar gelmeye başlıyor. Bu raporlarda çoğu kurum unuttuğu göndericileri keşfediyor: yıllar önce kurulmuş bir bildirim sistemi, bir tedarikçinin sizin adınıza gönderdiği mesajlar.
Doğru kurulum sırası
Sıralama önemli. "Hepsini birden ekleyelim" yaklaşımı, unuttuğunuz bir göndericinin mesajlarının bir anda reddedilmesine yol açıyor — ve bunu genelde bir müşteri "sizden mail gelmiyor" diye aradığında öğreniyorsunuz.
- Gönderici envanterini çıkarın: posta sunucusu, site formu, bülten servisi, ERP/muhasebe, CRM, faturalandırma. Hepsi.
- SPF kaydını bu listeye göre tek satır hâlinde yazın.
- DKIM'i posta sağlayıcınızda etkinleştirin ve verdiği kaydı DNS'e ekleyin.
- DMARC'ı "none" politikasıyla ekleyin ve rapor adresi tanımlayın.
- Birkaç hafta raporları izleyin. Beklemediğiniz göndericiler çıkarsa SPF'i düzeltin.
- Raporlar temizlendiğinde politikayı önce "quarantine", sonra "reject" yapın.
Adım 5'i atlamak bu işin en pahalı hatası. Bir kurumda "reject" politikası açıldıktan sonra sipariş onay e-postalarının iki hafta boyunca hiç ulaşmadığı, çünkü onları gönderen sistemin SPF kaydında olmadığı ancak müşteri şikâyetleriyle anlaşılabiliyor.
Kayıtlar doğruysa hâlâ spam'e düşüyorsa
Üç kayıt da doğruyken teslimat sorunu sürüyorsa bakılacak yerler şunlar:
- IP itibarı: paylaşımlı bir sunucudan gönderiyorsanız aynı IP'yi kullanan başka birinin davranışı sizi de etkiliyor.
- Kara listeler: alan adınızın ya da IP'nizin herhangi bir listeye girip girmediği kontrol edilmeli.
- Gönderim hacmindeki ani artış: yıllarca günde on mesaj gönderen bir alan adından birden binlerce mesaj çıkması şüphe uyandırıyor.
- İçerik: tamamı görselden oluşan, kısaltılmış bağlantı içeren ya da yalnızca "Merhaba, ektedir" yazan mesajlar filtreleri tetikleyebiliyor.
- Geri dönen adresler: artık var olmayan adreslere gönderim sürüyorsa itibar düşüyor.
Bir de sık karıştırılan durum: mesajınız spam'e değil, alıcının kendi kurum içi kuralına takılmış olabiliyor. Karşı tarafın IT'sine sorulduğunda çözülen bir sorunu kendi tarafınızda haftalarca aramak mümkün.
DMARC raporlarını okumak
DMARC kaydına bir rapor adresi yazdığınızda, alan adınız adına gönderilen mesajlar hakkında günlük özetler gelmeye başlıyor. Raporlar XML biçiminde ve elle okunması zor; ama içlerindeki bilgi çok değerli.
Raporlarda üç grup göreceksiniz:
- Bildiğiniz ve doğrulamayı geçen gönderim kaynakları — olması gereken durum
- Bildiğiniz ama doğrulamayı geçemeyen kaynaklar — genelde unutulmuş bir sistem: fatura yazılımı, site form eklentisi, CRM
- Hiç tanımadığınız kaynaklar — adınıza gönderim denemesi
İkinci grup, p=none ayarından p=quarantine ayarına geçmeden önce mutlaka temizlenmeli. Aksi hâlde kendi meşru sistemleriniz karantinaya düşüyor ve fatura, sipariş onayı gibi mesajlar müşteriye ulaşmıyor.
Raporları okunur hâle getiren ücretsiz ve ücretli araçlar var. Hangisini kullandığınızdan bağımsız olarak ilk ay raporları düzenli takip etmek gerekiyor; sonrasında yalnızca bir değişiklik yaptığınızda bakmak yetiyor.
Toplu e-posta gönderiyorsanız
Bülten, kampanya ya da toplu bilgilendirme gönderiyorsanız bunları kurumsal e-posta sunucunuzdan göndermeyin. İki sebebi var.
Birincisi teslimat: toplu gönderim kalıbı spam filtrelerinin dikkatini çekiyor ve alan adınızın itibarı düşüyor. İkincisi daha ağır: itibar düştüğünde yalnızca bülten değil, günlük iş yazışmalarınız da spam klasörüne düşmeye başlıyor.
Doğru yol, toplu gönderim için ayrı bir servis kullanmak ve tercihen ayrı bir alt alan adından göndermek. Böylece bültenin itibarı ile kurumsal yazışmanın itibarı birbirinden ayrılıyor.
Alan adı itibarı nasıl korunur?
- Satın alınmış listelere gönderim yapmayın — şikâyet oranı hızla yükseliyor.
- Abonelikten çıkma bağlantısını her toplu mesajda bulundurun ve gerçekten çalıştığından emin olun.
- Uzun süredir açılmayan adresleri listeden çıkarın; ölü adresler itibarı düşürüyor.
- Yeni bir gönderim altyapısına geçtiğinizde hacmi kademeli artırın.
- Posta kutularınızın ele geçirilip spam gönderiminde kullanılmasını engelleyin.
Son madde en sık karşılaşılan itibar kaybı sebebi: ele geçen tek bir posta kutusundan gönderilen binlerce mesaj, alan adını günler içinde kara listeye taşıyabiliyor. İki adımlı doğrulama burada da ilk savunma.
Özet
E-postanız gereksiz klasörüne düşüyorsa önce metni değil, DNS kayıtlarını kontrol edin. SPF hangi sunucuların yetkili olduğunu, DKIM mesajın değişmediğini, DMARC doğrulama başarısız olduğunda ne yapılacağını söylüyor. Üçü birlikte kurulduğunda hem teslimat düzeliyor hem de alan adınız adına sahte mesaj gönderilmesi zorlaşıyor.
Kayıtların doğru olup olmadığını bilmiyorsanız kontrol etmek dakikalar sürüyor; düzeltmenin faturası ise ulaşmayan her teklif.