Cara Kerja Enkripsi Email: SPF, DKIM, TLS, dan End-to-End

Titik Awal: Email Tanpa Enkripsi

Ketika SMTP dirancang pada 1982, pesan dikirim sebagai teks biasa melalui jaringan. Siapa pun yang memiliki akses ke node jaringan antara pengirim dan penerima bisa membaca isinya. Tidak ada cara untuk memverifikasi siapa yang benar-benar mengirim pesan — kolom "From" bisa berisi apa saja. Ini dapat diterima di jaringan institusi akademik tepercaya, tetapi menjadi masalah besar saat internet berkembang menjadi miliaran pengguna.

Saat ini, keamanan email bergantung pada beberapa teknologi independen tetapi saling melengkapi, masing-masing menangani kerentanan yang berbeda. Pikirkan mereka sebagai lapisan-lapisan pelindung, masing-masing melindungi terhadap jenis serangan tertentu.

SPF: Siapa yang Boleh Mengirim?

Sender Policy Framework (SPF) menjawab pertanyaan sederhana: apakah server ini benar-benar diotorisasi untuk mengirim email untuk domain ini? Tanpa SPF, siapa pun bisa mengirim email yang mengklaim berasal dari bank-anda.com — protokol tidak memiliki cara bawaan untuk memverifikasi klaim tersebut.

SPF bekerja melalui catatan DNS. Pemilik domain mempublikasikan catatan TXT yang mencantumkan alamat IP dan server yang diotorisasi untuk mengirim email atas nama mereka. Ketika server penerima mendapat email dari "user@example.com", ia mencari catatan SPF example.com dan memeriksa apakah IP server pengirim ada dalam daftar yang diotorisasi. Jika tidak, email bisa ditandai atau ditolak.

SPF memiliki keterbatasan. Ia hanya memeriksa alamat "envelope from" (digunakan selama transmisi SMTP), bukan alamat "header from" (yang ditampilkan kepada pengguna). SPF juga bermasalah ketika email diteruskan, karena server penerus tidak ada dalam daftar SPF domain asli.

DKIM: Apakah Pesan Ini Asli?

DomainKeys Identified Mail (DKIM) mengambil pendekatan berbeda. Alih-alih memverifikasi server, ia memverifikasi pesan itu sendiri. Server pengirim menambahkan tanda tangan kriptografi ke setiap email keluar menggunakan kunci privat yang hanya dimilikinya. Kunci publik yang sesuai dipublikasikan di catatan DNS domain.

Ketika server penerima mendapat email, ia mengambil kunci publik dari DNS dan menggunakannya untuk memverifikasi tanda tangan. Jika tanda tangan cocok, itu berarti: (1) email dikirim oleh server yang memegang kunci privat untuk domain tersebut, dan (2) konten pesan tidak diubah sejak ditandatangani.

DKIM bertahan saat email diteruskan (tidak seperti SPF) karena tanda tangan ikut bersama pesan. Namun, mailing list yang memodifikasi isi pesan atau header akan merusak tanda tangan tersebut.

TLS: Enkripsi dalam Perjalanan

Transport Layer Security (TLS), diterapkan ke SMTP melalui ekstensi STARTTLS, mengenkripsi koneksi antara server email. Ketika dua server SMTP berkomunikasi, server pengirim bisa mengeluarkan perintah STARTTLS untuk meningkatkan koneksi dari teks biasa ke terenkripsi. Ini mencegah penyadap membaca konten pesan saat transit antar server.

Namun, STARTTLS biasanya bersifat "oportunistik" — jika server penerima tidak mendukungnya, pesan dikirim tanpa enkripsi. Penyerang jaringan juga bisa melakukan serangan downgrade, menghapus tawaran STARTTLS dari respons server. MTA-STS dan DANE adalah standar yang lebih baru yang dirancang untuk memaksakan TLS dan mencegah downgrade semacam itu, tetapi adopsinya masih berkembang.

Penting untuk dipahami bahwa TLS hanya melindungi data dalam perjalanan. Setelah email mencapai server tujuan, ia disimpan dalam format apa pun yang digunakan server — sering kali tanpa enkripsi. TempoMail mengatasi ini dengan mengenkripsi semua email yang tersimpan menggunakan AES-256-GCM, memastikan bahwa bahkan jika penyimpanan dikompromi, isinya tetap terlindungi.

Enkripsi End-to-End: Standar Emas

Enkripsi end-to-end (E2EE) adalah satu-satunya pendekatan yang melindungi konten email dari semua orang kecuali pengirim dan penerima yang dituju — termasuk penyedia email itu sendiri. Dua standar utamanya adalah PGP (Pretty Good Privacy) dan S/MIME.

Dengan PGP, setiap pengguna membuat pasangan kunci publik-privat. Untuk mengirim email terenkripsi, Anda mengenkripsi pesan dengan kunci publik penerima. Hanya kunci privat mereka yang bisa mendekripsinya. S/MIME bekerja serupa tetapi menggunakan sertifikat yang diterbitkan oleh otoritas sertifikat alih-alih web of trust.

Meskipun telah tersedia selama puluhan tahun, adopsi E2EE dalam email tetap rendah. Masalah manajemen kunci — mendistribusikan, memverifikasi, dan menyimpan kunci — menciptakan gesekan yang kebanyakan pengguna tidak mau terima. Layanan seperti ProtonMail telah menyederhanakan ini dengan menangani manajemen kunci secara transparan, tetapi secara default hanya berfungsi antar pengguna ProtonMail.

Gambaran Keseluruhan

Dalam praktik, teknologi-teknologi ini bekerja bersama: SPF dan DKIM memverifikasi identitas pengirim, DMARC memberikan penegakan kebijakan, TLS melindungi pesan dalam transit, dan E2EE (jika digunakan) melindungi konten itu sendiri. Tidak ada satu teknologi yang menyelesaikan semua masalah, tetapi bersama-sama mereka telah membuat email jauh lebih aman dari kondisi awalnya yang tidak terlindungi.

Untuk privasi sehari-hari, menggunakan alamat email sekali pakai untuk layanan yang tidak dipercaya adalah salah satu langkah paling praktis yang bisa Anda ambil — ini menghindari sepenuhnya pertanyaan apakah suatu layanan menerapkan enkripsi dengan benar, dengan memastikan alamat asli Anda tidak pernah terekspos sejak awal.