E-postalarım Neden Spam’e Düşüyor? SPF, DKIM ve DMARC Rehberi

E-posta neden doğrulamaya ihtiyaç duyar?

E-postayı taşıyan SMTP protokolü, internetin herkesin birbirine güvendiği bir dönemde tasarlandı. Protokolün kendisi, gönderenin gerçekten iddia ettiği kişi olup olmadığını hiçbir biçimde denetlemez: bir mektubun zarfına istediğiniz gönderen adresini yazabildiğiniz gibi, bir e-postanın “Kimden” alanına da istediğiniz adresi yazabilirsiniz. Oltalama saldırılarının ve sahte fatura e-postalarının bu kadar yaygın olmasının temel nedeni budur.

SPF, DKIM ve DMARC, bu boşluğu sonradan kapatmak için geliştirilmiş üç ayrı mekanizmadır. Üçü de alan adınızın DNS’ine eklenen TXT kayıtlarıyla çalışır ve alıcı sunucuya şu sorunun cevabını verir: “Bu ileti gerçekten bu alan adının sahibinin bilgisi dahilinde mi gönderildi?” Büyük e-posta sağlayıcıları bu kayıtları artık fiilen zorunlu tutuyor; eksik ya da hatalı olduklarında iletileriniz içeriği ne kadar masum olursa olsun spam klasörüne düşebilir ya da tümüyle reddedilebilir.

Önce bir ayrım: zarf göndereni ve görünen gönderen

Bir e-postada iki farklı “gönderen” vardır ve konunun tamamı bu ayrıma dayanır. Zarf göndereni (MAIL FROM ya da Return-Path), sunucular arasındaki SMTP konuşmasında bildirilen adrestir; teslim edilemeyen iletilerin geri döndüğü yerdir ve kullanıcı bunu normalde görmez. Görünen gönderen ise iletinin başlığındaki From alanıdır; e-posta programınızda gördüğünüz ad ve adres budur.

Bu ikisi aynı olmak zorunda değildir. Bir bülten servisi aracılığıyla gönderdiğiniz iletide görünen gönderen bilgi@ornek.com.tr olabilirken zarf göndereni servisin kendi alan adındaki bir geri dönüş adresi olabilir. SPF zarf gönderenine, DKIM imzadaki alan adına bakar; kullanıcının gördüğü adresle bunlar arasındaki bağı kuran ise DMARC’tır.

SPF: bu alan adı adına kim gönderebilir?

SPF (Sender Policy Framework), alan adınız adına e-posta göndermeye yetkili sunucuların listesidir. Alıcı sunucu, bağlantıyı kuran IP adresini alır, zarf gönderenindeki alan adının SPF kaydını DNS’ten sorgular ve IP’nin listede olup olmadığına bakar. Tipik bir kayıt şöyledir:

v=spf1 ip4:203.0.113.25 include:_spf.eposta-servisi.net -all

• v=spf1: Kaydın bir SPF kaydı olduğunu belirtir; en başta yer almalıdır.
• ip4: ve ip6: Yetkili IP adreslerini ya da bloklarını doğrudan sayar.
• a ve mx: Alan adının A ya da MX kayıtlarının gösterdiği sunucuları yetkilendirir.
• include: Başka bir alan adının SPF kaydını içeri alır. Kullandığınız e-posta ve bülten servisleri, eklemeniz gereken include değerini belgelerinde verir.
• all: Listeye uymayan herkes için hükmü belirler. -all “reddet” (hardfail), ~all “şüpheli say” (softfail), ?all “yorum yok” anlamına gelir. +all ise herkese izin verir ve kaydı anlamsız kılar.

SPF’in sınırları

İki önemli kısıt vardır. Birincisi, bir alan adında yalnızca tek bir SPF kaydı bulunabilir; iki ayrı v=spf1 kaydı doğrulamanın kalıcı hatayla sonuçlanmasına neden olur. Yeni bir servis eklerken ikinci bir kayıt açmak yerine mevcut kayda bir include daha eklemelisiniz. İkincisi, SPF değerlendirmesi sırasında en fazla 10 DNS sorgusu yapılabilir; include, a, mx gibi mekanizmaların her biri bu sayaçtan düşer ve iç içe include’lar da hesaba katılır. Çok sayıda servis kullanan alan adları bu sınıra fark etmeden ulaşır.

SPF’in yapısal bir zayıflığı da iletmedir (forwarding). Bir ileti başka bir adrese otomatik iletildiğinde, onu son alıcıya teslim eden sunucu sizin listenizde yer almaz ve SPF başarısız olur. DKIM’in varlık nedenlerinden biri budur.

DKIM: ileti yolda değişti mi?

DKIM (DomainKeys Identified Mail) bir dijital imzadır. Gönderen sunucu, iletinin seçili başlıklarının ve gövdesinin özetini özel anahtarıyla imzalar ve sonucu DKIM-Signature başlığı olarak iletiye ekler. Bu başlıkta iki kritik bilgi bulunur: imzalayan alan adı (d=) ve seçici (s=). Alıcı sunucu bu ikisini birleştirerek açık anahtarı DNS’ten sorgular. Örneğin seçici “posta2024” ise sorgulanan ad şudur:

