Email yang dihasilkan oleh sistem AI masih dikirimkan melalui aplikasi, layanan pengiriman, dan identitas domain. Inventarisasi komponen-komponen tersebut daripada memperlakukan yang dihasilkan AI sebagai kategori autentikasi baru. Penerima mengevaluasi identitas dan tanda tangan protokol, bukan apakah teks dibuat oleh manusia atau model.
Pisahkan identitas dalam aliran surat
Rekam domain Dari yang terlihat, SMTP pengirim amplop domain, DKIM penandatanganan domain dan pemilih, akun penyedia dan pemilik kredensial aplikasi. Tiga yang pertama memiliki peran protokol yang berbeda. RFC 9989 mendefinisikan DMARChubungan ke domain Dari dan selaras SPF atau hasil DKIM . Bagian lokal dan nama tampilan bukan dasar DMARC penyelarasan domain.
Domain infrastruktur penyedia dapat berhasil diautentikasi tanpa menyelaraskan dengan domain Dari organisasi yang terlihat. Sebaliknya, selaras tanda tangan DKIM dapat mendukung DMARC ketika jalur SPF tidak sejajar. Jangan mendiagnosis hasil dari satu label sandi tanpa mengidentifikasi domain mana yang diautentikasi oleh hasil tersebut.
Tetapkan kepemilikan organisasi secara terpisah
Petakan pesan ke penyewa penyedia sebenarnya, aplikasi, tujuan bisnis, dan tim yang bertanggung jawab. Alamat IP dan nama penyedia yang dibagikan hanyalah petunjuk, bukan bukti yang cukup bahwa pengirim tertentu adalah anggota organisasi tersebut. Minta pemilik aplikasi untuk mengonfirmasi cara layanan disediakan dan kredensial atau pengaturan penandatanganan mana yang digunakan.
DKIM membedakan pernyataan tanggung jawab domain penandatanganan dari penulis yang diakui. Tanda tangan yang valid tidak mengidentifikasi manusia yang menyetujui pesan, memvalidasi model AI, atau mengesahkan kontennya. Simpan catatan audit tingkat aplikasi untuk pertanyaan-pertanyaan tersebut.
Bandingkan tiga kasus identitas hipotetis
Asumsikan penyelarasan yang ketat dan From alerts.example . Dalam kasus A, SPF lolos untuk domain penyedia yang tidak terkait dan tanda tangan DKIM yang valid menggunakan d=alerts.example: jalur DKIM yang selaras memasok sandi DMARC . Dalam kasus B, SPF dan setiap tanda tangan DKIM yang valid menggunakan domain penyedia yang tidak terkait, sehingga tidak ada jalur yang selaras. Dalam kasus C, hanya nama tampilan pemasaran yang berubah sementara identitas domain dan hasil autentikasi tetap tidak berubah; penyelarasan domain tidak berubah.
Ini adalah perbandingan identitas buatan tangan, bukan evaluator atau tes tanda tangan yang dilakukan. Mereka berasumsi bahwa semua jalur yang relevan telah diperhitungkan dan tidak menerapkan penyelarasan yang longgar, penemuan kebijakan, atau disposisi penerima. Di bawah RFC 9989 bagian 7.4 dan 8, p=reject penerapan secara terpisah memerlukan tanda tangan DKIM yang valid dan melarang ketergantungan hanya pada SPF . Tiket masuk tingkat pesan tidak mengesampingkan kewajiban tersebut.
Verifikasi konfigurasi daripada menulis ulang label
Mengubah bidang tersimpan dari domain penyedia ke alerts.example tidak menjadikan tanda layanan sebagai domain tersebut. Gunakan konfigurasi akun yang didukung penyedia dan nilai DNS resmi, lalu uji rute sebenarnya dan bukti penerima yang dapat dipercaya. Jika pembacaan kembali konfigurasi cocok namun sampel masih menggunakan identitas penandatanganan lama, biarkan hasil jalur pesan gagal atau tidak terselesaikan alih-alih memperlakukan pengeditan file sebagai autentikasi yang diperbaiki. Ini adalah batas diagnostik hipotetis, bukan transformasi lokal, persetujuan nyata, atau publikasi DNS .
Pilih desain pengiriman yang dapat dipelihara
Gunakan identitas pengirim terdokumentasi yang dapat dipantau, dirotasi, dan dicabut oleh organisasi. Pisahkan aliran atau subdomain jika hal tersebut meningkatkan kepemilikan dan isolasi operasional, namun jangan mengklaim subdomain menjamin isolasi atau pengiriman reputasi. Verifikasi domain khusus penyedia dan konfigurasi penandatanganan dari instruksi pihak pertama saat ini sebelum penerapan.
Lacak setiap agen atau aplikasi yang membagikan kredensial pengirim. Jika satu kunci melayani beberapa layanan yang tidak terkait, laporan otentikasi mungkin tidak mengidentifikasi aplikasi mana yang menghasilkan pesan. Tingkatkan pencatatan log aplikasi dan pemisahan kredensial daripada melebih-lebihkan apa yang dapat diungkapkan DMARC .
Saat aplikasi dihentikan, cabut akses pengirimannya, tinjau konfigurasi penyedianya, dan hapus otorisasi yang tidak berlaku hanya setelah memeriksa dependensi bersama. Pertahankan inventaris yang dapat diuji yang menghubungkan bukti domain dengan kepemilikan bisnis. Rekomendasi ini bersifat netral terhadap penyedia dan tidak menegaskan integrasi EmailAuth tertentu atau kemampuan atribusi otomatis.