Platform pemasaran bank bisa lolos DMARC secara konsisten ketika layanan kode otentikasi kecil gagal. Persentase agregat menyembunyikan ketidakmampuan pelanggan untuk masuk. Inventarisasi pemberitahuan penting berdasarkan tujuan dan konsekuensi operasional sebelum menggunakan kesehatan email secara keseluruhan untuk menilai kesiapan.
Bedakan tiga janji layanan
Pesan kode autentikasi memiliki siklus kedaluwarsa dan coba lagi yang dikontrol oleh layanan identitas. Peringatan penipuan mungkin memerlukan perhatian tepat waktu melalui alur kerja kontak yang disetujui. Pemberitahuan akun mungkin tidak terlalu cepat namun tetap membawa informasi penting. Untuk masing-masingnya, dokumentasikan pemicunya, pemilik aplikasi, perkiraan waktu, jalur akses alternatif, dan tim eskalasi.
Jangan menjadikan inventaris ini sebagai dukungan email sebagai faktor otentikasi untuk transaksi perbankan tertentu. Kesesuaian kode email bergantung pada desain keamanan yang disetujui institusi dan persyaratan yang berlaku. DMARC melindungi penilaian identitas domain; hal ini tidak dapat membuat proses pemulihan yang lemah atau pilihan faktor yang tidak aman dapat diterima.
Periksa rute yang benar-benar mengeluarkan kode
Catat domain Dari, identitas amplop, DKIM penandatangan, pemilih, penyewa aplikasi dan lingkungan untuk layanan identitas. Pastikan konfigurasi pengujian, pementasan, dan produksi dipisahkan dengan jelas. Pengujian yang berhasil melalui kotak surat pengembang tidak menjelaskan apa pun tentang pekerja pemberitahuan produksi jika menggunakan penyedia lain.
Untuk peringatan penipuan, catat pengirim yang membuat peringatan tersebut dan saluran yang digunakan pelanggan untuk memverifikasinya secara independen. Hindari mengajari pelanggan untuk memercayai suatu pesan hanya karena pesan tersebut tampak bermerek atau diautentikasi. Pemberitahuan akun mungkin menggunakan pemroses batch dengan perilaku penandatanganan dan percobaan ulang yang berbeda; sertakan secara eksplisit daripada mewarisi hasil layanan kode.
Ukur latensi tanpa mengklaim lebih dari yang ditunjukkan jam
Tangkap waktu pemicu, waktu pengiriman penyedia, penerimaan jarak jauh jika tersedia, dan waktu observasi kotak surat terkontrol. Catat zona waktu dan ketidakpastian jam. Bandingkan tahapan ini dengan target layanan yang disetujui oleh institusi; tidak ada ambang batas waktu pengiriman universal yang diberikan di sini. Interval pelaporan agregat tidak dapat mengukur waktu kedatangan kode tertentu.
Gunakan kode sintetis yang tidak dapat diautentikasi ke akun nyata mana pun. Jangan pernah mengumpulkan kode yang dapat digunakan dalam tangkapan layar atau diagnostik yang dapat diakses secara luas. Uji perilaku kode kedaluwarsa, pengiriman tertunda, dan permintaan berulang di lingkungan non-produksi yang disetujui. Kode yang terlambat dapat diautentikasi dengan sempurna pada lapisan email, namun gagal pada lapisan aplikasi karena telah kedaluwarsa.
Tetapkan pemulihan sebelum pengetatan kebijakan
Pemilik identitas harus menentukan bagaimana pengguna mendapatkan kembali akses ketika email gagal, sementara operasi penipuan harus menentukan bagaimana pelanggan dapat memverifikasi peringatan melalui jalur tepercaya. Tim surat mendiagnosis identitas pengirim dan bukti penerima. Hindari penindasan otomatis terhadap pemberitahuan keamanan penting hanya untuk meningkatkan persentase autentikasi.
Memerlukan pengujian yang representatif untuk setiap rute kritis dan pemilik yang disebutkan untuk setiap celah. Pada peta lokal di bawah, penandatangan pemberitahuan akun ditetapkan tidak sejajar sedangkan kode dan penandatangan penipuan sama persis. Ini adalah perbedaan pelatihan, bukan pengukuran bank. Periksa kembali setelah failover penyedia, perubahan platform identitas, rotasi pemilih, dan perubahan pada masa pakai kode atau perilaku coba lagi. Pisahkan otoritas rollback yang terdokumentasi dari kemampuan teknis untuk mengubah DNS .
Kerjakan tiga catatan rute tertulis
Contoh domain, penyeleksi, peran, dan lokasi DKIM yang dicadangkan ini bersifat fiktif. Tidak ada pesan bertanda tangan, kunci, verifikasi kriptografi, pencarian DNS , transaksi SMTP , atau pengujian layanan langsung yang diberikan atau dijalankan untuk kasus ini. Tidak diperlukan kode pengujian atau spesimen eksternal untuk memeriksa alasan di bawah ini.
- kode otentikasi: terlihat Dari codes.bank.example domain.bank.example; DKIM d=codes.bank.example; demo pemilih1; menganggap DKIM lulus hanya untuk kasus tertulis ini. SPF KIRIM DARI identitas dan hasil tidak diketahui; tanda tangan lainnya tidak diketahui; penemuan dan penyampaian kebijakan sebenarnya tidak diketahui. Pemilik yang diusulkan: Pemilik layanan identitas. Tindakan selanjutnya: Dapatkan sampel resmi dan hasil penerima tepercaya untuk penyewa ini.
- peringatan penipuan: terlihat Dari domain fraud.bank.example ; DKIM d=fraud.bank.example; demo pemilih2; menganggap DKIM lulus hanya untuk kasus tertulis ini. SPF MAIL DARI identitas dan hasil tidak diketahui; tanda tangan lainnya tidak diketahui; penemuan dan penyampaian kebijakan sebenarnya tidak diketahui. Pemilik yang diusulkan: Pemilik operasi penipuan. Tindakan selanjutnya: Konfirmasikan rute terpisah ini dan peristiwa bisnisnya daripada mewarisi hasil rute pertama.
- pemberitahuan akun: terlihat Dari domain accounts.bank.example ; DKIM d=provider.example.net; demo pemilih3; menganggap DKIM lulus hanya untuk kasus tertulis ini. SPF MAIL DARI identitas dan hasil tidak diketahui; tanda tangan lainnya tidak diketahui; penemuan dan penyampaian kebijakan sebenarnya tidak diketahui. Pemilik yang diusulkan: Pemilik layanan akun. Tindakan selanjutnya: Tanyakan kepada pemasok terverifikasi tentang jalur penandatanganan selaras yang didukung penyewa ini; tidak memperluas otorisasi ke seluruh jaringannya.
Untuk dua tanda tangan pertama yang ditetapkan, d= sama persis dengan domain Dari, sehingga pengidentifikasinya memenuhi persyaratan ketat dan santai penyelarasan. Mengingat keberhasilan hasil DKIM yang ditetapkan, terdapat jalur autentikasi yang selaras untuk pesan hipotetis tersebut. Penanda tangan ketiga sengaja tidak terkait dengan domain penulis dan tidak dapat menyediakan jalur yang selaras tersebut. Jangan menyebut pesan ketiga sebagai kegagalan DMARC : SPF yang selaras atau penerusan selaras lainnya tanda tangan DKIM masih dapat memenuhi mekanisme tersebut, dan masukannya tidak diketahui. Jangan menyimpulkan penerapan sebenarnya atau penempatan kotak masuk dari baris mana pun.
Tanda tangan kriptografi mengautentikasi tanggung jawab domain penandatanganan, bukan kebenaran atau otorisasi setiap instruksi. Perubahan pada byte yang dikanonikalisasi dapat membuat tanda tangan menjadi tidak valid; tidak setiap pengeditan yang terlihat mengubah masukan yang ditandatangani. Otentikasi dan penerimaan tingkat aplikasi tetap terpisah.
Baca garis waktu kadaluarsa hipotetis
Untuk kasus nonfungsional OTP-01, asumsikan jam tersinkronisasi: pemicu 10:00:00 GST, pengiriman penyedia 10:00:01 , penerimaan SMTP jarak jauh 10:00:03 , masa berlaku aplikasi yang disetujui 10:01:00 dan pengamatan kotak surat terkontrol 10:01:10 . Kedatangan yang ditemukan ini adalah 70 detik setelah pemicu dan 10 detik setelah asumsi berakhirnya. Bahkan izin DKIM yang telah diselaraskan dan ditetapkan tidak dapat memperpanjang masa pakai kode. Pemilik identitas menyelidiki latensi dan jalur pemulihan yang disetujui; aplikasi harus menerapkan aturan validitas yang dikonfigurasinya. Penerimaan jarak jauh bukanlah observasi kotak surat atau pembacaan manusia. Tidak ada latensi operasional, validitas kode, atau akses pelanggan yang diukur. Log aktual memerlukan offset jam dan ketidakpastian sebelum membandingkan tahapan.
Terapkan standar tanpa mengklaim kepatuhan
RFC 9989 Bagian 4.4 dan 5.3.5 mendukung keselarasan dan pembedaan mekanisme. Bagian 7.4 memperingatkan tentang interoperabilitas surat tidak langsung: penggunaan domain p=reject harus menggunakan DKIM yang valid, bukan SPF saja, dan penggunaan milis untuk tujuan umum memerlukan perhatian khusus. Inventaris rute itu sendiri bukanlah izin untuk menerapkan penolakan. RFC 6376 Bagian 3.4–3.7 dan 6.1 jelaskan masukan dan verifikasi yang ditandatangani. RFC 9990 Bagian 3.1 memberikan konteks pelaporan, bukan bukti kedatangan per penerima. RFC 5321 Bagian 4.2.5 membedakan tanggung jawab penerimaan server dari hasil pengiriman selanjutnya. Pilihan alur kerja sektor di sini adalah rekomendasi editorial; ruang lingkup hukum, kesesuaian faktor dan otorisasi lokal memerlukan tinjauan yang dapat dipertanggungjawabkan.