posta2024._domainkey.ornek.com.tr

Bu addaki TXT kaydı v=DKIM1; k=rsa; p=MIIBIjANBg… biçimindedir; p= alanı açık anahtarı taşır. Alıcı bu anahtarla imzayı doğrular. İmza tutuyorsa iki şey kanıtlanmış olur: ileti gerçekten o alan adının özel anahtarına sahip bir sistem tarafından imzalanmıştır ve imzalanan kısımlar yolda değiştirilmemiştir.

Seçici mekanizması sayesinde aynı alan adında birden fazla anahtar bir arada yaşayabilir: kurumsal posta sunucunuz bir seçiciyi, bülten servisiniz bir başkasını kullanır. Bu aynı zamanda anahtar yenilemeyi kolaylaştırır; yeni seçiciyi yayımlar, gönderimi ona geçirir, eskisini bir süre sonra kaldırırsınız. Günümüzde 2048 bit RSA anahtarlar yaygın tercihtir; daha kısa anahtarlar bazı alıcılar tarafından zayıf kabul edilir.

DKIM, imza iletiyle birlikte taşındığı için iletmeden etkilenmez. Zayıf noktası ise iletiyi değiştiren aracılardır: konu satırına etiket ekleyen ya da gövdenin altına dipnot yerleştiren e-posta listeleri imzayı bozabilir.

DMARC: ikisini birleştiren politika

SPF ve DKIM tek başlarına önemli bir açık bırakır: ikisi de kullanıcının gördüğü From adresini denetlemez. Bir saldırgan kendi alan adı için kusursuz SPF ve DKIM kurup From alanına sizin adresinizi yazabilir. DMARC bu açığı hizalama (alignment) kavramıyla kapatır: iletinin DMARC’tan geçmesi için SPF ya da DKIM’den en az birinin hem başarılı olması hem de doğrulanan alan adının From alanındaki alan adıyla örtüşmesi gerekir.

DMARC kaydı _dmarc alt adına eklenir. _dmarc.ornek.com.tr için örnek:

v=DMARC1; p=quarantine; rua=mailto:dmarc-rapor@ornek.com.tr; adkim=r; aspf=r

DMARC’ın en değerli yanı raporlardır. rua adresine, alıcı sağlayıcılardan düzenli olarak XML biçiminde toplu raporlar gelir: alan adınız adına hangi IP’lerden kaç ileti gönderildi, hangileri SPF ve DKIM’den geçti, hangileri kaldı. Bu raporlar çoğu zaman unutulmuş gönderim kaynaklarını ortaya çıkarır: eski bir form eklentisi, muhasebe yazılımının fatura gönderimi, bir yazıcının tarama e-postaları. Ham XML okumak zahmetli olduğundan raporları özetleyen bir çözümleme hizmeti kullanmak işleri kolaylaştırır.

Adım adım kurulum sırası

1. Gönderim kaynaklarının dökümünü çıkarın: Kurumsal posta hizmeti, web sitesinin iletişim formu, bülten servisi, e-ticaret ve muhasebe yazılımları, destek sistemi. Alan adınız adına ileti gönderen her şey listede olmalı.
2. SPF kaydını yayımlayın: Tüm kaynakları tek bir kayıtta toplayın. Listeden eminseniz -all, geçiş dönemindeyseniz ~all ile bitirin.
3. Her kaynak için DKIM’i etkinleştirin: Servislerin çoğu size yayımlamanız gereken bir seçici ve TXT (ya da CNAME) kaydı verir. İmzanın kendi alan adınızla atıldığından emin olun; servisin varsayılan alan adıyla atılan imza hizalamayı sağlamaz.
4. DMARC’ı p=none ile başlatın: Bu aşamada hiçbir ileti engellenmez, yalnızca rapor toplarsınız.
5. Raporları birkaç hafta izleyin: Meşru olup doğrulamadan geçemeyen kaynakları bulun ve düzeltin.
6. Politikayı kademeli sıkılaştırın: Önce quarantine, isterseniz pct ile küçük bir yüzdeyle; her şey temizse reject.
7. Doğrulayın: Kendinize bir test iletisi gönderip başlıklardaki Authentication-Results satırına bakın; spf=pass, dkim=pass ve dmarc=pass görmelisiniz. Kayıtların DNS’te doğru yayımlandığını bir DNS kayıt sorgulama aracıyla TXT türünü seçerek kontrol edebilirsiniz.

Kara listeler ve IP itibarı

Kimlik doğrulama “bu ileti gerçekten sizden mi?” sorusunu cevaplar; “siz iyi bir gönderen misiniz?” sorusunu değil. İkincisi itibar meselesidir. Kara listeler (RBL ya da DNSBL), spam gönderdiği gözlemlenen IP adreslerini DNS üzerinden sorgulanabilir biçimde yayımlar; alıcı sunucular bağlantı anında bu listelere bakar ve listedeki IP’lerden gelen iletileri reddedebilir ya da puanını düşürebilir.

