SPF, DKIM ve DMARC: E-posta Sahteciliğini Durdurma Rehberi

Şu an, tanımadığınız biri bilgisayarının başında oturup “Kimden” satırına sizin şirket alan adınızı yazabilir ve muhasebenize “IBAN değişti, ödemeyi şu hesaba yapın” diyen bir mail gönderebilir. Alıcının kutusuna adınızla, logonuzla düşer. Klasik e-posta protokolü kimin gönderdiğini doğrulamaz — mektubun zarfına istediğiniz gönderen adresini yazmak gibi.

İşte SPF, DKIM ve DMARC bu boşluğu kapatan üç DNS kaydı. Üçü birlikte, “bu alan adından ancak şu sunucular mail gönderebilir ve gönderdiği doğrulanabilir” diyor. Kurulumları teknik görünüyor ama mantığı basit.

Üç kayıt tam olarak neyi çözüyor?

Her biri ayrı bir soruya cevap veriyor:

Kayıt	Sorduğu soru	DNS’te ne olarak durur
SPF	Bu alan adına hangi sunucular mail gönderebilir?	TXT kaydı — yetkili IP/host listesi
DKIM	Mail yolda değiştirildi mi, imzası geçerli mi?	Şifreli imza (açık anahtar TXT’te)
DMARC	SPF/DKIM geçmezse ne yapılsın, kim raporlansın?	TXT kaydı — politika + rapor adresi

SPF tek başına yeterli değil, çünkü iletilen (forward) maillerde bozulur. DKIM imzayı taşır ama “imzasız mail gelirse ne olacak” sorusunu boş bırakır. DMARC ikisini birbirine bağlar: “From satırındaki alan adı, SPF veya DKIM’de doğrulanan alan adıyla örtüşsün — yoksa şu kuralı uygula.” Buna hizalama (alignment) deniyor ve sahteciliği asıl durduran şey bu.

Neden tam da şimdi konuşuyoruz?

Bu kayıtlar yıllardır vardı, çoğu şirket görmezden geldi. Artık lüks değil, geçiş şartı:

• Google ve Yahoo, Şubat 2024’ten beri günde 5.000’den fazla mail gönderenlerden en az p=none seviyesinde bir DMARC kaydı ve hizalama istiyor. Uymayan mail teslim edilmiyor.
• Microsoft, 5 Mayıs 2025’ten itibaren Outlook.com, Hotmail ve Live adreslerine günde 5.000’den fazla mail gönderenler için SPF + DKIM + DMARC’ı zorunlu kıldı. Eksikse mail junk’a bile düşmüyor, doğrudan 550 5.7.15 Access denied hatasıyla reddediliyor.

5.000 sınırının altındaysanız “beni ilgilendirmez” demeyin. Asıl mesele teslimat değil, alan adınızın çalınması. DMARC’ı reject seviyesine çekmiş bir alan adından kimse sizin adınıza sahte mail gönderemez. Bu, sahte ödeme talimatı dolandırıcılığına ve yönetici taklidi saldırılarına karşı elinizdeki en ucuz teknik önlem — maliyeti birkaç DNS kaydı.

p=none’dan reject’e: acele etmeden geçiş

En sık yapılan hata, alan adını daha ilk gün p=reject’e çekip meşru mailleri (fatura sistemi, e-bülten aracı, İK yazılımı) çöpe göndermek. Doğru yol kademeli:

1. İzle (p=none). DMARC kaydını raporlama moduyla yayınlayın. Kimse engellenmez ama her gün “sizin adınıza kimler mail gönderiyor” raporu gelir. Genelde 2-4 haftalık bir gözlem yeterli.
2. Temizle. Raporlarda çıkan meşru gönderenleri (Microsoft 365, muhasebe yazılımı, pazarlama aracı) SPF ve DKIM’e ekleyin. Tanımadıklarınız zaten sahtecileri gösterir.
3. Karantinaya al (p=quarantine). Doğrulanmayan mailler spam klasörüne düşsün. Birkaç hafta daha izleyin.
4. Reddet (p=reject). Artık doğrulanmayan her mail tamamen engellenir. Hedef bu.

Tipik bir KOBİ için tüm süreç bir–iki ayda tamamlanır. Aceleye getirmenin bedeli, kaybolan fatura mailidir.

Sahada en çok karşılaştığımız üç hata

Kayıtları kuran çok firma var, düzgün kuran az. Tekrar tekrar aynı üç şeye takılıyoruz:

• SPF’te “birden fazla TXT kaydı” hatası. Bir alan adında yalnızca tek bir SPF kaydı olabilir. Yeni bir servis ekleyince ikinci bir v=spf1 satırı açan firmalar, ilk kaydı da geçersiz kılıyor. Hepsini tek satırda birleştirmek gerekiyor.
• SPF’te 10 DNS sorgusu sınırını aşmak. Her include: bir sorgu sayılır. Microsoft 365, muhasebe yazılımı, pazarlama aracı derken sınır dolunca SPF sessizce “permerror” verir ve doğrulama çöker. Kullanılmayan servisleri temizlemek şart.
• DMARC’ı p=none’da unutmak. En yaygın olanı bu. Kayıt yıllarca izleme modunda kalıyor, kimse raporlara bakmıyor. p=none sahteciyi engellemez, sadece görür. Koruma ancak reject’e geçince başlar.

Bir de rapor adresi (rua) hiç konmadan yayınlanan kayıtlar var — o zaman sistem size kimse rapor göndermez ve kör uçarsınız. Küçük ayrıntı, ama koca farkı bu ayrıntılar yaratıyor.

Sık sorulan sorular

Sadece SPF kursam yetmez mi? Hayır. SPF, mail bir yere iletildiğinde (forward) kırılır ve “From” satırını doğrulamaz. Gerçek koruma üçünün birlikte, hizalamayla çalışmasından gelir.

Microsoft 365 kullanıyorum, hepsi otomatik değil mi? SPF ve temel DKIM büyük ölçüde hazır gelir ama DMARC kaydını sizin yayınlamanız gerekir. Kendi alan adınızdan (@sirketiniz.com.tr) gönderiyorsanız DKIM’i alan adınıza özel yapılandırmak da şart.

Yanlış kurarsam maillerim kesilir mi? p=none ile başladığınız sürece hayır — o aşamada hiçbir mail engellenmez, sadece raporlanır. Riski quarantine ve reject adımlarına geçerken kontrol edersiniz.

Raporları kim okuyacak, XML dosyaları anlaşılmıyor? DMARC raporları ham XML gelir, elle okunmaz. Bir rapor işleme aracına ya da bu işi yürüten bir BT iş ortağına yönlendirmek pratik yoldur.

Alan adınızın şu an hangi seviyede olduğunu bilmiyorsanız, işe oradan başlayalım: mevcut SPF, DKIM ve DMARC kayıtlarınızı kontrol edip güvenli bir geçiş planı çıkaralım. Bize ulaşın, alan adınızın karnesini birlikte görelim.