Bir gözlemle başlayalım: Denetlediğimiz kurumların çoğunun tek bir mail alan adı değil, onlarcası vardır — eski markalar, kampanya alan adları, satın alınıp park edilmiş domainler, yalnızca yönlendirme için tutulan adresler. Bunların büyük bölümü ne mail gönderir ne de alır. Sorun şu: DNS bunu bilmez. Ve bilmeyen her alan adı, saldırgan için sessiz bir yem, teslim edilemeyen postalar için de bir kara delik olur.
RFC 7505 tam olarak bu boşluğu kapatır. Kısa, 2015 tarihli ama az bilinen bir Standards Track belgesidir ve tek bir şey söyler: bir alan adının hiç e-posta kabul etmediğini DNS üzerinden açıkça ilan etmenin standart yolu. Adı "null MX"tir.
1. Sorun: MX Yoksa Sistem Tahmin Eder
Bir gönderici sunucu (MTA) ornek.com alan adına mail teslim etmek istediğinde, RFC 5321'in tarif ettiği sırayı izler: önce MX kaydına bakar. MX yoksa, geri düşüş (fallback) olarak alan adının A/AAAA kaydına bakar ve o IP'yi mail sunucusu sayar.
İşte tuzak burada. Alan adınızın bir web sitesi var diye A kaydı vardır — ama o adreste SMTP dinleyen bir sunucu yoktur. Gönderici bunu baştan bilemez; bağlanmayı dener, zaman aşımına uğrar, tekrar dener… ve bu döngü tipik olarak bir hafta sürer. Sonuç: yanlış yazılmış bir adrese giden mailin sahibine "teslim edilemedi" bildirimi günler sonra döner; gönderici tarafında ise boşa kuyruk ve kaynak tüketimi birikir.
2. Çözüm: MX 0 .
Null MX, alan adının mail kabul etmediğini tek bir kayıtla, kesin biçimde ilan eder. Bir tek MX kaydı yayınlarsınız; tercih numarası 0, hedef (exchange) alanı ise tek bir nokta — yani boş etiket:
ornek.com. IN MX 0 .
"." geçerli bir konak adı olmadığı için bu kayıt sıradan bir MX ile karıştırılamaz; anlamı nettir: "burada mail sunucusu yok." Kural katıdır — null MX yayınlayan alan adı başka hiçbir MX kaydı yayınlamamalıdır (RFC 7505: MUST NOT). Bu yaklaşım, SRV kayıtlarındaki "hizmet yok" anlamına gelen aynı "." kullanımından modellenmiştir.
Etkisi anında hissedilir: gönderici, ilk denemede teslimatın kalıcı olarak başarısız olduğunu görür. Kuyruk yok, bir haftalık tekrar denemesi yok, geciken bildirim yok.
3. Standart Hata Kodları: 556 ve 550
Null MX yalnızca bir davranış değil, IANA'ya kayıtlı yeni durum kodları da getirir. Bunları raporlarda veya reddedilen postaların günlüklerinde görürseniz artık ne anlama geldiklerini bilirsiniz:
- Alıcı tarafı (birine null MX'li adrese yazdınız):
556temel kodu +5.1.10genişletilmiş kod — "Recipient address has null MX". - Gönderen tarafı (size null MX'li bir zarf adresinden mail geldi):
550+5.7.27— "Sender address has null MX". Alıcı, dönüş adresi geçersiz olduğu için bu postayı reddedebilir.
4. Kritik Uyarı: Gönderdiğiniz Alana Null MX Koymayın
Null MX, yalnızca ne alan ne gönderen alan adları içindir. RFC 7505 açıkça uyarır: bir mail sistemi, MAIL FROM (zarf-dönüş) veya From: adreslerinde kullandığı alan adları için null MX yayınlamamalıdır. Çünkü birçok alıcı sistem, dönüş adresi geçersiz olan postayı spam sayıp reddeder — kendi giden postanızı sabote edersiniz.
Basit kural: mail gönderen alan adına null MX değil, düzgün bir MX/SPF/DKIM/DMARC yapılandırması gerekir. Null MX, kenarda duran sessiz alan adları içindir.
5. Üçlü Mühür: Null MX + SPF -all + DMARC
Null MX tek başına "almıyorum" der. Ama saldırgan zaten sizin alan adınıza mail göndermek değil, sizin alan adınız adına mail göndermek ister. Bu yüzden mail göndermeyen bir alan adını üç yönden birden mühürlemek gerekir:
- Null MX — "bu alan mail kabul etmiyor" (
MX 0 .). - SPF
-all— "bu alan hiç mail göndermiyor":v=spf1 -all. RFC 7505 bunu doğrudan önerir; göndermeyen alanların açık deklarasyonudur. - DMARC
p=reject— "adıma sahte mail görürseniz reddedin":v=DMARC1; p=reject; rua=mailto:....
Bu üçü birlikte, park edilmiş bir alan adını hem "almıyorum" hem "göndermiyorum" hem "taklidimi reddedin" diye üç ayrı dilde ilan eder. Kimlik doğrulama katmanının bütününü SPF, DKIM, DMARC kurulum rehberimizde adım adım ele alıyoruz.
6. DMARCbis Bağlantısı: np Etiketi
Mayıs 2026'da yayınlanan yeni DMARC standardı (RFC 9989, RFC 7489'un yerini alır) bu resmi tamamlayan bir etiket getirdi: np — non-existent domain policy, yani var olmayan alt alan adları için politika. Bir organizasyon, hiç kullanılmayan alt alanlardan (örn. fatura.ornek.com gibi hiç oluşturulmamış adlar) gelen sahte postaların doğrudan reddedilmesini np=reject ile isteyebilir.
Yani tablo şöyle tamamlanıyor: null MX mevcut ama mail almayan alan adlarını, SPF -all göndermeyeni, DMARC p=reject ana alan taklidini, DMARCbis np=reject ise hiç var olmayan alt alan taklidini kapatır. Dört katman, tek amaç: kimsenin sizin adınıza konuşamaması.
7. Neden Şimdi Önemli: AI Çağında Sessiz Alan Adları
Bu konunun "az bilinen" olması, önemsiz olduğu anlamına gelmiyor — tam tersi. Somut sayılarla konuşalım: Google Trends'in Ocak 2024–Ağustos 2026 dünya geneli verisinde yükselen aramalar arasında "brand impersonation" (marka taklidi) %450, "ai impersonation" %2.000 ve "ai voice impersonation" %800 arttı. Saldırganlar artık ikna edici sahte içerikleri saniyeler içinde üretiyor ve gönderecek bir "meşru görünümlü" alan adı arıyor.
Kurumların unuttuğu park alan adları tam da bu iş için biçilmiş kaftandır: kimse izlemez, kimse denetlemez, DNS'te hiçbir "hayır" yazmaz. Kullanmadığınız her alan adını null MX + SPF -all + DMARC p=reject ile kapatmak, saldırı yüzeyinizi sessizce daraltmanın en ucuz yoludur. Yalnız unutmayın: kimlik doğrulama alan adınızın birebir taklidini durdurur; benzer görünen (look-alike) alan adları ve ele geçirilmiş gerçek hesaplar için davranışsal analiz katmanı gerekir.
8. Güvenlik ve Doğrulama
Null MX, DNS içinde sıradan bir MX kaydıdır; yeni bir güvenlik riski getirmez ve istenirse diğer tüm kayıtlar gibi DNSSEC ile imzalanabilir. Aslında park alan adlarında DNSSEC ihmal edilmemeli: null MX, SPF -all ve DMARC p=reject kayıtlarınız yolda değiştirilirse verdiğiniz tüm "hayır"lar sessizce etkisizleşir. Yayınladıktan sonra doğrulaması basittir: alan adınızın MX kaydını sorgulayın, tek satırda 0 . görüyorsanız iş tamamdır.
Onlarca alan adınız varsa hepsini tek tek elle kontrol etmek zahmetlidir. mailskop.com ile bir alan adının MX, SPF, DKIM, DMARC ve BIMI karnesini saniyeler içinde çıkarabilir; park alan adlarınızın gerçekten mühürlenip mühürlenmediğini görebilirsiniz. Motor Kinetik Bilişim tarafından geliştirildi ve ücretsizdir.
Sıkça Sorulan Sorular
Null MX nedir?
Bir alan adının hiç e-posta kabul etmediğini DNS üzerinden ilan eden özel bir MX kaydıdır: tercih 0 ve boş "." hedefi (MX 0 .). RFC 7505 ile tanımlanmıştır.
Null MX nasıl yayınlanır?
DNS'e ornek.com. IN MX 0 . kaydını eklersiniz ve o alan adında başka hiçbir MX kaydı bırakmazsınız.
Null MX ile SPF -all arasındaki fark nedir?
Null MX "mail almıyorum" der; SPF -all "mail göndermiyorum" der. Mail almayan ve göndermeyen alan adlarında ikisi birlikte kullanılır.
Mail gönderdiğim alan adına null MX koyabilir miyim?
Hayır. RFC 7505, MAIL FROM veya From: adreslerinde kullandığınız alan adlarına null MX koymamanızı önerir; postanız reddedilebilir.
5.7.27 hata kodu ne demek?
"Sender address has null MX" — gönderenin zarf alan adı null MX yayınladığı için alıcı sunucu postayı reddetti. Alıcı taraftaki karşılığı 556 + 5.1.10'dur.
Şimdi Ne Yapmalı?
On dakikanız varsa: kurumunuzun sahip olduğu tüm alan adlarını listeleyin ve mail göndermeyenleri işaretleyin. Her biri için MX, SPF ve DMARC kayıtlarına bakın — kaçında hiçbir "hayır" yok? Cevap sizi rahatsız ettiyse:
- Ücretsiz Saha Denetimi: Tüm alan adlarınızın (aktif + park) SPF/DKIM/DMARC/MX karnesi, null MX eksikleri ve look-alike domain riskiyle birlikte raporlanır.
- Yönetilen geçiş: Aktif alan adlarında SPF/DKIM/DMARC yönetimi, park alan adlarında null MX +
-all+p=rejectmühürlemesi; hepsi tek yol haritasıyla.
Bu yazı hakkında: Mail Teknolojileri Serimizin bir parçasıdır ve SPF, DKIM, DMARC rehberimizi tamamlar. Kinetik Bilişim, Check Point Software Technologies'in Advanced Partner 2026 seviyesindeki Türkiye iş ortağıdır; Email, Endpoint & Browser, Mobile ve SASE Solution Specialization akreditasyonlarına sahiptir. Yazar Kemal Özleyen, Check Point Workspace Security Expert sertifikalı bir siber güvenlik mühendisidir.
