[ DNS ve alanlar ]

E-postayı kabul etmeyen alan adları için boş MX kayıtları

Bir etki alanının, yanlışlıkla gönderemeyeceğini veya alt etki alanlarının bildirimi devraldığını ima etmeden hiçbir e-postayı kabul etmediğini beyan edin.

EmailAuth araştırma ekibi tarafından

[ Anahtar noktalar ]

  • Tek bir MX 0 noktası, bu alan adının posta kabul etmediğini belirtir.
  • MX olmaması ve Boş MX farklı SMTP yönlendirme davranışı vardır.
  • Alma ihtiyaçlarının envanterini çıkarın ve gönderme kontrollerini ayrı ayrı inceleyin.
Bu sayfada

Hayırlı bir alan adı MX kaydı mutlaka postayı reddeden bir alan adı değildir. MX verileri olmadığında SMTP adres arama işlemine geri dönebilir. Bir alan adının e-postayı kabul etmediğini belirtmek ve bu belirsiz geri dönüşten kaçınmak için Null MX mevcuttur.

Açık hizmet dışı yanıtını yayınlayın

Referanslar: RFC 7505 §3.

RFC 7505 Null MX sıfır tercihli ve değişim alanı olarak kök etki alanına sahip tek bir MX kaydı olarak tanımlar: example.com . 300 IN MX 0 .. Nokta anlamlıdır. Bir ana bilgisayar adı için yer tutucu değildir ve yerel ana bilgisayar eşdeğer değildir. Null MX reklamı yapan bir alan adı aynı zamanda başka bir MX kaydının reklamını da yapmamalıdır.

Null MX yalnızca tam olarak bu etki alanındaki hiçbir adresin posta alması gerekmediğini belirledikten sonra kullanın. Hesap kurtarma, satın alma, yasal bildirimler, rol hesapları ve düşük hacimli operasyonel adresleri envantere ekleyin. Görünüşte etkin olmayan bir alan adı hâlâ birisinin kurtarma adresi olabilir.

Alma kontrollerini gönderme kontrollerinden ayırın

Referanslar: RFC 7505 §4.2, RFC 7208 §5.1, RFC 9989 §4.10.1.

Null MX bir alıcı beyanıdır. Giden postanın kimliğini doğrulamaz, bir SPF politika yapın veya bir alanı kimliğe bürünmeye karşı bağışık hale getirin. RFC 7505 alıcılar bu postayı reddedebileceğinden, SMTP MailFrom veya message From adreslerinde kullanılan etki alanlarında Null MX karşı tavsiyede bulunur. Null MX zararsız bir giden ayar olarak ele almak yerine, yasal gönderenler için gözden geçirilmiş bir alma ve iade adresi tasarımı kullanın.

Ne gönderme ne de alma amaçlı bir alan adı için açık giden kontrolleri ayrı bir değişiklik olarak değerlendirin. SPF v=spf1 -all hiçbir gönderenin yetkili olmadığı durumlarda tam SPF kimliğinin açıklayıcı bir reddidir. A DMARC Politika, politika kapsamının, alt alanların ve raporlamanın açık bir değerlendirmesini gerektirir. Gönderim envanteri eksik olan bir alana genel bir kontrol kümesi yapıştırmayın.

Negatif rotayı bilinçli olarak test edin

Referanslar: RFC 5321 §5.1, RFC 7505 §3.

İzole edilmiş bir bölgede A fikstürü noreceive.example . MX 0'DA. ve bir Bir kayıt web sitesi için. Beklenen posta yönlendirmesi, söz konusu web adresine geri dönmek yerine Null MX tanır. Fikstür B'de A kaydı var ancak MX yok; SMTP örtülü MX davranışı farklı bir durumdur. Fikstür C, Null MX sıradan bir değişimle birleştirir ve desteklenen bir yük devretme tasarımı değil, geçersiz bir yapılandırmadır.

