Pemberitahuan keuangan tidak menentukan keakuratan transaksi yang mendasarinya maupun izin untuk memindahkan uang. Pengirim resmi yang disusupi dapat menghasilkan email yang lolos otentikasi. Bangun inventaris rute yang menjelaskan sistem mana yang mewakili institusi tersebut, lalu pertahankan kontrol transaksi terpisah yang menentukan apa yang mungkin terjadi.
Mulailah dengan tindakan yang diminta dari pelanggan
Pisahkan peringatan informasi pelanggan, pemberitahuan transaksi, dan komunikasi outsourcing. Catat apakah setiap pesan meminta pelanggan untuk meninjau aktivitas, mengautentikasi ke akun yang ada, menghubungi dukungan, atau mengotorisasi tindakan finansial. Identifikasi aplikasi otoritatif di mana transaksi dapat diverifikasi melalui jalur akses yang diketahui.
Untuk setiap aliran, catat pemiliknya, penyewa aplikasi, Dari domain, identitas amplop, DKIM domain dan pemilih, populasi penerima yang diharapkan dan pemilik cadangan. Kontrol staf-mail tidak dapat menetapkan cakupan layanan laporan yang dialihdayakan. Nama Dari bermerek yang sama dapat menyembunyikan beberapa penyedia dan konfigurasi khusus pelanggan.
Simpan dua catatan persetujuan
Pemilik domain menyetujui identitas pengirim dan konfigurasi teknisnya. Pemilik transaksi atau risiko menyetujui alur kerja keuangan. Catatan perubahan DNS tidak boleh digunakan sebagai bukti bahwa perubahan penerima telah disetujui, dan alur kerja pembayaran yang disetujui tidak boleh digunakan untuk mengabaikan pengujian email.
Untuk instruksi sensitif, gunakan prosedur verifikasi dan persetujuan independen yang telah ditetapkan oleh lembaga. Jangan verifikasi tujuan pembayaran yang diubah hanya menggunakan rincian kontak yang terdapat dalam pesan yang meminta perubahan. Jaga pemisahan peran dan otorisasi transaksi dalam aplikasi keuangan yang relevan. Ini adalah rekomendasi pengendalian risiko; panduan ini tidak menentukan perizinan, penerapan peraturan, atau kepatuhan hukum.
Uji komunikasi yang dialihdayakan oleh penyewa
Tanyakan kepada pemasok tentang konfigurasi yang berlaku untuk layanan dan penyewa yang dikontrak sebenarnya. Verifikasi siapa yang mengontrol domain penandatanganan khusus, bagaimana pemilih diubah, siapa yang menangani kegagalan, dan apa yang terjadi pada penghentian kontrak. Pernyataan umum bahwa pemasok mendukung DKIM tidak cukup menjadi bukti bahwa aliran lembaga tersebut menggunakan tanda tangan yang selaras.
Peta contoh di bawah membuat perbedaan tersebut terlihat: komunikasi yang dialihdayakan diasumsikan melewati DKIM di bawah provider.example.net , namun domain tersebut tidak sama persis dengan notices.finance.example . Selidiki jalur selaras yang sah sebelum memutuskan remediasi. Hasilnya bukanlah bukti bahwa pemasok sebenarnya tidak aman atau bahwa setiap pesan pada rute tersebut gagal DMARC.
Definisikan penerimaan dan eskalasi secara terpisah
Gunakan akun pengujian yang disetujui dan detail transaksi fiktif. Konfirmasikan jalur identitas, waktu, dan status aplikasi aktual untuk setiap kelompok notifikasi. Tanda tangan yang benar dengan jumlah yang menyesatkan merupakan masalah aplikasi atau integritas data. Jumlah yang benar dengan pengirim yang tidak terverifikasi adalah masalah identitas. Keduanya mungkin memerlukan eskalasi, namun keduanya mempunyai pemilik dan solusi yang berbeda.
Pertahankan referensi peristiwa minimal dan bukti yang disunting daripada mengekspor informasi akun secara luas. Tinjau lansiran konsekuensial bervolume rendah secara terpisah dari kampanye. Jika suatu perubahan merusak aliran kritis, hentikan peluncuran dan gunakan rencana pemulihan yang disetujui daripada melonggarkan semua izin domain. Segarkan inventaris setelah perubahan platform inti, migrasi pemasok, perjalanan pelanggan baru, dan perubahan kebijakan persetujuan transaksi.
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.
- peringatan pelanggan: terlihat Dari domain alerts.finance.example ; DKIM d=alerts.finance.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 operasi pelanggan. Tindakan selanjutnya: Dapatkan sampel resmi dan hasil penerima tepercaya untuk penyewa ini.
- pemberitahuan transaksi: terlihat Dari domain transactions.finance.example ; DKIM d=transactions.finance.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 pembayaran. Tindakan selanjutnya: Konfirmasikan rute terpisah ini dan peristiwa bisnisnya daripada mewarisi hasil rute pertama.
- komunikasi outsourcing: terlihat Dari domain notices.finance.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 risiko pemasok. 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.
Memutuskan kasus identitas dan pembayaran secara mandiri
Untuk notifikasi fiktif F-01, asumsikan pass DKIM selaras tetapi permintaan penerima baru tanpa bukti transaksi yang disetujui. Membiarkan keputusan pembayaran tidak disetujui dan memverifikasi melalui proses terkendali yang ada di lembaga; administrator DNS tidak dapat menggantikan pemberi persetujuan transaksi. Sebaliknya, transaksi yang disetujui dengan identitas pemberitahuan yang belum terselesaikan memerlukan penyelidikan rute surat, bukan pembalikan pembayaran otomatis. Hanya mencatat referensi kasus yang tidak sensitif dan peran yang bertanggung jawab dalam diagnostik bersama. Tidak ada nomor rekening, saldo, instruksi nyata atau transfer yang dieksekusi yang disertakan.
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.