SPF, DKIM, DMARC Nedir ve Birbirinden Farkı Ne

SPF, DKIM ve DMARC üçü birlikte anılır ama üçü de farklı bir soruyu cevaplar: SPF "bu IP bu domain adına göndermeye yetkili mi", DKIM "bu mesaj gerçekten imzalandığı domain'den mi geldi ve değişmedi mi", DMARC ise "SPF veya DKIM başarısız olursa alıcı sunucu ne yapsın" sorusunu cevaplar. B2B soğuk e-postada bu üçü eksiksiz kurulmadan gönderilen mesajlar, alıcı sunucu tarafında doğrulanamadığı için doğrudan spam klasörüne yönlendirilme riski taşır.

Neden üç ayrı protokol gerekiyor

E-posta, tasarımı gereği gönderen adresinin kolayca taklit edilebildiği (spoofing) bir protokol üzerine kuruludur. SPF, DKIM ve DMARC, bu boşluğu kapatmak için farklı zamanlarda geliştirilmiş ve birbirini tamamlayan üç katman oluşturur. Hiçbiri tek başına yeterli değildir — SPF sadece gönderen sunucuyu doğrular, DKIM sadece mesaj bütünlüğünü kanıtlar, DMARC ise ikisinin sonucunu birleştirip bir karar kuralı sunar.

B2B soğuk e-posta gönderen bir ekip için bu üçü anlamak teorik bir konu değil: alıcı sunucular (Gmail, Outlook, kurumsal mail geçitleri) bu kayıtları kontrol eder ve eksik veya yanlış yapılandırılmış bir domain'den gelen mesajı, gerçek içerik ne olursa olsun şüpheli olarak işaretleyebilir.

SPF nedir, nasıl çalışır

SPF (Sender Policy Framework), domain'inizin DNS'inde yayınlanan bir TXT kaydıdır ve genelde 'v=spf1 include:... ~all' veya '-all' ile biter. Bu kayıt, hangi sunucuların veya servislerin (kendi mail sunucunuz, kullandığınız CRM, ESP, fatura sistemi vb.) o domain adına e-posta göndermeye yetkili olduğunu listeler. Alıcı sunucu, gelen mesajın zarf (envelope) gönderen adresindeki IP'nin bu listede olup olmadığını kontrol eder.

SPF'in bilinen bir teknik sınırı var: bir domain'in SPF kaydında toplamda en fazla 10 DNS lookup (include/redirect zinciri) yapılabilir. Bu limit aşıldığında SPF kaydı 'permerror' ile başarısız sayılır. Birden fazla gönderim aracı (kurumsal e-posta, CRM, pazarlama aracı, fatura sistemi) domain'e eklendikçe bu limit kolayca aşılabilir — bu yüzden SPF kaydını düzenli gözden geçirmek gerekir.

SPF'in bir diğer önemli sınırı, yalnızca zarf (envelope) gönderen adresini, yani teknik olarak 'Return-Path' değerini kontrol etmesidir — kullanıcının posta kutusunda gördüğü 'Kimden' (From) başlığını doğrudan doğrulamaz. Bu ayrım önemlidir çünkü bir mesaj SPF kontrolünden geçse bile, alıcının gördüğü gönderen adı farklı bir domain'i taklit ediyor olabilir. Bu boşluğu kapatan katman DMARC'ın alignment kontrolüdür.

DKIM nedir, nasıl çalışır

DKIM (DomainKeys Identified Mail), gönderilen her e-postaya domain sahibinin özel anahtarıyla oluşturulmuş kriptografik bir imza ekler; bu imza mesajın başlığında 'DKIM-Signature' olarak görünür. Karşılık gelen açık anahtar ise DNS'te 'selector._domainkey.domain.com' formatında bir TXT kaydında yayınlanır.

Alıcı sunucu, gelen mesajdaki imzayı bu açık anahtarla doğrular. Doğrulama başarılıysa, mesajın gerçekten o domain tarafından imzalandığı ve yolda (aktarım sırasında) değiştirilmediği kanıtlanmış olur. SPF'ten farkı burada: SPF gönderen sunucunun kimliğine bakar, DKIM ise mesajın kendisinin bütünlüğüne ve gerçek kaynağına bakar.

DKIM'in SPF'e göre pratik bir avantajı var: mesaj yönlendirildiğinde (forward edildiğinde) bile imza genelde geçerliliğini korur, çünkü imza mesajın içeriğine ve başlıklarına bağlıdır, gönderen IP'ye değil. SPF ise yönlendirme sırasında genelde bozulur çünkü mesaj artık orijinal gönderenin değil, yönlendiren sunucunun IP'sinden gelir. Bu fark, DKIM'i özellikle mesajın birden fazla sunucu üzerinden geçtiği senaryolarda daha güvenilir kılar.

DMARC nedir, nasıl çalışır

DMARC (Domain-based Message Authentication, Reporting & Conformance), '_dmarc.domain.com' altında yayınlanan bir DNS TXT kaydıdır. DMARC, SPF ve DKIM sonuçlarını tek başına yeterli görmez; ayrıca 'alignment' (hizalama) kontrolü yapar — yani From başlığında görünen domain ile SPF/DKIM'in gerçekte kontrol ettiği domain'in eşleşip eşleşmediğine bakar.