Sorgu dig @AUTH noreceive.example . MX +norecurse geçerli her fikstür için ve tam yanıtı saklayın. Null MX durumunun tam olarak amaçlanan tek kaydı döndürdüğünü doğrulayın. Daha sonra, ilgisiz altyapıya istenmeyen trafik göndermeden işlenmesini denetlemek için kontrollü bir SMTP göndericisi kullanın. DNS vakaları buradaki test spesifikasyonlarıdır; gerçek gönderen davranışı yürütmeyi beklemede kalır.

Tam kapsamı onaylayın

Referanslar: RFC 4592 §3.3, RFC 8767 §4.

Boş bir MX example.com otomatik olarak bir MX kaydı değildir sub.example.com. Joker karakter ve yetkilendirilmiş dallar da dahil olmak üzere adları ayrı ayrı test edin. DNS yokluğu, joker karakter sentezi ve açık kayıtlar farklı yollara yol açabilir.

Teslim almama kararını işletme sahibiyle birlikte belgeleyin ve varsa, ikinci bir incelemecinin göndermeme kontrol planını kontrol etmesini sağlayın. Bu kılavuz böyle bir onayın gerçekleştiğini iddia etmemektedir. Gerekli bir adres bulunursa, önbelleğe alınan kayıtlara izin vererek onaylanan DNS sürecine geri dönün. Kapatma, yalnızca başarılı bir DNS kaydına değil, amaçlanan yayınlanmış rotaya ve bağımsız olarak incelenen bir envantere ihtiyaç duyar.

Saklanan arama ve incelenebilir kontrol planı

İncelenen ancak bu inceleme için yeniden çalıştırılmayan, 7 Kasım 2026'ya ait tutulan geçmiş yakalama, sentetik için bir geridöngü yetkili UDP sorgusunun kaydedildiğini kaydeder. noreceive.example MX tam olarak geri döndü 0 .; tutulan yakalama sorguyu, telgraf yanıtını, UTC saatini ve yetki uç noktasını içerir. Ekteki somut göndermeme planı, MX bir SPF ile birleştiriyor -all politikası ve açık bir şekilde meşru posta içermediği varsayılan bir fikstür için açıklayıcı bir DMARC reddetme politikası. Kurtarma adresi ve alt alan adı ön kontrol kontrollerini, raporlama verileri kısıtlamalarını, alıcı testi sınırlarını ve geri alma işlemlerini listeler. Bu planın bağımsız değerlendirmesi, işletme sahibinin onayı değil, bir inceleme kapısıdır. Gerçek müşteri envanteri ve herhangi bir genel dağıtım doğrulanmamış olarak kalır.

Kanıt kapsamını açık tutun

Tarihsel Null MX yanıtı, tel baytları ve geridöngü uç noktasıyla korunur. İlgili göndermeme planı, envanter varsayımları içeren sentetik bir teklif olmaya devam ediyor; ne saklanması ne de bu içerik incelemesi müşteri onayı vermez veya gerçek alıcı kullanımını test etmez.

[ Götürmek ]

Tek bir MX 0 noktası, bu alan adının posta kabul etmediğini belirtir. MX olmaması ve Boş MX farklı SMTP yönlendirme davranışı vardır. Alma ihtiyaçlarının envanterini çıkarın ve gönderme kontrollerini ayrı ayrı inceleyin.

[ Role göre ]

Bu sizin için ne anlama geliyor?

Sonraki pratik adımlar için rolünüzü seçin.

BT / Posta Yöneticisi

Kesin bir rota yayınlayın

Null MX tek MX olmalıdır ve alt alan adlarının kendi değerlendirmeleri olmalıdır.

Sonraki adımlar

  1. Tam olarak bir MX 0 nokta kaydı yayınlayın.
  2. Örtük-MX ve açık-null durumlarını test edin.
  3. İlgili her alt alanı inceleyin.

CISO / SecOps

Göndermeme planını gözden geçirin

Alma beyanı giden kimlik doğrulama kontrollerinin yerini almaz.

