Geçerli SPF, DKIM ve DMARC kayıtları alan adınızın sahteciliğe açık kalmasını engelleyemeyebilir

Dev.to'da yayımlanan (aslen Merlonix blogunda ortaya çıkan) bir yazıya göre, e-posta kimlik doğrulamasını denetlemenin standart yolu yanlış soruyu soruyor. Ücretsiz denetleyicilerin çoğu yalnızca bir alan adında SPF, DKIM ve DMARC kayıtlarının yayımlanmış olup olmadığını doğruluyor. Ancak bu kayıtların her birinin, varlık kontrolüne "yapılandırılmış" gibi görünen ama sahteciliği durdurmak için hiçbir şey yapmayan izin verici bir modu var; dolayısıyla bir alan adı her yerde yeşil görünebilir ve yine de istenildiği gibi taklit edilebilir.

Var olmak, zorunlu kılmak değildir

Dev.to yazısına göre izin verici modların meşru bir gerekçeşi var: işletmecilerin kendi meşru posta trafiğini geri çevirmeden kimlik doğrulamayı kademeli olarak devreye almasını sağlıyorlar. Başarısızlık modu şu: "önce izlemek" ile "tamamlamak", yalnızca varlığa bakan bir araç için aynı görünüyor ve alan adlarının büyük bölümü ilk dağıtımdan sonra yapılandırmayı sıkılaştırmak için geri dönmüyor.

SPF: yalnızca bir niteleyici postayı reddeder

Bir SPF kaydı, all mekanizmasıyla biter ve bu mekanizmanın niteleyicisi, alıcıların listede olmayan sunuculardan gelen postayla ne yapacağını belirler. Yazı dört seçeneği şöyle özetliyor:

• -all (hardfail) yetkisiz sunuculardan gelen postayı reddeder — alan adını fiilen koruyan tek ayardır.
• ~all (softfail) postayı şüpheli olarak işaretler ama yine de teslim edilmesine izin verir; yazıya göre çoğu kayıt bu geçiş aşaması ayarında sıkışıp kalıyor.
• ?all (nötr) hiçbir fikir belirtmez ve bu terimde politika olmamasıyla işlevsel olarak eşdeğerdir.
• +all internetteki herhangi bir sunucunun alan adı adına posta göndermesine izin verir — yazı bunu hiç SPF olmamasından bile kötü olarak nitelendiriyor ve genellikle bir kopyala-yapıştır kazası.

Yazı ayrıca daha az bilinen ikinci bir tuzağa dikkat çekiyor: RFC 7208, SPF değerlendirmesini 10 DNS sorgusuyla sınırlıyor ve bir posta sağlayıcısı — ESP, CRM, destek masası, faturalama aracı — için eklenen her include: girdisi bir veya daha fazla sorgu tüketiyor. Sınır aşılırsa alıcılar PermError döndürüyor ve SPF değerlendirmesini tamamen durduruyor; böylece dün çalışan bir kayıt, DNS'te operatörü uyaran hiçbir şey değişmeden, bir sağlayıcı daha eklendiği gün sessizce çalışmamaya başlayabiliyor.

DMARC: p=none raporlar ama engellemez

DMARC'ın p= etiketi zorunlu kılmayı açıp kapatan anahtardır. p=none, alıcılara kontrol etmelerini, raporlamalarını ve yine de teslim etmelerini söyler; yani sahte posta yine de gelen kutusuna düşer — yazı bunu, yangını söndürmeden sadece algılayan bir duman dedektörüne benzetiyor. p=quarantine başarısız postayı spam'e yönlendirir, p=reject ise doğrudan reddeder; yazı bunu hedef olarak tanımlıyor.

Zorunlu kılıyor gibi görünen bir politikayı sessizce etkisiz kılabilen iki etiket daha var:

• sp=, alt alan adları için politikayı belirler. p=reject içeren ama sp=none içeren bir kayıt, mail., news. veya billing. gibi alt alan adlarını tamamen sahteciliğe açık bırakır ve saldırganlar bunları yoklamayı bilir.
• pct= politikayı yalnızca postaların bir yüzdesine uygular. p=reject; pct=20, beş mesajdan birinde zorunlu kılar, diğer dördünü teslim eder — yazıya göre insanların 100'e geri dönmeyi unuttuğu bir dağıtım kadranı.

DKIM: dışarıdan yapılan kontrolün sınırları var

DKIM her mesajı bir özel anahtarla imzalar ve eşleşen ortak anahtarı DNS'te, göndericinin seçtiği bir selector'dan oluşturulan bir adreste yayımlar. Selector'lar DNS üzerinden numaralandırılamadığı için harici bir denetleyici yalnızca büyük sağlayıcıların kullandığı bilinen selector'ların derlenmiş bir listesini yoklayabilir — Google Workspace google, Microsoft 365 selector1 ve selector2 kullanır. Bir eşleşme kesindir, ama bulunamaması yalnızca yaygın selector'lardan hiçbirinin çözümlenmediği anlamına gelir; özel bir selector'la imzalayan alan adı boş görünecektir. Yazının tavsiyesi, "DKIM: bulunamadı" sonucunu "elle doğrula" olarak okumak, asla alan adında DKIM olmadığının kanıtı saymak değil.

MTA-STS aynı örüntüyü izliyor

Yayımlanmış ile zorunlu kılınmış arasındaki ayrım bir katman aşağıda, gelen posta için transit şifrelemede de karşımıza çıkıyor. MTA-STS (RFC 8461), bir alan adının diğer sunuculara kendisine teslimatta her zaman TLS kullanmalarını söylemesine olanak tanır ama bunu zorunlu kılan yalnızca mode: enforce değeridir — mode: testing durumundaki bir politika, alıcının ne yapacağını raporlar ve postayı yine de düz metin üzerinden teslim eder. Yardımcı kaydı olan TLS-RPT ise hata raporlarını toplar ama kendi başına hiçbir şeyi zorunlu kılmaz.

Neden önemli

E-posta sahteciliği, kimlik avı ve kurumsal e-posta suistimali için hâlâ birincil bir vektördür ve en çok risk altındaki alan adları, kendilerini zaten korunuyor sananlardır. Yazının kapanış kontrol listesi şöyle: SPF'nin -all ile bittiğini ve 10 sorgu sınırının altında kaldığını doğrulayın; DMARC'ın p= değerinin en az quarantine olduğunu, sp= değerinin eşit derecede güçlü olduğunu ve pct= değerinin 100 olduğunu kontrol edin; DKIM'i harici bir yoklamaya güvenmek yerine göndericinizin fiilen kullandığı selector'ı belirleyerek doğrulayın; ve MTA-STS'nin test modunda değil, enforce modunda olduğundan emin olun. Bu ayrımların tümü, dig veya nslookup ve her kaydın niteleyicilerinin dikkatli bir okumasıyla görülebilir — tam da çoğu yalnızca varlığa bakan denetleyicinin atladığı zorunlu kılma ayrıntıları.