DMARC kaydı, bu kontroller başarısız olursa alıcı sunucuya ne yapması gerektiğini söyler: p=none (sadece izle, herhangi bir aksiyon alma), p=quarantine (şüpheli/spam klasörüne yönlendir), veya p=reject (mesajı tamamen reddet). Ayrıca rua= etiketiyle toplu (aggregate) rapor adresleri, ruf= etiketiyle adli (forensic) rapor adresleri belirtilebilir; bu raporlar hangi kaynakların domain adına gönderim yaptığını ve doğrulamadan geçip geçmediğini gösterir.

DMARC'ın 'alignment' kavramı biraz daha ayrıntılı açıklanmayı hak ediyor: SPF alignment, Return-Path domain'i ile From başlığındaki domain'in aynı (veya aynı üst domain'e ait) olmasını ister; DKIM alignment ise imzayı atan domain (d= etiketi) ile From başlığındaki domain'in eşleşmesini ister. Bu iki hizalamadan en az biri sağlanmazsa DMARC başarısız sayılır — SPF veya DKIM tek başına 'geçti' dese bile, hizalama yoksa DMARC bunu kabul etmez.

B2B soğuk e-postada bu üçü neden özellikle kritik

Toplu bültenden farklı olarak adresli B2B soğuk e-posta genelde tanınmayan bir alıcıya ilk temas kurar — alıcı sunucu ve alıcının kendisi, bu gönderenle daha önce hiç etkileşime girmemiştir. Bu durumda kimlik doğrulama sinyalleri (SPF/DKIM/DMARC) filtrenin karar vermesinde normalden daha büyük ağırlık taşır, çünkü ortada henüz bir etkileşim geçmişi yoktur.

Domain doğrulanmadan (eksik SPF, imzasız DKIM, DMARC kaydı olmayan) gönderilen bir soğuk e-posta, içerik ne kadar kaliteli olursa olsun alıcı sunucu tarafında 'kimliği kanıtlanamamış gönderen' olarak değerlendirilir ve bu, doğrudan spam klasörüne yönlendirilme olasılığını belirgin şekilde artırır.

DMARC raporlarını okumak neden önemli

DMARC kaydına rua= etiketiyle bir rapor adresi eklendiğinde, büyük mail sağlayıcıları (Gmail, Outlook/Microsoft, Yahoo gibi) genelde günlük periyotlarla XML formatında toplu raporlar gönderir. Bu raporlar, domain'iniz adına hangi IP'lerden gönderim yapıldığını, bunların SPF/DKIM sonuçlarını ve hizalama durumunu gösterir. Ham XML formatı okunması zor olduğundan, dmarcian gibi DMARC izleme araçları bu raporları okunabilir bir panele dönüştürür.

Bu raporları düzenli incelemek iki şeyi ortaya çıkarır: birincisi, tanımadığınız bir kaynağın domain'iniz adına gönderim yaptığı (yetkisiz kullanım veya unutulmuş eski bir entegrasyon), ikincisi ise kendi bildiğiniz meşru bir aracın aslında SPF veya DKIM ile tam hizalı olmadığı. İkinci durum, p=quarantine veya p=reject'e geçmeden önce mutlaka düzeltilmesi gereken bir husustur — aksi halde o aracın gönderdiği meşru e-postalar da etkilenir.

Sık karışan noktalar

En sık karışan nokta, SPF'in 'her şeyi hallettiğini' düşünmek — oysa SPF sadece zarf gönderen adresini kontrol eder, kullanıcının gördüğü 'From' başlığını değil. DKIM imzası olmadan, mesaj yolda değiştirilse bile SPF bunu yakalamaz. İkinci sık hata, DMARC kaydını hiç kurmadan sadece SPF ve DKIM'e güvenmek — bu durumda alignment kontrolü yapılmaz ve From başlığı taklit edilen (ama SPF'i geçen farklı bir domain'den gönderilen) mesajlar yakalanamayabilir.

Üçüncü hata, DMARC'ı doğrudan p=reject ile başlatmak. Henüz tüm meşru gönderim araçları (CRM, ESP, fatura sistemi) SPF/DKIM ile hizalanmadan p=reject'e geçmek, kendi meşru e-postalarınızın da reddedilmesine yol açabilir.

Checklist: temel kimlik doğrulama kurulumu

B2B soğuk e-posta göndermeden önce şu üç kaydın varlığını ve doğruluğunu kontrol edin.

• SPF kaydı var mı, tüm meşru gönderim kaynakları listede mi, 10 lookup limitine yakın mı
• DKIM imzası aktif mi, açık anahtar DNS'te doğru selector ile yayınlanmış mı
• DMARC kaydı var mı, en azından p=none ile raporlama başlatılmış mı
• From başlığındaki domain ile SPF/DKIM'in kontrol ettiği domain hizalı mı
• DMARC raporları düzenli izleniyor mu, p=quarantine/reject geçişi planlanmış mı

Sık sorulan sorular