SPF, DKIM ve DMARC kayıtları nasıl çalışır?

SPF: kim sizin adınıza e-posta gönderebilir?

SPF (Sender Policy Framework, RFC 7208), alan adınızın kök seviyesinde bir TXT kaydı olarak yayınlanır ve hangi sunucuların sizin adınıza e-posta göndermeye yetkili olduğunu listeler. Tipik bir kayıt şöyle görünür: "v=spf1 include:_spf.google.com ip4:203.0.113.10 -all". Burada "include" başka bir sağlayıcının (Google Workspace) yetkili listesini dahil eder, "ip4" belirli bir sunucu IP'sini ekler, "-all" ise listelenmeyen her kaynağın reddedilmesi gerektiğini söyler.

SPF'in en kritik kısıtı, alıcı sunucunun bir kaydı çözerken en fazla 10 DNS aramasına (include, a, mx, ptr, exists mekanizmalarının her biri bir arama sayılır) izin vermesidir; bu sınır aşılırsa kayıt "permerror" (kalıcı hata) döner ve SPF tamamen geçersiz sayılır. SPF Kontrol aracı include zincirini takip ederek bu sayıyı gerçek zamanlı hesaplar ve limite yaklaşıldığında uyarır.

Ayrı bir sınır daha vardır: "void lookup" sayısı, yani NXDOMAIN veya boş cevap dönen aramaların sayısı en fazla 2 olabilir; bu sınır, kötü amaçlı ya da hatalı yapılandırılmış kayıtların alıcı sunucuya aşırı yük bindirmesini önlemek içindir. Kullanılmayan veya artık var olmayan bir sağlayıcıya ait unutulmuş bir "include" satırı, fark etmeden bu limiti doldurabilir ve SPF'i tamamen bozabilir.

