SPF Kaydı Analizi
SPF zincirini include'larıyla açın; 10 DNS sorgu limitini ve politika hatalarını görün.
Bir hedef girin
Örn. example.com — çalıştırmak için ⏎ / ⌘⏎
SPF Kaydı Analizi Nedir?
SPF Kaydı Analizi, kaydınızı okumakla kalmaz; include ve redirect zincirini sonuna kadar açarak RFC 7208 §4.6.4'ün 10 DNS sorgu limitine ne kadar yaklaştığınızı gösterir.
Bu limit pratikte en çok gözden kaçan e-posta arızasıdır: aşıldığında alıcı sunucular PermError üretir ve SPF hiç yokmuş gibi davranır. Kayıt görünürde kusursuz olduğu için sorun genellikle teslimat düşene kadar fark edilmez. Düz bir metin kontrolü bunu göremez; yalnızca özyinelemeli açılım görebilir.
Analiz ayrıca birden fazla SPF kaydı, döngüsel include, var olmayan hedefler (void lookup), önerilmeyen ptr mekanizması ve +all gibi kaydı tamamen işlevsiz kılan hataları da raporlar.
Sık Sorulan Sorular
11 soru10 DNS sorgu limiti tam olarak nedir?
RFC 7208 §4.6.4, SPF değerlendirmesi sırasında include, a, mx, ptr, exists mekanizmaları ve redirect= değiştiricisinin toplam 10 DNS sorgusunu aşmamasını zorunlu kılar. Bu sayı iç içe include'ları da kapsar: kendi kaydınızda 3 include olsa bile, onların içindeki include'lar toplamı 10'un üzerine çıkarabilir.
Limit aşılırsa ne olur?
Alıcı sunucu PermError üretir ve SPF sonucunu "başarısız" değil, "değerlendirilemedi" sayar. Pratikte bu, SPF kaydınız hiç yokmuş gibi davranılması demektir — kayıt görünürde kusursuz olsa bile e-postalarınız SPF ile doğrulanmaz ve DMARC hizalaması SPF üzerinden sağlanamaz.
Sorgu sayısını nasıl düşürürüm?
Üç etkili yöntem: (1) kullanmadığınız sağlayıcıların include'larını silin — en yaygın kazanç budur; (2) mümkün olan yerlerde include yerine doğrudan ip4:/ip6: yazın, çünkü IP mekanizmaları sorgu harcamaz; (3) a ve mx mekanizmalarını, gerçekten gerekli değilse kaldırın.
ip4 ve ip6 mekanizmaları sorgu sayılmıyor mu?
Hayır, saymaz. ip4:, ip6: ve all mekanizmaları DNS sorgusu gerektirmez; istediğiniz kadar ekleyebilirsiniz. Tek sınır kaydın toplam uzunluğudur — 255 karakteri aşan kayıtlar DNS'te birden fazla parçaya bölünür.
-all ile ~all arasındaki fark ne?
-all (hardfail) listelenmemiş göndericinin reddedilmesini ister; ~all (softfail) yalnızca işaretlenmesini. Yeni kurulumda ~all ile başlayıp DMARC raporlarında tüm meşru göndericilerinizin göründüğünü doğruladıktan sonra -all'a geçmek en güvenli yoldur.
İki SPF kaydım var, sorun mu?
Evet, ciddi bir sorun. RFC 7208 §4.5 gereği birden fazla v=spf1 kaydı PermError üretir ve SPF tamamen devre dışı kalır. Tüm mekanizmaları tek bir kayıtta birleştirmeniz gerekir.
Alt alan adları SPF'i miras alır mı?
Hayır. Her gönderen alt alan adının kendi SPF kaydı olmalıdır. Alt alan adından e-posta göndermiyorsanız, o ad için v=spf1 -all yayınlayarak kötüye kullanımı engelleyebilirsiniz.
SPF'i tek başına kullanmak yeterli mi?
Hayır. SPF yalnızca zarftaki (Return-Path) alan adını doğrular; kullanıcının gördüğü From başlığını korumaz. Ayrıca e-posta yönlendirmelerinde (forwarding) doğal olarak kırılır. Bu yüzden DKIM ve DMARC ile birlikte kullanılmalıdır.
E-posta yönlendirmesi SPF'i neden bozar?
Yönlendiren sunucu mesajı kendi IP'sinden yeniden gönderir, ancak Return-Path orijinal alan adında kalır — dolayısıyla SPF eşleşmez. Bu, SPF'in tasarımsal sınırıdır; SRS bu sorunu çözmek için tasarlanmıştır ve DKIM yönlendirmede genelde sağ kalır.
exists ve macro mekanizmaları ne işe yarar?
exists: bir DNS sorgusunun yanıt verip vermediğine göre eşleşme yapar ve %{i} gibi makrolarla gönderen IP'sini ada gömerek dinamik SPF politikaları kurmayı sağlar. Büyük e-posta altyapılarında görülür; küçük kurulumların ihtiyacı yoktur.
Kaydımda ip4 ile include'u karıştırabilir miyim?
Evet, sıra da serbesttir. İyi bir pratik, en sık eşleşen mekanizmaları başa koymaktır — değerlendirme soldan sağa yapılır ve ilk eşleşme sonucu belirler, böylece gereksiz DNS sorgusu yapılmaz.