ARC pada Email: Menjaga Hasil Autentikasi saat Pesan Diteruskan

Email sering melewati beberapa server sebelum tiba di kotak masuk. Layanan penerusan, gateway keamanan, dan milis dapat mengubah bagian pesan atau jalur pengirimannya. Akibatnya, pemeriksaan autentikasi yang semula berhasil bisa gagal di server penerima berikutnya, meskipun email itu awalnya dikirim secara sah.

Authenticated Received Chain (ARC) dirancang untuk membawa catatan hasil autentikasi dari setiap perantara yang mendukungnya. ARC membantu penerima memahami apa yang terjadi pada email sepanjang perjalanan, tetapi bukan pengganti SPF, DKIM, atau DMARC dan bukan jaminan bahwa pesan aman.

Mengapa email yang diteruskan bisa gagal autentikasi?

SPF memeriksa apakah alamat IP pengirim diizinkan oleh kebijakan domain yang diperiksa. Ketika email diteruskan, server pengirim yang terlihat bisa berubah menjadi server penerus, sehingga pemeriksaan SPF terhadap domain awal mungkin gagal. DKIM menggunakan tanda tangan untuk membantu memeriksa integritas bagian pesan; tanda tangan itu juga dapat rusak jika perantara mengubah isi atau header yang ditandatangani.

DMARC menilai apakah hasil SPF atau DKIM yang lolos selaras dengan domain pada alamat From. Jika kedua mekanisme tidak memenuhi syarat DMARC setelah proses penerusan, penerima dapat memperlakukan pesan sah sebagai mencurigakan. Masalah serupa dapat terjadi pada milis yang menambahkan awalan subjek atau footer.

ARC memberi konteks tambahan: perantara yang mendukung protokol ini dapat menandatangani hasil autentikasi yang dilihatnya saat memproses pesan. Server berikutnya dapat memeriksa rantai tersebut dan mempertimbangkan informasi itu dalam kebijakan penerimaan.

Tiga header utama ARC

Setiap perantara ARC menambahkan satu set informasi. Tiga header yang perlu dikenali adalah:

• ARC-Authentication-Results (AAR): mencatat hasil pemeriksaan autentikasi yang dinyatakan oleh perantara, misalnya hasil SPF, DKIM, atau DMARC pada tahap tersebut.
• ARC-Message-Signature (AMS): memberikan tanda tangan atas pesan dan informasi terkait sehingga penerima dapat memeriksa integritas data yang ditandatangani.
• ARC-Seal (AS): menandatangani informasi rantai ARC, termasuk set sebelumnya, agar perubahan pada rantai dapat terdeteksi.

Setiap set memiliki nomor instans, misalnya i=1, i=2, dan seterusnya. Nomor ini membantu menunjukkan urutan perantara. ARC juga membawa informasi status validasi rantai sebelumnya, tetapi keberadaan header saja tidak cukup untuk menyimpulkan bahwa semua pemeriksaan berhasil.

Bagaimana ARC bekerja dalam alur email?

1. Server penerima pertama memeriksa pesan. Sistem menilai SPF, DKIM, dan DMARC sesuai kebijakannya. Hasil ini menjadi konteks yang dapat dicatat oleh perantara ARC.
2. Perantara memproses atau meneruskan email. Jika layanan mendukung ARC, layanan tersebut membuat AAR, AMS, dan AS yang sesuai dengan hasil pemeriksaan serta pesan pada tahap itu.
3. Rantai bertambah saat pesan melewati perantara lain. Set berikutnya diberi nomor instans berikutnya dan mengikat informasi sebelumnya dalam rantai yang ditandatangani.
4. Server tujuan memvalidasi rantai. Penerima memeriksa tanda tangan dan urutan set ARC, lalu menilai hasil autentikasi yang disampaikan perantara.
5. Kebijakan penerima mengambil keputusan. Sistem dapat menggunakan hasil ARC sebagai salah satu sinyal untuk menentukan apakah kegagalan autentikasi akhir dapat dijelaskan oleh penerusan yang tepercaya. Keputusan tetap bergantung pada implementasi dan tingkat kepercayaan penerima.

Langkah praktis untuk administrator email

ARC paling berguna bila organisasi mengoperasikan sistem penerusan, milis, atau gateway yang memodifikasi pesan. Mulailah dengan langkah berikut:

• Petakan jalur email. Catat layanan penerusan, platform tiket, gateway keamanan, dan milis yang memproses pesan domain organisasi. Jangan mengaktifkan kepercayaan hanya berdasarkan nama layanan yang terlihat di header.
• Periksa dukungan penyedia. Gunakan dokumentasi resmi layanan email untuk mengetahui apakah ARC didukung dan bagaimana kunci penandatanganan dikelola. Hindari membuat konfigurasi DNS sendiri berdasarkan contoh yang tidak cocok dengan penyedia.
• Uji pesan nyata. Kirim email melalui jalur penerusan yang umum digunakan, lalu buka header lengkap di kotak masuk tujuan. Periksa AAR, AMS, AS, nomor instans, hasil validasi rantai, serta hasil SPF, DKIM, dan DMARC pada pesan akhir.
• Percayai perantara secara selektif. Jika server tujuan memiliki daftar atau kebijakan perantara tepercaya, masukkan hanya layanan yang identitas, pengoperasian, dan praktik keamanannya telah dievaluasi. ARC yang valid membuktikan integritas klaim dalam rantai, bukan bahwa pembuat klaim selalu jujur.
• Pantau sebelum mengubah kebijakan. Amati email sah yang gagal autentikasi dan pesan berbahaya yang lolos penyaringan. Sesuaikan kebijakan secara terukur; jangan menonaktifkan DMARC hanya karena beberapa email yang diteruskan mengalami masalah.

Kesimpulan

ARC dapat membantu penerima menilai riwayat autentikasi pesan yang melewati perantara, tetapi bukan jaminan bahwa pesan aman. Terapkan bersama SPF, DKIM, dan DMARC, pilih perantara yang tepercaya, dan evaluasi kebijakan berdasarkan log serta hasil pengiriman nyata.