SPF, DKIM ve DMARC - p=reject’e güvenli geçiş

Herkes bir e-postanın Kimden (From) satırına sizin alan adınızı yazabilir. SPF, DKIM ve DMARC, alıcı sunucunun bir iletinin gerçekten sizden gelip gelmediğini kontrol etmesini ve gelmediyse ne yapacağını bilmesini sağlar. Özenle kurulduklarında, alan adınızın birebir taklit edilmesini çok zorlaştırır. Aceleyle kurulduklarında ise kendi faturalarınızı engelleyebilir.

Her mekanizma ne yapar

SPF (Sender Policy Framework, RFC 7208), bir alan adı adına e-posta göndermesine izin verilen sunucuları listeleyen bir DNS TXT kaydıdır. Alıcı, bağlanan sunucunun IP adresini bu listeyle karşılaştırır. SPF, alıcının gördüğü From adresini değil, zarf göndericisini (MAIL FROM ve HELO kimliklerini) kontrol eder.

DKIM (DomainKeys Identified Mail, RFC 6376), her iletiye kriptografik bir imza ekler. d= etiketi imzalayan alan adını, s= ise seçiciyi (selector) belirtir. Açık anahtar DNS’te selector._domainkey.domain adresinde yayınlanır. Geçerli bir imza, iletinin imzalanan kısımlarının o alan adı imzaladığından beri değişmediğini gösterir.

DMARC ise ikisini de görünen From alan adına bağlar. Gözden geçirilmiş sürümü Mayıs 2026’da, RFC 7489’un yerini alan bir Standards Track belgesi olan RFC 9989 olarak yayımlandı. DMARC kaydı politikanızı belirtir ve alıcılardan size rapor göndermelerini ister.

Gözden kaçan kısım: hizalama

Bir ileti, SPF ya da DKIM başarılı olduğunda ve doğrulanan alan adı From alan adıyla hizalandığında DMARC’tan geçer. Varsayılan olan esnek hizalama, kurumsal alan adı düzeyinde eşleşmeyi kabul eder; yani mail.example.eu, example.eu ile hizalanır. Katı hizalama (adkim=s ya da aspf=s) ise tam eşleşme ister.

İşler genellikle üçüncü taraf göndericilerde ters gider. Bir bülten platformu bounces.platform.example gibi bir zarf alan adı kullanabilir. SPF platformun alan adı için başarılı olur, ancak bu alan adı example.eu ile hizalanmadığı için DMARC sonucunuza hiçbir katkısı olmaz.

Çözüm, platformun DKIM ile d=example.eu kullanarak imzalamasını sağlamak ya da kendi alt alan adlarınızdan biri üzerinde özel bir return-path ayarlamaktır. RFC 9989, alan adı sahiplerinin hem SPF’yi hem de DKIM’i kullanmasını önerir. Böylece biri, örneğin yönlendirme sonrasında başarısız olduğunda diğeri sonucu yine taşıyabilir.

Kayıtlar nasıl görünür

Aşağıdaki örneklerde belgelemeye ayrılmış bir IP adresi ve temsilî bir sağlayıcı kullanılmıştır. Bunları kendi değerlerinizle değiştirin.

example.eu.                    TXT  "v=spf1 include:spf.mail-provider.example ip4:203.0.113.25 ~all"
s2026._domainkey.example.eu.   TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc.example.eu.             TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.eu"

Yukarıdaki DMARC kaydı izleme modundadır. Toplu rapor ister, ancak kontrolden geçemeyen e-postalar için hiçbir işlem talep etmez. Artık RFC 9990’da tanımlanan toplu raporlar, alan adınızı kullanarak hangi sunucuların e-posta gönderdiğini ve bu sunucuların kontrolden geçip geçmediğini gösterir.

DKIM anahtarları için RFC 6376, uzun ömürlü anahtarlarda en az 1024 bitlik RSA anahtarı şart koşar. Google, kişisel Gmail hesaplarına gönderilen e-postalar için en az 1024 bit ister ve sağlayıcınız destekliyorsa 2048 bit önerir.

p=none’dan p=reject’e güvenli geçiş

1. Tüm göndericileri listeleyin. E-posta platformunuzu, CRM’inizi, faturalama ve bordro sistemlerinizi, destek masanızı, web sitesi formlarını ve belge e-postalayan tarayıcılar gibi cihazları ekleyin.
2. Her biri için SPF ve DKIM’i yapılandırın. İzin veren her servisten kendi alan adınız altında DKIM ile imzalamasını isteyin.
3. Bir rua adresiyle p=none yayınlayın. RFC 9989 bunu olağan başlangıç noktası olarak tanımlar; böylece kurulum sırasında gözden kaçırdığınız göndericileri bulabilirsiniz.
4. Raporları okuyun ve eksikleri giderin. Buna en az birkaç hafta ayırın; bordro ya da yıllık hesap özetleri gibi aylık veya üç aylık toplu gönderimleriniz varsa daha uzun.
5. Önce p=quarantine’e, ardından p=reject’e geçin. RFC 9989 eski pct etiketini kaldırdı. Yerini test modu aldı: t=y, alıcılardan politikayı bir kademe hafif uygulamalarını ister; yani p=reject; t=y karantina olarak işlenir.
6. Alt alan adlarını ve park edilmiş alan adlarını da kapsayın. sp etiketi var olan alt alan adlarının politikasını belirler, yeni np etiketi ise var olmayan alt alan adlarını kapsar.

