SPF, DKIM ve DMARC Birlikte Nasıl Çalışır?

SPF kaydınız var, DKIM imzanız yapılandırılmış, DMARC politikanız yayında — ama e-postalar hâlâ bazen spam klasörüne düşüyor ya da bazı alıcılara ulaşmıyor. Üç mekanizma da kendi başına doğru çalışıyor görünebilir; sorun, bunların birlikte nasıl değerlendirildiğinde gizli. Her biri ayrı bir doğrulama katmanı sunar, ama nihai karar alıcı sunucunun bu üçünü birden nasıl yorumladığına bağlıdır.

SPF, DKIM ve DMARC'ın ne olduğu ve nasıl kurulduğu SPF, DKIM ve DMARC yazılarında ayrıntılı ele alındı. Burada farklı bir soruyu yanıtlıyoruz: bu üç mekanizma aynı mesaj üzerinde aynı anda çalıştığında aralarındaki ilişki nasıl işliyor, birinin başarısız olması diğerlerini nasıl etkiliyor ve alıcı sunucu bu karmaşık değerlendirmeyi nasıl tek bir karara dönüştürüyor?

Bu soruların cevabı, e-posta teslimini salt teknik bir kurulum meselesi olarak değil, birbirine bağlı bir sistem olarak anlamayı gerektiriyor. Üç mekanizmadan birinin eksik ya da yanlış yapılandırılmış olması, diğer ikisini de etkiliyor — çoğu zaman sessizce, görünür bir hata olmadan.

Alıcı sunucunun değerlendirme sırası

Bir e-posta alıcı sunucuya ulaştığında, sunucu SMTP bağlantısı kurulur kurulmaz SPF doğrulamasını başlatır. Bu, mesajın içeriğini görmeden önce gerçekleşir. SPF, gönderen IP adresinin domain'in DNS kaydında yetkili olup olmadığını kontrol eder — "bu IP'nin bu domain adına posta göndermesine izin var mı?" sorusunu yanıtlar. Değerlendirme SMTP oturumu sırasında, MAIL FROM komutuyla birlikte tetiklenir.

DKIM doğrulaması mesaj alındıktan sonra başlar çünkü imzanın doğrulanabilmesi için mesaj başlıklarının mevcut olması gerekir. Sunucu DKIM-Signature başlığını okur, selector ve domain bilgisini alır, DNS'ten açık anahtarı sorgular ve imzayı doğrular. Bu adım SPF'ten bağımsızdır; SPF sonucu ne olursa olsun DKIM değerlendirmesi ayrıca yapılır.

DMARC değerlendirmesi en sona kalır ve her iki mekanizmanın sonuçlarını bekler. SPF ve DKIM sonuçlarını aldıktan sonra DMARC, gönderen domain'in kendi _dmarc TXT kaydındaki politikayı sorgular ve bir karar üretir. Bu karar — teslim et, karantinaya al veya reddet — DMARC politikasına ve SPF/DKIM alignment sonuçlarına göre belirlenir.