• "-all" — listelenmeyenleri reddet (sert, önerilen)
• "~all" — listelenmeyenleri şüpheli işaretle (yumuşak başarısızlık, geçiş dönemi için)
• "+all" — herkese izin ver (pratikte SPF'i işlevsiz kılar, kullanılmamalı)
• "?all" — nötr, hiçbir hüküm vermez

DKIM: e-posta yolda değişti mi?

DKIM (DomainKeys Identified Mail, RFC 6376), gönderilen e-postaya kriptografik bir imza ekler ve bu imzanın doğrulanabileceği ortak anahtarı DNS'e "seçici._domainkey.alanadi" biçiminde bir TXT kaydı olarak yayınlar. Örnek bir kayıt: "v=DKIM1; k=rsa; p=MIGfMA0GCSq...". Buradaki "p=" alanı ortak anahtarın kendisidir; boş bırakılırsa (p=) anahtarın iptal edildiği, artık geçersiz olduğu anlamına gelir.

Anahtar uzunluğu önemlidir: 1024 bit RSA artık zayıf kabul edilir ve çoğu güvenlik aracı uyarı verir, 2048 bit önerilen minimum standarttır, Ed25519 tabanlı anahtarlar (k=ed25519) daha yeni ve daha kısa ama henüz her sağlayıcıda desteklenmiyor. Seçiciyi (selector) bilmiyorsanız -DKIM kaydı domain kökünde değil, seçiciye özel bir alt alan adında durur- DKIM Kontrol aracındaki "yaygın seçicileri dene" özelliği google, selector1, selector2, default, k1, s1 gibi yaklaşık 15 yaygın adı otomatik dener.

Bazı büyük sağlayıcılar (örneğin Microsoft 365) DKIM'i doğrudan bir TXT kaydı yerine bir CNAME zinciriyle devreder: "selector1._domainkey.alanadi" kaydı sağlayıcının kendi alanına işaret eder ve gerçek anahtar orada tutulur. Bu, anahtar rotasyonunu sağlayıcının sizin DNS'inize dokunmadan kendisinin yapabilmesini sağlar; ama sorgu yaparken bu CNAME zincirini takip etmeniz, cevabı doğrudan hedef kayıttan okumanız gerekir.

DMARC: alıcı sahte postayla ne yapmalı?

DMARC (Domain-based Message Authentication, Reporting & Conformance, RFC 7489), SPF ve DKIM'in üstüne kurulan bir politika katmanıdır ve "_dmarc.alanadi" TXT kaydında yayınlanır. Temel görevi, SPF veya DKIM doğrulamasından geçemeyen -ya da alignment denen, "From" başlığıyla eşleşmeyen- postalara alıcı sunucunun ne yapacağını söylemektir: "p=none" sadece izler, hiçbir şeyi engellemez; "p=quarantine" spam'e gönderir; "p=reject" tamamen reddeder.

Örnek bir kayıt: "v=DMARC1; p=quarantine; pct=100; rua=mailto:raporlar@ornek.com; adkim=s; aspf=r". "rua" toplu (aggregate) rapor adresidir ve gönderenlerin sizin adınızı nasıl kullandığını gösteren günlük özet raporları buraya gelir; "pct" politikanın postaların yüzde kaçına uygulanacağını belirler (kademeli geçiş için 100'den düşük başlanabilir); "adkim"/"aspf" sırasıyla DKIM ve SPF için katı (s) veya gevşek (r) hizalama seçer.

"ruf" ise adli (forensic) rapor adresidir ve başarısız olan bireysel postaların örneklerini gönderir; hassas içerik taşıyabileceğinden çoğu büyük alıcı artık ruf'u desteklemiyor veya kısıtlı gönderiyor, bu yüzden çoğu kurulumda sadece rua kullanılır. Alt alan adı için ayrı bir DMARC kaydı yoksa alıcı sunucu otomatik olarak organizasyonel domain'in (örneğin posta.ornek.com yerine ornek.com) DMARC kaydına bakar; bu da tek bir kök kaydın genelde tüm alt alan adlarını kapsamasını sağlar.

Sık yapılan hatalar

Kurulumdan sonra en çok karşılaşılan sorunlar genelde standardın kendisinden değil, aşağıdaki gibi pratik ayrıntılardan kaynaklanır.

• Birden fazla SPF kaydı yayınlamak: RFC 7208'e göre bir alan adında yalnızca tek bir SPF TXT kaydı olmalıdır; ikinci bir kayıt eklemek (birleştirmek yerine) doğrudan permerror'a yol açar.
• SPF kaydını sonlandırmayı unutmak: "all" mekanizması olmayan bir kayıt, listelenmemiş kaynaklar için hiçbir hüküm vermez ve pratikte korumasız kalır.
• DMARC kurmadan doğrudan "p=reject" ile başlamak: rua raporlarını izlemeden sert politikaya geçmek, meşru postaların (örneğin üçüncü taraf pazarlama araçları) reddedilmesine yol açabilir; önce p=none ile raporları izlemek, sonra kademeli sıkılaştırmak önerilir.
• DKIM anahtarını değiştirip eski seçiciyi DNS'ten hemen silmek: geçiş sırasında hem eski hem yeni seçicinin bir süre paralel yayında kalması, henüz eski anahtarla imzalanmış postaların da doğrulanabilmesini sağlar.
• SPF'de "ptr" mekanizmasını kullanmak: RFC 7208 bunu kullanımdan kaldırılmış (deprecated) ilan eder çünkü hem yavaştır hem de ters DNS'e güvenilirlik açısından zayıftır.

Gmail ve Yahoo'nun 2024 toplu gönderen kuralları

Şubat 2024'te Gmail ve Yahoo, günde 5.000'den fazla e-posta gönderen (toplu gönderen) alan adları için kuralları sıkılaştırdı: SPF veya DKIM'den yalnızca birinin geçmesi artık yeterli değil, gönderilen postaların hem SPF hem DKIM ile doğrulanması ve en az birinin "From" başlığıyla hizalı (aligned) olması, yani bir DMARC kaydının bulunması zorunlu hale geldi. Ayrıca spam şikâyet oranının yaklaşık binde 3'ün (%0,3) altında kalması ve pazarlama postalarında tek tıkla abonelikten çıkma desteği isteniyor.

Bu kurallar küçük gönderenleri de dolaylı etkiler çünkü DMARC kaydı olmayan (hatta "p=none" bile olmayan) alan adlarından gelen postalar artık daha kolay spam'e düşüyor. En az bir "_dmarc" TXT kaydı yayınlamak -politika ne kadar gevşek olursa olsun- 2024 sonrası pratik bir asgari hâline geldi; DMARC Kontrol kaydınızın bu asgari şartı karşılayıp karşılamadığını saniyeler içinde gösterir.

"Alignment" (hizalama) kavramı burada kritik hale geldi: SPF'in geçmesi tek başına yeterli değildir, geçen SPF'in kullandığı domain'in de "From" başlığındaki domain ile aynı (katı) ya da aynı organizasyonel domain (gevşek) olması gerekir. Örneğin bir e-posta pazarlama aracı sizin adınıza gönderim yapıyor ama SPF sadece kendi domain'ini doğruluyorsa, bu SPF geçer ama hizalanmaz; DMARC'ın gerçekten "geçmesi" için ya DKIM imzasının From ile hizalanması ya da SPF'in From ile hizalanması gerekir.

Üçünü birlikte test etmek

SPF, DKIM ve DMARC birbirinden bağımsız üç DNS kaydı olduğu için üçünü ayrı ayrı kontrol etmek zaman alır ve MX kayıtlarıyla (hangi sunucuların gerçekten posta aldığıyla) çelişip çelişmediğini gözden kaçırmak kolaydır. Kurulumdan sonra MX Sorgulama ile hangi sağlayıcının posta aldığını doğrulamak, SPF'teki include'ların bu sağlayıcıyla tutarlı olup olmadığını kontrol etmenin en hızlı yoludur.

Tek tek kontrol yerine E-posta Güvenlik Kontrolü aracı MX, SPF (arama sayısıyla birlikte), DKIM (yaygın seçici taraması), DMARC'ı ve ayrıca MTA-STS ile BIMI kayıtlarının varlığını tek raporda ok/uyarı/hata etiketleriyle listeler — bu, üç ayrı sorguyu tek tek çalıştırıp zihninizde birleştirmekten daha güvenilirdir.

Yeni bir e-posta sağlayıcısına geçerken -örneğin şirket postasını Google Workspace'ten Microsoft 365'e taşırken- SPF include'unu güncellemeyi unutmak en sık yapılan hatalardan biridir: eski sağlayıcının include'u DNS'te kalmaya devam eder, yeni sağlayıcının include'u eklenmez ve yeni sunuculardan giden postalar SPF'ten geçemez. Böyle bir geçişte SPF, DKIM ve MX kayıtlarının üçünü birlikte, aynı gün içinde güncellemek ve hemen ardından tek raporla doğrulamak, teslim edilmeyen postalarla uğraşmamanın en pratik yoludur. Geçiş sırasında eski sağlayıcının include'unu hemen kaldırmak yerine birkaç gün her ikisini birden listelemek, henüz eski sunucudan giden kuyruktaki postaların da SPF'ten geçmesini garanti eder.