t=y’yi bir garanti değil, bir yumuşatma olarak görün. Hem RFC 7489 hem de RFC 9989, alıcılara tanımadıkları etiketleri yok saymalarını söyler. Bu nedenle yeni spesifikasyonu henüz benimsememiş bir alıcı, yayımladığınız politikayı tam olarak uygulayabilir.

Altıncı adımla ilgili bir not: hiç e-posta göndermeyen bir alan adı bunu açıkça belirtmelidir. Hiçbir sunucuya izin vermeyen bir SPF kaydı ve bir reddetme politikası yayınlayın:

parked-example.eu.                              TXT  "v=spf1 -all"
_dmarc.parked-example.eu.                       TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.eu"
parked-example.eu._report._dmarc.example.eu.    TXT  "v=DMARC1"

Raporlar farklı bir alan adına gittiği için üçüncü kayıt önemlidir. RFC 9990, alıcıların rapor göndermeden önce hedef alan adının o politika alan adı için rapor kabul etmeyi onayladığını kontrol etmesini şart koşar.

Büyük e-posta sağlayıcıları bu çalışmayı zaten bekliyor. Google, 1 Şubat 2024’ten beri toplu göndericilerin (Gmail’e günde 5.000’den fazla ileti gönderenlerin) hizalı SPF, DKIM ve DMARC kullanmasını şart koşuyor. p=none politikası bu asgari şartı karşılar, ancak alan adınızı korumaz.

Sık yapılan hatalar

İki SPF kaydı

Bir alan adı yalnızca bir SPF kaydı yayınlayabilir. Alıcı birden fazla kayıt bulursa SPF sonucu başarılı değil, permerror olur. Yeni bir servis eklediğinizde ikinci bir kayıt oluşturmak yerine o servisin include ifadesini mevcut kayda ekleyin.

Ondan fazla DNS sorgusu

RFC 7208, SPF değerlendirmesini DNS sorgusuna yol açan 10 terimle sınırlar: include, a, mx, ptr, exists ve redirect değiştiricisi. Kendi include’larınızın içindeki iç içe include’lar da sayılır. Sınırı aşarsanız sonuç permerror olur.

ip4, ip6 ve all terimleri sayılmaz; bu yüzden kendi sunucularınızı adresleriyle listelemek işe yarar. Artık kullanmadığınız servislerin include’larını kaldırın. RFC ayrıca cevap döndürmeyen sorguların, yani “boş sorguların” (void lookups) ikiyle sınırlanmasını önerir.

+all ve ?all

all mekanizması her zaman eşleşir; sonucu önündeki niteleyici belirler. Bu yüzden +all internetteki her sunucuya izin verir; asla yayınlamayın. ?all nötr sonuç döndürür ve RFC 7208’e göre bu, hiç SPF sonucu olmamasıyla tamamen aynı şekilde değerlendirilmelidir. ~all (softfail) ya da -all (fail) kullanın.

Peki hangisi? Özgün DMARC spesifikasyonu (RFC 7489, Bölüm 6.7), SPF fail sonucunda iletiyi reddetmenin alıcının DKIM’i değerlendirmesini engellediğini belirtir. Bu da SPF’nin başarısız olduğu ama DKIM imzasının hâlâ geçerli olduğu yönlendirilmiş e-postalara zarar verebilir. DMARC uygulamaya alındıktan sonra ~all, son kararı DMARC’ın vermesine olanak tanır.

Yönlendirmeyi ve e-posta listelerini göz ardı etmek

Yönlendirilen bir ileti, yönlendiren sunucunun IP adresinden gelir ve bu adres SPF kaydınızda yoktur. İleti değiştirilmezse DKIM imzası genellikle yönlendirmeden sağ çıkar. Ancak konu satırını düzenleyen ya da altbilgi ekleyen e-posta listeleri imzayı bozabilir. p=reject’e geçerken kendi alan adınız altında güvenilir DKIM imzalamanın SPF’den daha önemli olmasının nedeni budur.

ptr kullanmak

RFC 7208’e göre ptr mekanizması yayınlanmamalıdır. Yavaştır, daha az güvenilirdir ve yine de sorgu sınırına dahil edilir.

Raporları okumadan uygulamaya almak

Doğrudan p=reject’e geçmek, kendi parola sıfırlama e-postalarınızı, faturalarınızı ya da destek yanıtlarınızı engellemenin kolay bir yoludur. Raporlar hangi göndericileri unuttuğunuzu gösterir. Uygulamaya almadan önce okuyun ve sonrasında da okumaya devam edin, çünkü yeni servisler eklenir.

Nereden başlamalı

• Alan adınızın bugün ne yayınladığını e-posta güvenliği kontrolümüzle görün.
• Kayıtlarınızı SPF ve DMARC oluşturucuyla oluşturun ya da düzenleyin.
• Alan adınız adına e-posta gönderen tüm sistemleri yazın. Uygulamaya geçmeden önce bu listeye ihtiyacınız olacak.
• Şimdi bir rapor adresiyle p=none yayınlayın ve ilk raporları incelemek için bir tarih belirleyin.
• Sahip olduğunuz ve e-posta göndermeyen her alan adına v=spf1 -all ve p=reject içeren bir DMARC kaydı ekleyin.

Rapor analizini ve uygulamaya geçişi başkasına bırakmayı tercih ederseniz yönetilen güvenlik hizmetimiz ikisinde de yardımcı olabilir.