Kullanılmayan alan adlarında e-posta sahtekârlığını nasıl durdurursunuz?

Kullanılmayan alan adlarının neden e-posta kayıtlarına ihtiyacı var?

Çünkü herkes alan adınızı bir e-postanın Kimden satırına yazabilir ve kaydı olmayan bir alan adı alıcılara kontrol edecek hiçbir şey vermez. Markanızın yazım hatalı bir varyantı gibi bir savunma alan adı bu nedenle cazip bir hedeftir. Kimlik avcıları varyanttan veya destek adresinize benzeyen bir addan geliyormuş gibi görünen postalar gönderir ve hiçbir politika bulamayan bir alıcı sistemin onu reddetmek için bir dayanağı yoktur.

İki kayıt bu boşluğun büyük kısmını kapatır. SPF, bir alan adı adına gönderebilecek sunucuları listeler; sunucusu olmayan ve sert başarısızlık (hard fail) belirten bir SPF kaydı her göndericiyi reddeder. DMARC, SPF ve DKIM kontrollerini geçemeyen postayla ne yapılacağını alıcılara söyler ve p=reject onlardan bunu reddetmelerini ister. Üçüncü kayıt olan null MX, gönderenlere alan adının posta sunucusu olmadığını bildirir; böylece ona gönderilen bir mesaj günlerce yeniden denenmek yerine hemen başarısız olur.

Wardmint'in savunma amaçlı uzantı listesi bir kripto projesi hangi alan adlarını tescil etmeli yazısındadır. Onlara sahip olduğunuzda bu üç kayıt eklenecek ilk şeydir.

Null MX kaydı (RFC 7505) ne işe yarar?

Null MX, önceliği 0 ve hedefi kök nokta olan tek bir MX kaydıdır ve alan adının e-posta kabul etmediği anlamına gelir. RFC 7505 bunu tanımlar. Exchange sıfır uzunlukta bir etikettir, bölge dosyalarında nokta olarak yazılır ve nokta geçerli bir ana bilgisayar adı olmadığından kayıt gerçek bir posta sunucusuyla karıştırılamaz.

İki kural geçerlidir. Null MX yayımlayan bir alan adı başka hiçbir MX kaydı yayımlamamalıdır. Ayrıca kayıt yalnızca tam olarak bu biçimde bir null MX'tir: öncelik 0, hedef nokta. Bunu gören gönderenler kalıcı bir hatayla hemen başarısız olur; bu, posta döngülerini durdurur ve alan adınızı yanlış yazan dürüst gönderenlerin yeniden deneme kuyruklarını kurtarır.

O olmadan, MX bulamayan bir gönderen alan adının A kaydına başvurur ve teslimatı orada dener; bu daha yavaş ve daha belirsizdir. Null MX bu tahmini ortadan kaldırır.

SPF v=spf1 -all ne anlama gelir?

Hiçbir göndericiyi yetkilendirmeyen bir TXT kaydıdır ve eksi işareti her kontrolün başarısız olmasını sağlar. RFC 7208 bunu tanımlar: v=spf1 sürüm etiketidir ve -all, all mekanizmasının her zaman eşleştiği ve eksi niteleyicisinin fail döndürdüğü tek bir yönergedir. Birlikte, hiçbir ana bilgisayarın bu ad için posta gönderemeyeceğini belirtirler.

RFC 7208, adreslerde kullanılmayan ve posta göndermesi beklenmeyen adlar için bu yaklaşımı önerir. Her savunma alan adının kökünde yayımlayın. SPF, zarf göndericisindeki alan adı veya HELO adı için kontrol edilir; bu yüzden bir sahtekâr hiç yapılandırmadığınız bir alt alan adını da deneyebilir. Alan adı altında kendi kaydı olmayan adlara uygulanan bir joker TXT kaydı bunları kapsayabilir.

example.com.          3600  IN  MX   0 .
example.com.          3600  IN  TXT  "v=spf1 -all"
_dmarc.example.com.   3600  IN  TXT  "v=DMARC1; p=reject; adkim=s; aspf=s"

DMARC p=reject ne ekler?

DMARC politikayı ve raporlamayı ekler: alıcılara başarısız postayı reddetmelerini söyler ve kimin denediğini görmenizi sağlar. RFC 7489, politikayı alan adının _dmarc adında bir TXT kaydı olarak yerleştirir. v etiketi ilk olmalı ve DMARC1 yazmalıdır, p ise politikayı none, quarantine veya reject olarak belirler. sp etiketi alt alan adları için politikayı belirler ve yoksa p onlara uygulanır. adkim ve aspf etiketleri katı veya esnek hizalamayı belirler, rua ise toplu raporlar için adresler verir.

RFC, p=reject'in gücü konusunda dikkatlidir: sahip alıcılardan reddetmelerini ister, alıcılardan azami çaba göstermeleri beklenir ama kesin olarak yükümlü değillerdir. Büyük posta kutusu sağlayıcıları pratikte buna uyar; kaydı yayımlamaya değer kılan da budur.

Girişimleri görmek için okuduğunuz bir posta kutusunda bir raporlama adresi ekleyin, örneğin rua=mailto:[email protected]. Birden fazla savunma alan adı olan bir proje için hepsine tek bir raporlama posta kutusu yeterlidir. Ana alan adınız gibi posta gönderen bir alan adını gerçek göndericilerine uyan bir politikada tutun ve reject'e geçirmeden önce toplu raporları okuyun.

Bir savunma setini korumanın maliyeti nedir?

Wardmint'te üç kayıt için ek ücret yoktur; maliyet alan adlarının kendisidir. Wardmint "e-posta yok" DNS şablonu (null MX, SPF -all, DMARC p=reject) sayesinde savunma amaçlı bir alan adı e-postanızı taklit etmek için kullanılamaz; her varyantı ana sitenize yönlendirmek için ücretsiz URL yönlendirme ve hiçbir varyantın süresi dolmasın diye bakiyenizden otomatik yenileme sağlar.

Wardmint'in 12 Kasım 2026 araştırmasına göre, oltalama setindeki dokuz uzantı (.xyz, .pro, .info, .shop, .online, .icu, .click, .live ve .support) yılda toplam $212.41, üç yılda $637.23 tutar ve her biri e-posta içermeyen şablonu taşıyabilir. .com, .net, .org, .io, .xyz, .app çekirdek seti yılda $128.94 tutar. Setler paket değil, önerilerdir: isimler toplu arama ile en fazla 50 adet olarak sepete eklenir.

Web trafiğini yönlendirmeyen her savunmacı alan adına şablonu uygulayın ve yönlendiren olanlar için URL yönlendirme ile birleştirin. İsimleri seçme yöntemi markanız için savunmacı alan adı listesi nasıl oluşturulur içindedir.