Bir IP’nin listeye girmesinin yaygın nedenleri şunlardır: ele geçirilmiş bir hesap ya da web sitesindeki açık üzerinden spam gönderilmesi, satın alınmış ya da bayatlamış adres listelerine toplu gönderim, tuzak adreslere (spam trap) ileti düşmesi. Paylaşımlı barındırmada IP’yi başkalarıyla paylaştığınız için komşularınızın davranışı da sizi etkiler. Sorgulaa’nın IP kara liste sorgulama aracı gibi bir denetleyiciyle gönderim IP’nizin durumuna bakabilirsiniz. Listedeyseniz sıralama önemlidir: önce spam’in kaynağını bulup kapatın, sonra liste operatörünün kendi sitesindeki çıkarma sürecini izleyin. Neden ortadan kalkmadan yapılan çıkarma talebi, kısa sürede yeniden listelenmeyle sonuçlanır.

Gönderim IP’nizin ters DNS (PTR) kaydı da itibarın parçasıdır. Birçok alıcı, PTR kaydı olmayan ya da PTR’ın gösterdiği ad yeniden aynı IP’ye çözümlenmeyen sunuculardan gelen iletilere kuşkuyla yaklaşır. PTR kaydını alan adı panelinizden değil, IP’nin sahibi olan barındırma ya da servis sağlayıcınız üzerinden tanımlatırsınız.

Doğrulama tamam ama hâlâ spam’e düşüyorsa

SPF, DKIM ve DMARC giriş biletidir; gelen kutusunu garanti etmez. Bundan sonrasını alıcıların davranışı ve içeriğiniz belirler:

• Liste temizliği: Geri dönen (bounce) adresleri listeden çıkarın, uzun süredir hiçbir iletiyi açmayan aboneleri ayıklayın. Çift onaylı (double opt-in) kayıt, hatalı ve sahte adreslerin listeye girmesini baştan önler.
• Kolay abonelikten çıkış: Çıkış bağlantısını bulamayan kullanıcı “spam olarak işaretle” düğmesine basar; bu da itibarınıza doğrudan zarar verir. Toplu gönderimlerde List-Unsubscribe başlığını kullanın.
• Hacmi kademeli artırın: Yeni bir IP ya da alan adından bir anda yüksek hacimli gönderim yapmak şüphe uyandırır. Hacmi günler ve haftalar içinde artırmak (ısındırma) itibarın oluşmasına zaman tanır.
• İşlemsel ve pazarlama iletilerini ayırın: Şifre sıfırlama ve sipariş onayı gibi kritik iletileri, bültenlerden ayrı bir alt alan adı ya da IP üzerinden göndermek, birindeki itibar sorununun diğerini etkilemesini önler.
• İçerik: Tek bir büyük görselden oluşan iletiler, bağlantı kısaltıcılar ve görünen metinle hedefi uyuşmayan bağlantılar filtrelerin dikkatini çeker.

Sık yapılan hatalar

• İki ayrı SPF kaydı yayımlamak: Her yeni servis için yeni kayıt açmak en yaygın hatadır. Tek kayıt, birden çok include.
• 10 sorgu sınırını aşmak: Kullanılmayan servislerin include’larını temizleyin; kayıt zamanla birikir.
• İzlemeden doğrudan p=reject’e geçmek: Unuttuğunuz bir gönderim kaynağının iletileri sessizce reddedilir ve bunu müşterilerinizden öğrenirsiniz.
• p=none’da sonsuza dek kalmak: İzleme modu sahteciliğe karşı hiçbir koruma sağlamaz; bir ara duraktır, varış noktası değil.
• Hizalamayı gözden kaçırmak: Başlıklarda spf=pass ve dkim=pass görüp dmarc=fail almak mümkündür; neden neredeyse her zaman doğrulanan alan adının From alanıyla örtüşmemesidir.
• E-posta göndermeyen alan adlarını korumasız bırakmak: Yalnızca yönlendirme için tuttuğunuz ya da park ettiğiniz alan adları sahtecilik için idealdir. Bunlara v=spf1 -all ve p=reject içeren bir DMARC kaydı ekleyin.
• Uzun DKIM anahtarını yanlış bölmek: Tek bir TXT dizgisi 255 karakterle sınırlıdır; 2048 bit anahtarlar birden çok dizgiye bölünerek girilir. Bazı paneller bunu kendisi yapar, bazıları yapmaz; kaydı yayımladıktan sonra dışarıdan sorgulayıp bütün olarak döndüğünü doğrulayın.

Özetle: SPF kimin gönderebileceğini, DKIM iletinin özgün olduğunu, DMARC ise bu ikisinin kullanıcının gördüğü adresle tutarlı olmasını ve tutmadığında ne yapılacağını söyler. Üçünü doğru kurmak teslim edilebilirliğin ön koşuludur; kalıcı olarak gelen kutusunda kalmak ise temiz bir liste, düzgün bir gönderim disiplini ve alıcıların gerçekten almak istediği iletilerle mümkündür.