Soalan dan senario
Sebuah syarikat sedang menyatukan beberapa penyedia e-mel di bawah satu domain penghantaran. Terangkan penjajaran DMARC dan peranan RFC 9989, 9990, dan 9991, kemudian reka bentuk pengesahan dan pengunduran (rollback) daripada p=none kepada reject.
Ini sesuai untuk peranan platform, keselamatan, infrastruktur e-mel, dan diagnosis insiden rentas pasukan. Ia menguji penaakulan protokol dan kawalan pelancaran; ia tidak memerlukan dakwaan bahawa setiap penerima sudah melaksanakan setiap RFC baharu secara serupa.
Perkara yang diuji oleh penemu duga
- Sama ada anda memisahkan peranan dan input SPF, DKIM, dan DMARC.
- Sama ada anda tahu bahawa DMARC memerlukan sekurang-kurangnya satu laluan SPF atau DKIM yang lulus dan sejajar.
- Sama ada anda boleh membezakan DMARC teras RFC 9989, laporan agregat RFC 9990, dan laporan kegagalan RFC 9991.
- Sama ada anda boleh mengetatkan dasar berdasarkan pemerhatian dan bukannya beralih terus kepada
p=reject. - Sama ada anda boleh mengendalikan pemajuan (forwarding), pihak ketiga, subdomain, privasi laporan, dan pengunduran (rollback).
Soalan penjelasan sebelum menjawab
- Adakah identiti yang dilindungi merupakan satu domain organisasi atau beberapa subdomain, dan apakah domain From, Return-Path, dan DKIM d bagi setiap penghantar?
- Bagaimanakah rupa kadar lulus dan penjajaran SPF, DKIM, dan DMARC mengikut penyedia dan subdomain, dan adakah laporan agregat boleh diterima?
- Adakah mesej pemasaran, transaksi, dan pekerja dihantar dari domain yang sama, atau bolehkah ia dipisahkan?
- Adakah tingkah laku penerima telah disahkan melalui ujian dan dokumentasi penyedia, atau adakah kita hanya mengandaikan sokongan piawaian?
Rangka kerja jawapan 30 saat
DMARC menyemak sama ada domain From yang kelihatan sejajar dengan domain SPF yang disahkan atau domain DKIM d; sekurang-kurangnya satu laluan mesti lulus dan sejajar. RFC 9989 mentakrifkan DMARC teras, manakala RFC 9990 dan RFC 9991 mentakrifkan laporan agregat dan kegagalan. Mulakan dengan p=none sebagai mod pemerhatian, huraikan (parse) laporan, baiki penjajaran penyedia, subdomain, dan jenis mesej, kemudian beralih secara beransur-ansur kepada quarantine dan reject. Setiap langkah memerlukan metrik, ujian representatif, dan pengunduran yang pantas. Nombor RFC baharu bukanlah bukti bahawa setiap penerima menghasilkan laporan yang serupa hari ini.
Jawapan mendalam langkah demi langkah
1. Lakarkan tiga laluan identiti
SPF mengesahkan sama ada pelayan penghantar dibenarkan, biasanya menggunakan domain SMTP envelope MAIL FROM. DKIM mengesahkan tandatangan, dengan domain d miliknya mengambil bahagian dalam penjajaran. DMARC menilai domain From yang kelihatan kepada penerima dan menggunakan dasar berdasarkan penjajaran. Input ini berbeza, jadi satu baris Authentication-Results bukan pengganti untuk menyemak domain sebenar.
2. Nilai penjajaran dan bukannya sekadar lulus tanpa penjajaran
Syarat utama DMARC ialah SPF atau DKIM lulus dan domain yang disahkan sejajar dengan From di bawah mod longgar (relaxed) atau ketat (strict) organisasi. Penyedia boleh mempunyai SPF yang lulus sementara envelope-from miliknya tidak sejajar, atau DKIM lulus dengan domain d milik penyedia. Kedua-duanya memerlukan penukaran domain, tandatangan, atau sempadan penghantaran.
3. Terangkan sempadan RFC 2026
RFC 9989 ialah spesifikasi teras DMARC dan menggantikan kedudukan sejarah RFC 7489. RFC 9990 menerangkan laporan agregat untuk taburan sumber jangka panjang, manakala RFC 9991 menerangkan laporan kegagalan. Pastikan “spesifikasi telah diterbitkan” dipisahkan daripada “setiap penerima mengeluarkan laporan yang sama”; sahkan sokongan konkrit dengan ujian dan dokumentasi penyedia.
4. Reka bentuk perubahan dasar secara beransur-ansur
Terbitkan p=none terlebih dahulu dengan destinasi rua yang terkawal dan peti mel atau saluran paip analisis yang dikawal aksesnya. Agregatkan dimensi SPF, DKIM, From, subdomain, dan kegagalan mengikut penghantar, kemudian baiki sumber yang sah. Gunakan sp untuk subdomain yang dicakupkan secara teliti atau pisahkan subdomain transaksi dan pemasaran. Beralih kepada quarantine hanya selepas trafik yang sah stabil dan sumber yang tidak diketahui dapat dijelaskan, kemudian pertimbangkan reject.
5. Letakkan pengesahan dan pengunduran dalam rekod perubahan
Simpan rekod DNS, tetapan penyedia, dan garis dasar laporan sebelum setiap perubahan. Selepas pengetatan, perhatikan penghantaran yang sah, lulus DMARC, kegagalan penjajaran, aduan, dan kelewatan laporan. Uji pemajuan (forwarding), senarai mel, dan lampiran dengan peti masuk sebenar. Jika penghantaran yang sah menurun, undurkan dasar sebelumnya atau sempitkan subdomain terlebih dahulu, kemudian tentukan sama ada perambatan (propagation), penandatanganan DKIM, penulisan semula pemajuan, atau laporan yang hilang menyebabkannya.
Contoh jawapan berkualiti tinggi
Saya akan menginventori domain From, MAIL FROM, dan DKIM d bagi setiap penghantar, kemudian mengira kadar lulus dan penjajaran mengikut penyedia dan subdomain. DMARC tidak memerlukan SPF dan DKIM lulus bersama-sama; satu laluan yang lulus dan sejajar sudah mencukupi. RFC 9989 memegang dasar teras, manakala RFC 9990 dan RFC 9991 merangkumi dua jenis laporan, yang mana liputan penerimanya mesti diukur dan bukannya diandaikan. Saya akan bermula pada p=none, mengumpul laporan agregat, membetulkan isu pihak ketiga, pemajuan, dan subdomain, kemudian mengetatkan segmen yang dicakupkan kepada quarantine sebelum reject. Setiap langkah mendapat ambang untuk penghantaran yang sah, penjajaran, dan sumber yang tidak dapat dijelaskan, serta laluan pengunduran DNS dan pengasingan subdomain. Ini menjadikan perubahan boleh diaudit dan mengehadkan kemudaratan apabila andaian salah.
Kesilapan lazim
- Mengisytiharkan DMARC lulus selepas SPF atau DKIM lulus tanpa menyemak penjajaran domain From.
- Menganggap SPF MAIL FROM, DKIM d, dan From yang kelihatan sebagai medan yang sama.
- Memanggil ketiga-tiga RFC 2026 sebagai “teras DMARC” tanpa memisahkan tanggungjawab laporan.
- Beralih kepada
p=rejecttanpa garis dasar laporan dan menyekat mel pihak ketiga yang sah. - Mengandaikan pemajuan mengekalkan SPF atau DKIM tanpa menguji senarai dan laluan pemajuan.
- Menerbitkan data laporan tanpa mempertimbangkan maklumat alamat dan organisasi dalam laporan tersebut.
Soalan susulan dan respons
SPF lulus tetapi DMARC gagal. Apakah yang anda periksa dahulu?
Bandingkan domain yang disahkan SPF dengan From dan sahkan penjajaran longgar (relaxed) atau ketat (strict). Kemudian periksa pewarisan subdomain, penulisan semula, dan pengepala mesej sebenar; IP penghantaran yang dibenarkan sahaja tidak mencukupi.
DKIM lulus tetapi gagal selepas pemajuan. Apakah langkah seterusnya?
Semak sama ada pemaju (forwarder) menulis semula kandungan atau pengepala yang ditandatangani dan sama ada domain d serta pemilih (selector) masih dapat dihuraikan. Bagi pemajuan yang tidak terkawal, nilaikan penandatanganan yang stabil, pengendalian senarai, dan subdomain yang diasingkan dan bukannya menyembunyikan sumber yang tidak diketahui dengan melemahkan dasar.
Bagaimanakah anda memutuskan untuk beralih daripada quarantine kepada reject?
Gunakan hirisan laporan mengikut penyedia, subdomain, dan jenis mesej untuk menunjukkan penjajaran yang berterusan, dan lengkapkan ujian pemajuan, pemasaran, dan transaksi. Tetapkan ambang untuk penghantaran yang sah, kegagalan penjajaran, aduan, dan sumber yang tidak dapat dijelaskan, dengan tetingkap pengunduran (rollback).
Apakah yang penting apabila alamat laporan berada dalam domain lain?
Sahkan bahawa domain penerima membenarkan hubungan pelaporan secara jelas, dan sekat akses serta pengekalan dalam saluran paip laporan. Pelaporan rentas domain bukanlah eksport data yang dipercayai secara automatik.
Sumber: RFC 9989, RFC 9990, RFC 9991, Google Gmail “Email sender guidelines,” dan Dataford “Explaining Email Authentication Clearly” (URL penuh direkodkan dalam meta.json).