Untuk menyiapkan DMARC dengan aman, publikasikan catatan pemantauan terlebih dahulu, gunakan laporannya untuk mengautentikasi setiap sumber pengirim yang sah, lalu tingkatkan kebijakan secara bertahap dari tidak ada, karantina, hingga penolakan. Urutannya penting: menerapkan sebelum kode sumber Anda akan memblokir email asli. Dilakukan secara berurutan, Anda mendapatkan perlindungan penuh tanpa mengganggu pengiriman.
Sebelum Anda mulai
DMARC bergantung pada SPF dan DKIM , jadi pastikan keduanya ada terlebih dahulu. SPF ( RFC 7208 ) mencantumkan IP dan layanan yang diizinkan untuk dikirim ke domain Anda dalam data TXT . DKIM menambahkan tanda tangan kriptografi yang diterbitkan sebagai kunci publik di DNS . Anda memerlukan setidaknya satu dari mereka yang lewat dan selaras agar DMARC dapat lewat, dan idealnya keduanya. Perhatikan juga batas pencarian DNS SPF 10: data SPF yang memicu lebih dari sepuluh pencarian DNS gagal, yang kemudian merusak penyelarasan DMARC .
Langkah demi langkah
- 1
1. Publikasikan catatan pemantauan
Tambahkan data TXT di _dmarc dengan v=DMARC1; p=none; rua=mailto:rua@example.com. Ini mengumpulkan data tanpa memengaruhi pengiriman.
- 2
2. Kumpulkan laporan
Tunggu dua hingga empat minggu dan baca laporan agregat ( RUA ) untuk melihat setiap sumber yang dikirimkan sebagai domain Anda.
- 3
3. Otentikasi setiap sumber
Untuk setiap pengirim yang sah, siapkan SPF dan DKIM agar lolos dan selaras dengan domain Dari Anda.
- 4
4. Pindah ke karantina
Ketika surat yang sah lolos secara konsisten, setel p=quarantine, secara opsional gunakan pct untuk meningkatkan secara bertahap.
- 5
5. Pindah untuk menolak
Setelah karantina menunjukkan tidak ada email sah yang gagal, setel p=reject untuk perlindungan penuh.
- 6
6. Terus pantau
Lanjutkan membaca laporan sehingga layanan baru dan penyalahgunaan dapat diketahui lebih awal.
Jalur peluncuran
v=DMARC1; p=none then p=quarantine; pct=50 then p=reject; pct=100
Tangani batas pencarian SPF
Banyak organisasi melampaui batas pencarian DNS SPF 10 karena mereka menambahkan layanan cloud, yang secara diam-diam merusak SPF dan melemahkan DMARC . Meratakan SPF menyelesaikan mekanisme yang disertakan menjadi alamat IP langsung sehingga Anda tetap berada di bawah batas. SmartSPF EmailAuth meratakan data SPF Anda secara otomatis dan terus memperbaruinya saat vendor Anda mengubah IP mereka.
Kesalahan umum
- Melompat ke p=reject sebelum sumber diautentikasi, yang memblokir email asli.
- Melupakan subdomain: tetapkan kebijakan sp atau subdomain mungkin tidak terlindungi.
- Menerbitkan dua data DMARC , yang membuat DMARC tidak valid sepenuhnya.
- Mengabaikan batas pencarian SPF 10, yang merusak penyelarasan SPF dan DMARC .
- Menegakkan dan kemudian tidak pernah memeriksa laporan lagi, sehingga pengirim baru tidak diketahui.
Membuat pengelolaan berkelanjutan menjadi lebih mudah
EmailAuth dapat menghosting data DMARC , SPF , DKIM , dan BIMI melalui delegasi CNAME , sehingga Anda mengarahkan DNS satu kali dan mengelola perubahan kebijakan di dasbor alih-alih mengedit DNS berulang kali. Ini mem-parsing RUA dan RUF untuk Anda dan menandai sumber-sumber yang masih perlu diperbaiki. Untuk melihat titik awal Anda, jalankan pemindaian domain gratis, lalu ikuti jalur bertahap di atas untuk mencapai p=reject.
Pertanyaan yang sering diajukan
Bagaimana cara mengatur DMARC tanpa merusak email?
Mulailah dengan p=none, yang memantau tanpa mempengaruhi pengiriman. Gunakan laporan agregat untuk mengautentikasi setiap pengirim yang sah dengan SPF dan DKIM , lalu pindah ke karantina dan terakhir tolak. Pendekatan bertahap berarti Anda tidak pernah menerapkannya sampai Anda mengonfirmasi surat masuk yang sebenarnya.
Berapa lama saya harus bertahan di p=none?
Cukup lama untuk melihat gambaran lengkap tentang sumber pengiriman Anda, biasanya dua hingga empat minggu untuk sebagian besar organisasi. Jika Anda mengirim melalui banyak layanan atau memiliki pengirim musiman, tunggu lebih lama. Lanjutkan hanya jika laporan Anda menunjukkan semua surat yang sah diteruskan dan diselaraskan.
Berapa batas pencarian DNS SPF 10?
Evaluasi SPF dibatasi pada sepuluh pencarian DNS . Jika penyertaan catatan Anda dan mekanisme lain memicu lebih dari sepuluh, SPF akan mengembalikan permerror dan gagal, sehingga merusak keselarasan DMARC . Meratakan data SPF menjadi IP langsung, misalnya dengan EmailAuth SmartSPF , membuat Anda tetap berada di bawah batas.
Apakah saya memerlukan data DMARC terpisah untuk subdomain?
Belum tentu. Subdomain mewarisi kebijakan domain organisasi kecuali Anda menyetel tag sp atau memublikasikan data khusus di _dmarc.subdomain. Gunakan sp untuk menerapkan kebijakan berbeda pada subdomain, dan lindungi subdomain yang tidak digunakan secara eksplisit sehingga tidak dapat dipalsukan.
[ DMARC memandu ]
Asal perusahaan
Mengapa lembaga keuangan dan pemerintah terkemuka menghentikan dasbor keamanan email mereka.
Platform autentikasi email tradisional menjual dasbor kepada Anda dan meminta teknisi Anda melakukan pekerjaannya. Di lingkungan berisiko tinggi, pengawasan manual berarti penegakan yang tertunda, penyimpangan konfigurasi, dan domain bayangan yang tidak dipantau.
EmailAuth adalah platform asal email agen. Agen kami menegakkan p=reject, jaga agar pengirim pihak ketiga tetap selaras dan pindahkan domain Anda ke kapasitas penuh RFC 9989 kepatuhan, standar DMARC baru, dengan kemampuan audit yang dapat dilakukan secara langsung oleh manusia.
SaaS · Penyewaan khusus · On-prem dengan celah udara · Enkripsi BYOK