Sonraki adımlar

  1. Ayrı alma ve kimliğe bürünme kontrolleri.
  2. Bağımsız olarak incelenen bir gönderme envanteri gerektir.
  3. Politika kapsamını ve istisnaları kaydedin.

Kurucu / Teknik Olmayan

Gözden kaçan alım ihtiyaçlarını kontrol edin

Kurtarma ve düşük hacimli iş adresleri, görünüşte boşta olan bir etki alanını önemli hale getirebilir.

Sonraki adımlar

  1. Envanter kurtarma ve iş adresleri.
  2. Teslim almama kararını onaylayın.
  3. Adlandırılmış bir geri alma sahibini tutun.

[ SSS ]

Sık sorulan sorular

Hiçbir MX Null MX eşdeğer değil mi?

Hayır. MX bulunmaması, SMTP adresinin geri dönmesine izin verebilir.

RFC 5321 §5.1

Tam Null MX değeri nedir?

Tercih 0 ve değişim noktası, MX 0 olarak ifade edilir.

RFC 7505 §3

Yedek bir MX saklayabilir miyim?

Hayır. Null MX söz konusu alan adına ait diğer MX kayıtlarıyla bir arada bulunmamalıdır.

RFC 7505 §3

Null MX giden kimlik sahtekarlığını durdurur mu?

Hayır. Kimlik doğrulama ve etki alanı politikasının gönderilmesi için ayrı kontroller gerekir.

Alan adı hâlâ bir web sitesi barındırabilir mi?

Evet. Null MX , HTTP hizmetiyle değil, posta alımıyla ilgilidir.

RFC 7505 §1

Ebeveyn ayarı alt alan adlarını kapsıyor mu?

Otomatik olarak değil. İlgili her DNS adını ve kayıtlarını kontrol edin.

RFC 4592 §3.3

Önce kurtarma adresleri kontrol edilmeli mi?

Evet. Düşük hacimli operasyonel ve kurtarma hesaplarının gözden kaçırılması kolaydır.

Önerilen göndermeme planı bu kılavuz tarafından onaylandı mı?

Hayır. Bağımsız inceleme ve alan adı sahibinin onayı hâlâ gereklidir.

[ Kaynaklar ]

Kaynaklar

  1. RFC 5321

    Bölümler §5.1

  2. RFC 7505

    Bölümler §1 · §3 · §4.2

  3. RFC 7208

    Bölümler §5.1

  4. RFC 9989

    Bölümler §4.10.1

  5. RFC 8767

    Bölümler §4

  6. RFC 4592

    Bölümler §3.3

[ Sözlük ]

Sözlük

Boş MX
Tercihi sıfır olan ve alan adının posta kabul etmediğini bildiren değişim noktasına sahip tek MX .

RFC 7505 §3

Örtülü MX
Bulunmayan bir MX RRset'in SMTP , o ana bilgisayara işaret eden örtülü bir değişim olarak işlenmesi; açık bir Null MX farklıdır.

RFC 5321 §5.1

Kurumsal menşe

Neden en iyi finans kurumları ve hükümetler e-posta güvenlik kontrol panellerini kullanımdan kaldırdı.

Geleneksel e-posta kimlik doğrulama platformları size bir gösterge tablosu satar ve mühendislerinizden bu işi yapmalarını ister. Riskli ortamlarda, manuel gözetim, gecikmeli uygulama, konfigürasyon kayması ve izlenmeyen gölge alanlar anlamına gelir.

EmailAuth aracılı e-posta kaynak platformudur. Temsilcilerimiz uyguluyor p=reject, üçüncü taraf gönderenleri uyumlu tutun ve alan adlarınızı tam sürüme taşıyın RFC 9989 döngüdeki insan tarafından denetlenebilirliğe sahip yeni DMARC standardı uyumluluğu.

Hükümetler Büyük işletmeler 1. Seviye finans kurumları

SaaS · Özel kiracılık · Şirket içi hava boşluklu · BYOK şifrelemesi

Bilgi Bankası