SPF / DKIM / DMARC Kontrolü

E‑posta kimlik doğrulaması tamamen DNS’te yaşar; sessizce bozulmasının ve genellikle mailler spam’e düşmeye başlayınca fark edilmesinin sebebi de budur. Bu araç bir alan adının SPF, DKIM ve DMARC kayıtlarını okuyup düzenli biçimde önünüze koyar: ne yayınlanmış, söz dizimi tutuyor mu ve politika gerçekten bir işe yarayacak kadar sıkı mı.

SPF, alan adının kökünde duran tek bir TXT kaydıdır ve o alan adına kimin mail gönderebileceğini listeler; örneğin v=spf1 include:_spf.google.com ip4:203.0.113.10 -all. Alıcı taraf, gönderen sunucuyu bu listeye karşı doğrular ve baktığı adres alıcının gördüğü From: başlığı değil zarf göndericisidir (MAIL FROM). SPF hatalarının çoğu iki ayrıntıdan çıkar. Birincisi sondaki nitelik: -all sert reddir, ~all “muhtemelen biz değiliz ama yine de teslim et” demektir, +all ise hiçbir şey yayınlamamakla aynı kapıya çıkar. İkincisi on DNS sorgusu sınırıdır. include, a, mx, ptr, exists ve redirect mekanizmalarının her biri bu sınıra sayılır; zincir onu aştığı anda kayıt permerror olur ve birçok alıcı bunu SPF hiç yokmuş gibi değerlendirir. Google Workspace, bir CRM, bir yardım masası ve bir pazarlama platformunu üst üste koyduğunuzda sınırı fark etmeden aşarsınız; çözüm kaydı düzleştirmek ya da göndericileri alt alan adlarına dağıtmaktır.

DKIM bir IP’yi yetkilendirmez, mesajın kendisini imzalar. Gönderim platformunuz özel anahtarı tutar, gövdeyi ve seçilmiş başlıkları kapsayan bir DKIM-Signature başlığı ekler, eşleşen açık anahtar da selector._domainkey.alanadiniz.com adresinde yayınlanır. Selector yalnızca bir etikettir — google, k1, s1, mail gibi — ve insanların bulamadığı parça tam olarak budur, çünkü ancak o platformun gerçekten gönderdiği bir mesajın başlıklarında görünür. Kendinize bir test maili atın, ham kaynağı açın; DKIM-Signature satırındaki s= etiketi selector’ü söyler. Anahtar boyu 2048 bit olmalı, 1024 hâlâ kabul ediliyor ama ömrünü tamamlıyor. İmza, mesaj yolda değiştirilirse de bozulur; konu başlığına ön ek ekleyen veya alta imza metni koyan mail listelerinin sizin hatanız olmayan DKIM hataları üretmesinin nedeni budur.

DMARC, bu ikisini alıcının gerçekten gördüğü alan adına bağlayan halkadır. _dmarc.alanadiniz.com altında v=DMARC1; p=none; rua=mailto:rapor@alanadiniz.com gibi yayınlanır ve iki iş yapar: doğrulama başarısız olduğunda ne yapılacağını söyler ve hizalama (alignment) şartı koyar — SPF ya da DKIM’i geçen alan adı, From: başlığındaki alan adıyla eşleşmelidir. İnsanları şaşırtan kısım hizalamadır. Bir mesaj SPF’i tertemiz geçip yine de DMARC’tan kalabilir, çünkü zarf göndericisi bounces@sendgrid.net iken From: başlığında siz@alanadiniz.com yazıyordur. İkisinden yalnızca birinin geçip hizalanması yeterlidir; DKIM’in daha dayanıklı mekanizma olmasının sebebi de budur, çünkü yönlendirmeden (forward) sağ çıkar, SPF çoğu zaman çıkmaz.

DMARC’ı aşamalı yayına alın. Önce p=none yayınlayıp birkaç hafta toplu (aggregate) raporları okuyun; raporlar büyük alıcılardan XML olarak gelir ve alan adınız adına kimin gönderdiğini, hizalanıp hizalanmadığını gösterir. Her zaman kimsenin hatırlamadığı iki üç kaynak çıkar: eski bir fatura sistemi, bir izleme aracı, eski bir sitedeki iletişim formu. Meşru göndericilerin hepsi geçmeye başladıktan sonra p=quarantine’a, ardından p=reject’e geçin. Doğrudan p=reject ile başlamak o unutulmuş sistemleri bulmanın hızlı ama pahalı yoludur. pct= etiketi, raporları izlerken politikayı trafiğin bir kısmına kademeli uygulamanızı sağlar.

Sonuçları okurken: var olan ama ~all ile biten bir SPF kaydı tek başına neredeyse hiçbir şey yapmaz. p=none’daki bir DMARC koruma değil izleme yapılandırmasıdır; sahte mailler yine teslim edilir. Aynı alan adında iki v=spf1 kaydı birleşmez, permerror üretir — ve bu tam olarak birileri ikinci sağlayıcıyı mevcut kaydı düzenlemek yerine yeni bir TXT kaydı açarak eklediğinde olur. DKIM sorgusu ise selector vermeden çalışmaz; boş sonuç genellikle anahtarın olmadığı değil, yanlış selector denendiği anlamına gelir.

Sık tekrarlanan diğer hatalar: DMARC kaydını _dmarc.alanadiniz.com yerine doğrudan alanadiniz.com’a koymak; DNS panelinin alan adını bir kez daha eklemesi sonucu host’un _dmarc.alanadiniz.com.alanadiniz.com hâline gelmesi; sp= yazılmadığı için alt alan adlarının istenmeyen bir politikayı devralması; ve park edilmiş, kullanılmayan alan adlarını SPF -all ile DMARC p=reject olmadan bırakmak — ki bu alan adları tam da kimse izlemediği için spoofing’in favori hedefidir. Bir alan adının mail göndermesi için MX kaydına ihtiyacı olmadığını da unutmayın; ama mail almıyorsa null MX ile sıkı bir SPF yayınlamak koca bir kötüye kullanım kategorisini kapatır.

Bu araç herkese açık DNS’i okur, yani alıcıların görebildiğini gösterir — bir değişiklikten sonra TTL ve resolver önbelleği kadar gecikmeyle. Sonucu bir teslimat denetimi değil ön kontrol olarak görün: kimlik doğrulama gerekli şarttır ama yeterli değildir; IP ve alan adı itibarı, liste hijyeni, şikâyet oranı, içerik ve etkileşim mailin nereye düşeceğini belirlemeye devam eder. Araç BIMI, ARC ve MTA-STS değerlendirmez; gönderdiğiniz belirli bir mesajın doğrulamayı geçip geçmediğini de söyleyemez. Onun için teslim edilmiş bir kopyadaki Authentication-Results başlığına ya da DMARC toplu raporlarınıza bakın.