Wildcard MX dapat membuat subdomain yang sebelumnya tidak dikonfigurasi tampak menerima email. Ini tidak berarti setiap nama di bawah zona tersebut memiliki rute yang sama. Sintesis karakter pengganti DNS bergantung pada apakah ada nama dan pada simpul terlampir terdekat, bukan pada pencocokan teks sederhana di semua subdomain.
Bedakan DNS wildcard dari kotak surat catch -all
Referensi: RFC 4592 §3.3, RFC 5321 §3.3.
Wildcard DNS seperti *.example.com dapat menyediakan data untuk nama-nama tertentu yang tidak ada. Kotak surat catch -all adalah aturan server email tentang bagian lokal mana yang diterima. Keduanya bisa ada tanpa yang lain. Jawaban wildcard MX tidak membuktikan bahwa pertukaran akan menerima anything@sub.example.com, dan kotak surat catch -all tidak dapat memperbaiki rute DNS yang tidak pernah mencapai servernya.
RFC 4592 mendefinisikan perilaku wildcard dalam hal penutup terdekat dan sumber sintesis. Nama yang ada penting meskipun tidak memiliki catatan jenis yang diminta. Jangan berasumsi wildcard MX mengisi tipe MX yang hilang di setiap nama yang sudah memiliki A atau catatan TXT.
Berjalanlah di zona minimal
Referensi: RFC 4592 §2.2.2, RFC 4592 §3.3.1, RFC 5321 §5.1.
Gunakan yang terisolasi example.com zona uji yang berisi *. example.com . DI MX 10 mx.example.com ., sebuah Sebuah rekor pada mx.example.com, dan rekor A di known.example.com. Tanpa nama lain yang relevan, kueri MX untuk missing.example.com dapat mensintesis wildcard MX . Kueri MX untuk yang sudah ada known.example.com tidak memiliki data MX pada nama tersebut dan tidak hanya mewarisi wildcard. SMTP kemudian dapat mengikuti aturan penggantian alamatnya.
Menambahkan leaf.branch.example.com . DI TXT "perlengkapan". Hal ini menciptakan intervensi branch.example.com node meskipun tidak memiliki catatan eksplisitnya sendiri. Kueri MX di bawah cabang tersebut sekarang memiliki simpul terlampir yang lebih dekat. Tanpa wildcard di *.branch.example.com, wildcard apex bukanlah pengganti catch -all . Pertahankan contoh tandingan ini karena ini menjelaskan mengapa dua alamat yang tampak serupa mengambil rute yang berbeda.
Ini adalah hasil sintetik yang diharapkan. Muat zona ke dalam server otoritatif yang terisolasi, tanyakan setiap nama persisnya dan simpan jawaban, otoritas, dan kode respons. Uji keberadaan nama dan ketik ketidakhadiran secara terpisah. Tidak ada eksekusi server langsung yang diklaim oleh contoh-contoh ini.
Audit rute dan kebijakan penerimaannya
Referensi: RFC 1034 §4.3.2.
Cantumkan subdomain sebenarnya, turunan yang didelegasikan, dan pemilik wildcard. Delegasi menciptakan batas kewenangan; wildcard induk bukan pengganti jawaban zona anak. Periksa nama-nama yang tidak ada serta nama-nama yang dikenal, dan lacak nama host MX yang dikembalikan ke alamatnya.
Pada layanan penerima, konfirmasikan domain penerima dan komponen lokal mana yang diterima. Perutean yang tidak terduga dapat memaparkan email operasional ke penyewa atau hasil yang salah hamburan balik jika penolakan tertunda. Uji hanya alamat dan layanan yang Anda kendalikan, dengan konten tidak berbahaya dan penanganan yang diharapkan secara eksplisit.
Ubah kontrol relevan yang paling sempit
Referensi: RFC 7505 §3, RFC 8767 §4.
Jika satu domain tidak menerima email, nilai Null MX eksplisit pada nama tersebut. Jika wildcard tidak diperlukan, menghapusnya dapat mempengaruhi banyak nama yang sebelumnya tidak terlihat. Inventarisasi dependensi tersebut sebelum mengubahnya. Verifikasi penanganan DNS dan penerima setelah perubahan, termasuk jawaban sebelumnya yang di-cache, dan catat dengan tepat rute tak terduga mana yang dihilangkan.
Usahakan ruang lingkup bukti tetap eksplisit
Jalan wildcard adalah ilustrasi hasil yang diharapkan berdasarkan sumber, bukan pengujian DNS otoritatif yang dijalankan. Keberadaan nama dan penutup terdekat harus ditentukan sebelum memilih wildcard; jika sumber kandidat tidak ada, jangan mencari pemilik wildcard yang lebih luas sebagai cadangan.