DNS Kontrol ve E-posta Güvenliği Denetimi
DNS, alan adınızı IP adresine çeviren adres defteridir; ama bugün yaptığı iş bundan ibaret değil. Aynı kayıtlar, sizin adınıza kimin e-posta gönderebileceğini, hangi sertifika otoritesinin sertifika üretebileceğini ve DNS yanıtlarınızın araya girilerek değiştirilip değiştirilemeyeceğini de belirler. Bu araç alan adınızın A, AAAA, MX, NS, TXT, CAA ve SOA kayıtlarını çözümler; ardından SPF, DMARC ve DNSSEC yapılandırmanızı yalnız "var/yok" diye değil, gerçekte ne kadar koruma sağladığı açısından değerlendirir.
Kayıt dökmek yetmez, kaydın ne söylediği önemli
Çoğu DNS sorgulama aracı kayıtlarınızı listeler ve orada durur. Oysa bir SPF kaydının varlığı tek başına hiçbir şey ifade etmez: kayıt on DNS sorgusu sınırını aşıyorsa alıcı sunucular onu geçersiz sayar ve hiç yokmuş gibi davranır. Aynı şekilde bir DMARC kaydınız olabilir ama politikanız p=none ise alıcıya "hiçbir şey yapma" demiş olursunuz; sahte e-posta yine teslim edilir. Bu araç kayıtları listelemekle kalmaz, her birinin pratikte hangi koruma seviyesine karşılık geldiğini söyler.
SPF ve on sorgu sınırı
SPF kaydı, sizin adınıza e-posta göndermeye yetkili sunucuları bildirir. Kaydın içindeki include, a, mx, ptr, exists ve redirect ifadelerinin her biri alıcı sunucuda ek bir DNS sorgusu doğurur ve RFC 7208 bu sorguların toplamını onla sınırlar. Sınır aşıldığında sonuç "permerror" olur: SPF değerlendirmesi başarısız sayılır ve kaydınız sessizce devre dışı kalır. Bu, birden çok pazarlama aracı, CRM ve fatura sistemi ekleyen şirketlerde çok sık görülen ve fark edilmesi zor bir arızadır. Kaydın sonundaki işaret de belirleyicidir: -all listelenmemiş sunuculardan gelen postanın reddedilmesini, ~all işaretlenip geçirilmesini ister. Yaygın öneri ~all'dır, çünkü SMTP düzeyinde reddetmek yerine DKIM ve DMARC değerlendirmesine imkân verir. +all ise SPF'i tamamen anlamsız kılar.
DMARC: kaydın olması korunduğunuz anlamına gelmez
SPF ve DKIM, e-postanın yetkili bir sunucudan geldiğini ve yolda değiştirilmediğini doğrular. Ancak ikisi de, kullanıcının gördüğü "Kimden" adresiyle doğrulanan alan adının aynı olmasını şart koşmaz. Bu hizalamayı kuran ve alıcıya doğrulama başarısız olduğunda ne yapacağını söyleyen mekanizma DMARC'tır. Politikanın üç kademesi vardır: p=none yalnızca izler ve hiçbir koruma sağlamaz, p=quarantine doğrulanmayan postayı spam klasörüne yönlendirir, p=reject ise reddettirir. Yaygın hata, kaydı kurup p=none aşamasında bırakmaktır; bu durumda raporlar toplanır ama alan adınız adına gönderilen sahte e-postalar hedefine ulaşmaya devam eder. rua= etiketiyle rapor adresi tanımlamak da kritiktir: raporlar olmadan hangi meşru sistemlerin sizin adınıza gönderim yaptığını göremez, politikayı güvenle sıkılaştıramazsınız.
DNSSEC ve 2026'da değişen sertifika kuralı
DNSSEC, DNS yanıtlarını kriptografik olarak imzalayarak araya girip sahte adres döndürme saldırılarını engeller. Uzun süre isteğe bağlı bir iyileştirme olarak görüldü, ancak sertifika ekosisteminde konumu değişti: Mart 2026'dan itibaren yürürlüğe giren düzenlemeyle sertifika otoriteleri, alan adı doğrulaması ve CAA sorgularında DNSSEC doğrulaması yapmakla yükümlü. Bu, DNSSEC'i zorunlu kılmıyor; ancak imzalı bir bölgeniz varsa sertifika üretim süreci de kriptografik güvenceye bağlanıyor. Alan adı sağlayıcınız destekliyorsa DNSSEC'i açmak, hem çözümleme hem sertifika tarafında somut bir kazanç sağlar.
CAA: sertifikayı kimin verebileceğini siz belirleyin
CAA kaydı, alan adınız için hangi sertifika otoritesinin sertifika üretebileceğini sınırlar. Kayıt yoksa varsayılan davranış şudur: herhangi bir otorite, alan adınız için sertifika verebilir. Bu, alan adı doğrulamasını atlatabilen bir saldırganın sizin adınıza geçerli görünen bir sertifika elde etmesi riskini açık bırakır. Tek satırlık bir DNS kaydıyla üretimi kullandığınız otoriteyle sınırlamak, maliyeti sıfıra yakın ve etkisi doğrudan bir önlemdir.
Ad sunucusu yedekliliği neden ölçülür?
Alan adınızın çözümlenmesi ad sunucularına bağlıdır. Tek bir ad sunucusu tanımlıysa o sunucu erişilemez olduğunda siteniz sapasağlam ayakta olsa bile alan adınız çözümlenemez ve ziyaretçi siteye ulaşamaz. RFC 2182 bu nedenle en az iki ad sunucusu ister; sunucuların farklı ağlara ve tercihen farklı coğrafyalara dağıtılması riski daha da düşürür. Bu araç ad sunucusu sayısını ve bunların aynı alan adı altında toplanıp toplanmadığını raporlar.
Sorularla
Sıkça Sorulan Sorular
SPF, DKIM ve DMARC arasındaki fark ne?
SPF, sizin adınıza hangi sunucuların gönderim yapabileceğini bildirir. DKIM, e-postayı kriptografik imzayla mühürleyerek yolda değiştirilmediğini kanıtlar. DMARC ise bu ikisinin sonucunu, kullanıcının gördüğü gönderen adresiyle hizalar ve doğrulama başarısız olduğunda alıcının ne yapacağını söyler. Üçü birlikte çalışır; yalnız SPF kurmak alan adınızı spoofing'e karşı korumaz.
DMARC kaydım var ama yine de sahte e-posta gidiyor, neden?
Büyük olasılıkla politikanız p=none. Bu ayar alıcı sunuculara yalnızca rapor göndermelerini, aksi bir işlem yapmamalarını söyler; doğrulanmayan e-postalar teslim edilmeye devam eder. Koruma p=quarantine ile başlar, p=reject ile tamamlanır. Geçişi raporları inceleyerek kademeli yapın, aksi halde meşru gönderimleriniz de engellenebilir.
SPF kaydımda kaç sorgu olduğunu neden önemsemeliyim?
RFC 7208, SPF değerlendirmesinde yapılacak DNS sorgusu sayısını onla sınırlar. include, a, mx, ptr, exists ve redirect ifadelerinin her biri bu sayıya eklenir. Sınır aşıldığında sonuç "permerror" olur ve SPF hiç tanımlanmamış gibi işlem görür — üstelik bu, hiçbir hata mesajı görmediğiniz için fark edilmesi güç bir arızadır.
DNSSEC açmak sitemi yavaşlatır mı?
Pratikte fark edilir bir yavaşlama beklenmez. DNSSEC doğrulaması çözümleyici tarafında yapılır ve yanıt boyutunu bir miktar büyütür. Asıl dikkat edilmesi gereken nokta hız değil, yapılandırma disiplinidir: anahtar yenilemesi hatalı yapılırsa alan adı tamamen çözümlenemez hale gelebilir. Alan adı sağlayıcınız DNSSEC'i kendi yönetiyorsa risk büyük ölçüde ortadan kalkar.
CAA kaydı sertifikamı otomatik yeniler mi?
Hayır. CAA yalnızca hangi sertifika otoritesinin sertifika ÜRETEBİLECEĞİNİ sınırlar; yenileme işlemini yapmaz. Kayıt tanımlıysa listelenmeyen bir otorite sertifika talebini reddetmek zorundadır. Yenileme, sertifika sağlayıcınızın veya sunucunuzdaki otomasyonun işidir.
MX kaydım yok, SPF ve DMARC yine de gerekli mi?
Evet. MX kaydı e-posta ALMAYLA ilgilidir; SPF ve DMARC ise sizin adınıza GÖNDERİLEN e-postalarla. Hiç e-posta almayan bir alan adı bile, kimlik avı kampanyalarında gönderen adresi olarak kullanılabilir. Gönderim yapmayan alan adları için katı bir SPF ve p=reject DMARC tanımlamak, alan adınızın kötüye kullanılmasını engeller.
Bu araç DNS yayılımını (propagation) ölçüyor mu?
Hayır. Bu denetim, kayıtlarınızın güncel durumunu ve güvenlik yapılandırmasını değerlendirir; dünyanın farklı noktalarındaki çözümleyicilerde değişikliğin ne kadar yayıldığını ölçmez. Yayılım, DNS kaydını yeni değiştirdiyseniz ve TTL süresi dolmadıysa anlamlı bir sorudur; kalıcı yapılandırma denetiminde ise kayıtların içeriği belirleyicidir.