1. SMTP bağlantısı → SPF kontrolü (MAIL FROM domain'i)
2. Mesaj alındı   → DKIM doğrulaması (DKIM-Signature başlığı)
3. Her ikisi de   → DMARC değerlendirmesi (alignment + politika)
   tamamlandı        → disposition: none / quarantine / reject

Bu sıra önemli çünkü DMARC, SPF ve DKIM'in yalnızca "geçti/geçmedi" sonuçlarını değil, alignment durumlarını da değerlendirir. Ve alignment, üç mekanizmanın birbirinden bağımsız birer kontrolden nasıl birbirine bağlı bir sisteme dönüştüğünü açıklayan kavramdır.

Alignment kavramı: teknik "pass" neden yetmez?

SPF veya DKIM'in teknik olarak "pass" dönmesi, DMARC açısından yeterli değildir. DMARC'ın aradığı şey alignment — yani doğrulanan domain'in, e-postanın "From" başlığındaki domain'le eşleşmesi. Bu ayrım, e-posta kimlik sahteciliğine (spoofing) karşı temel bir koruma katmanı oluşturur.

SPF alignment'ını şöyle düşünebilirsiniz: SPF, mesajın envelope-from (zarf gönderici) domain'ini doğrular. Bu domain, mesajın From başlığındaki domain'den farklı olabilir. Örneğin bir gönderim servisi mesajlarınızı kendi altyapısından gönderdiğinde, envelope-from adresi servise ait olabilir ([email protected] gibi) ama From başlığı sizin domain'inizi gösterir ([email protected]). SPF teknik olarak geçse de — çünkü servisin IP'si kendi domain'inin SPF kaydında yetkili — DMARC açısından SPF alignment başarısız olur. "From" domain'i ile SPF'in doğruladığı domain farklı.

DKIM alignment farklı çalışır. DKIM imzasındaki d= etiketi hangi domain'in anahtarıyla imzalandığını gösterir. Bu domain "From" başlığıyla eşleşiyorsa alignment sağlanmış olur. Aynı gönderim servisi örneğine dönersek: servis DKIM imzasını sizin domain'inizin anahtarıyla atıyorsa (d=example.com), DKIM alignment sağlanır. DMARC bu alignment'a dayanarak geçebilir.

DMARC, iki mekanizmadan yalnızca birinin alignment sağlamasını yeterli sayar. SPF alignment başarısız olsa bile DKIM alignment geçiyorsa DMARC geçer; tam tersi de geçerli. Bu esneklik, farklı gönderim altyapılarıyla çalışmayı mümkün kılar — her servis için SPF alignment'ı zorlamak pratikte çoğu zaman mümkün değil, ama DKIM alignment genellikle sağlanabilir.

From: [email protected]          ← DMARC'ın referans aldığı domain

SPF alignment: envelope-from domain == example.com?
  MAIL FROM: [email protected]    → pass (eşleşiyor)
  MAIL FROM: [email protected]     → fail (eşleşmiyor)

DKIM alignment: d= değeri == example.com?
  DKIM-Signature: d=example.com   → pass (eşleşiyor)
  DKIM-Signature: d=servis.com    → fail (eşleşmiyor)

DMARC kaydında aspf ve adkim etiketleriyle alignment modunu belirleyebilirsiniz. r (relaxed) modda alt domain eşleşmeleri de geçerli sayılır: mail.example.com, example.com ile relaxed alignment'ta eşleşir. s (strict) modda tam eşleşme zorunludur. Varsayılan her ikisi de r'dir ve çoğu yapılandırma için bu yeterli.

Biri başarısız olduğunda DMARC ne yapar?

DMARC'ın kararı daima iki sorunun cevabına dayanır: SPF alignment sağlandı mı? DKIM alignment sağlandı mı? Bu soruların her kombinasyonu farklı bir sonuç üretir ve her sonuç DMARC politikasıyla kesişerek nihai disposition'ı belirler.

Her iki alignment da geçiyorsa DMARC geçer, politika ne olursa olsun mesaj teslim edilir. Bu en temiz senaryo — iki bağımsız mekanizma da domain'i doğrulamış, alıcı sunucunun kuşkusu yok.

Yalnızca DKIM alignment geçiyor, SPF başarısız ise DMARC yine de geçer. Bu, üçüncü taraf gönderim servisleri kullanan yapılarda en yaygın senaryo. Servis kendi altyapısından gönderdiği için SPF alignment sağlanamaz, ama DKIM imzası domain'e ait olduğu için alignment geçer. DKIM selector yapılandırması doğru kurulduğunda bu kombinasyon sorunsuz çalışır.

Yalnızca SPF alignment geçiyor, DKIM başarısız ise de DMARC geçer. Ama bu daha riskli bir konumdur. DKIM imzası olmayan ya da bozuk imza taşıyan mesajlar, bazı spam filtrelerinde ekstra şüpheyle karşılanır. Üstelik iletim sırasında (forwarding) SPF alignment kolayca bozulabilir — DKIM imzası ise mesaj değiştirilmediği sürece korunur. Uzun vadede DKIM'i sağlamak daha dayanıklı bir yapı sunar.

Her iki alignment da başarısız olursa DMARC fail olur. Bu noktada politika devreye girer. p=none ise mesaj teslim edilir ama DMARC raporu üretilir — gözlem modunda çalışıyorsunuz demektir. p=quarantine ise alıcı sunucu mesajı spam ya da junk klasörüne yönlendirir. p=reject ise mesaj doğrudan reddedilir, göndericiye bounce döner.

Forwarding (yönlendirme) senaryosu özellikle dikkat ister. Bir mesaj bir alıcı sunucudan başka bir sunucuya yönlendirildiğinde — örneğin kurumsal bir adrese gelen e-posta kişisel adrese yönlendiriliyor — gönderen IP değişir ve SPF alignment neredeyse her zaman bozulur. DKIM imzası ise mesaj değiştirilmediği sürece geçerli kalır ve forwarding sonrasında tek geçerli doğrulama katmanı olur. Bu, DKIM'in "From" başlığına bağlı alignment yapısının forwarding'e karşı neden daha dayanıklı olduğunu açıklar.

Üçü birlikte doğru yapılandırılmış bir domain nasıl görünür?

Sağlıklı bir e-posta doğrulama yapısı, alıcı sunucunun bakış açısından şöyle görünür: SPF kaydı tüm yetkili gönderim kaynaklarını kapsıyor, DKIM her gönderim kanalı için imzalama yapıyor ve DMARC her iki mekanizmadan en az birinin alignment sağladığını doğruluyor.

Somut bir örnek üzerinden gidelim: domain'inizden Google Workspace üzerinden dahili yazışmalar, Mailchimp üzerinden pazarlama e-postaları ve bir destek platformu üzerinden müşteri bildirimleri gönderiyorsunuz.

v=spf1 include:_spf.google.com include:servers.mcsv.net include:mail.destek-platform.com ~all

Bu kayıt üç servisin IP aralıklarını kapsıyor. SPF teknik olarak geçer ama alignment için envelope-from domain'inin sizin domain'inizle eşleşmesi gerekir — üçüncü taraf servisler genellikle kendi domain'lerini kullandığı için SPF alignment çoğunlukla sağlanmaz. Bu yüzden her servis için DKIM yapılandırması kritik hale gelir.

google._domainkey.example.com      TXT  "v=DKIM1; k=rsa; p=..."
mailchimp._domainkey.example.com   CNAME k1._domainkey.mailchimp.com
destek._domainkey.example.com      TXT  "v=DKIM1; k=rsa; p=..."

Her servis kendi selector'ıyla imzalar ve d=example.com ile DKIM alignment sağlar. DMARC değerlendirmesinde her kaynaktan gelen mesajlar için DKIM alignment geçer, SPF alignment geçmese bile DMARC geçer.

_dmarc.example.com  TXT  "v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]; adkim=r; aspf=r"

DMARC raporları, bu yapının gerçekte nasıl çalıştığını doğrular. Her kaynaktan gelen mesajların alignment durumu, raporlardaki policy_evaluated bölümünde görünür. Yapılandırma tamamlandıktan sonra birkaç gün rapor okumak, beklenen kaynakların doğru alignment sağlayıp sağlamadığını ve beklenmedik bir kaynağın domain adına mesaj gönderip göndermediğini açığa çıkarır.

Kademeli devreye alma stratejisi

Üç mekanizmayı birden sıfırdan kurmak mümkün ama riskli. Politikayı hemen reject'e almak, yapılandırma eksikliklerini teslimatta kritik hatalara dönüştürür. Kademeli yaklaşım çok daha güvenli.

İlk aşama gözlem modudur. p=none ile başlayın; bu politikada DMARC hiçbir mesajı etkilemez ama tüm kaynakları raporlar. SPF ve DKIM kayıtlarını ekleyin, tüm gönderim servislerini kapsadığınızı doğrulayın. Bu aşamada TXT kaydı yönetimi ve DNS yapısı oturur. En az iki hafta, tercihen bir ay gözlemleyin; tüm gönderim kanallarının bir aylık döngüde görünmesi gerekiyor — kampanya e-postaları, bildirimler, dahili yazışmalar. Raporlarda beklenmedik kaynak görünmüyorsa ve bilinen kaynakların büyük çoğunluğu alignment geçiyorsa bir sonraki adıma geçebilirsiniz.

İkinci aşama karantina modudur. p=quarantine; pct=25 ile başlayın — bu, DMARC fail olan mesajların yalnızca %25'ini karantinaya alır, %75'ini etkilemez. Bu kısmi uygulama, yapılandırmada gözden kaçan bir kaynak varsa tam bir teslim kesintisi yaşanmadan fark etmenizi sağlar. pct değerini zamanla 50, 75, 100'e çıkarın. Raporlarda fail oranı sıfıra yaklaşınca son adıma geçin.

Üçüncü aşama red modudur. p=reject ile domain'iniz adına gönderilen tüm doğrulanamayan mesajlar alıcı sunucu tarafından reddedilir. Bu, e-posta sahteciliğine karşı en güçlü korumadır. Ama bu noktaya gelmeden önce tüm meşru gönderim kaynaklarının alignment sağladığından emin olmanız gerekir; aksi takdirde meşru e-postalar da reddedilir.

Bu geçişin hızı domain'in e-posta altyapısının karmaşıklığına bağlı. Tek bir servis kullanan küçük bir yapıda birkaç haftada tamamlanabilir. Onlarca gönderim kanalı ve karmaşık yönlendirme yapıları olan büyük altyapılarda aylarca sürebilir — ve bu normal. Kademeli geçişin amacı, sistemin her aşamasını anlamadan ilerlememektir.

SPF, DKIM ve DMARC'ı ayrı ayrı doğru yapılandırmak başlangıç noktası. Ama bu üçünü bir sistem olarak anlamak — değerlendirme sırasını, alignment mantığını, birinin başarısızlığının diğerlerine etkisini — teslimatta gerçek güvenceyi sağlayan şey. Raporlar, bu sistemin görünür olmayan katmanlarını yüzeye çıkarır; düzenli okumak, altyapının değişmeye devam ettiği gerçekliğinde yapılandırmanın güncelliğini korumanın tek yolu.