Email bisa berbohong… meski pemeriksaan bilang “OK”

Diperbarui pada 25 September 2026

Di balik layar sebuah teknologi yang usianya sudah puluhan tahun, para peretas belajar mempermainkan aturan. Email sudah ditambahi pemeriksaan identitas, dan pemeriksaan itu bekerja. Tetapi semuanya hanya menjawab satu pertanyaan: dari mana pesan ini berasal? Tidak pernah menjawab pertanyaan yang paling penting: apakah pesan ini jujur?

Kebohongan pertama: “Saya bank Anda”

Ceritanya dimulai dengan sebuah email, seperti ribuan email lain yang datang setiap hari:

Dari: support@mybank.example
Subjek: ⚠️ Akun Anda akan ditangguhkan hari ini

Semuanya tampak normal: logo, tanda tangan, alamat, nada profesional. Tetapi siapa sebenarnya yang mengirim pesan ini?

Di sinilah kita menemukan warisan aneh dari internet: sejak awal, email tidak dirancang untuk membuktikan identitas pengirimnya.

Kartu pos, bukan surat tercatat

Mengirim email mirip seperti mengirim kartu pos: kita menulis pesan, menulis nama pengirim, lalu tukang pos mengantarkannya. Tetapi tukang pos tidak memeriksa apakah nama yang tertulis benar-benar milik orang yang mengirim kartu itu. (Untuk mengikuti tukang pos ini langkah demi langkah, lihat panduan Bagaimana email berpindah dari pengirim ke penerima.)

Protokol email pertama lahir di internet yang masih sangat kecil, ketika hampir semua orang saling mengenal. Kepercayaan dianggap wajar. Kini, teknologi yang sama mengalirkan sebagian besar komunikasi kita. Mustahil mematikan semuanya lalu membangun ulang email dengan benar: itu seperti mengganti mesin pesawat saat sedang terbang.

Tiga pemeriksa di pintu masuk: SPF, DKIM, dan DMARC

Karena tidak bisa membangun ulang semuanya, para insinyur menambahkan pemeriksaan identitas di atasnya. Daripada definisi teknis, bayangkan mereka sebagai tiga tokoh yang berjaga di pintu masuk kotak surat Anda.

Ilustrasi: sebuah email tiba dan melewati tiga tokoh. SPF, si detektif, memeriksa apakah mesin pengirim boleh mengirim atas nama domain itu. DKIM, penjaga segel, memeriksa apakah pesan membawa segel domain dan tidak diubah. DMARC, penjaga pintu, menjalankan aturan domain jika ada yang tidak cocok: loloskan, masukkan ke folder spam, atau tolak.
Gambar 1: tiga pemeriksa email. Masing-masing memeriksa sebagian identitas teknis pesan.
  • SPF, si detektif: “Apakah mesin ini boleh mengirim email atas nama domain ini?” Domain menerbitkan daftar server yang diizinkan; detektif memeriksanya.
  • DKIM, penjaga segel: “Apakah pesan ini membawa tanda tangan digital domain, dan apakah tanda tangan itu utuh?” Seperti segel lilin, tanda tangan ini membuktikan bahwa pesan benar-benar berasal dari infrastruktur domain dan tidak diubah di perjalanan.
  • DMARC, penjaga pintu: “Apa yang dilakukan jika ada yang tidak cocok?” Domain meninggalkan instruksi: loloskan, masukkan ke spam, atau tolak.

Di atas kertas, ini kokoh. Lalu bagaimana peretas masih bisa lolos?

Kejutannya: email yang asli… tapi tetap penipuan

Inilah inti masalahnya. Ketiga pemeriksa memverifikasi identitas teknis pesan. Tetapi setidaknya ada empat cara untuk mendapatkan identitas teknis yang benar-benar sah.

Jebakan no. 1: domain palsu yang hampir sempurna

Peretas membeli nama domainnya sendiri, yang sekilas sama persis dengan milik bank:

support@mybank-pr1vate.example   (bukan mybank-private)

Sebuah angka “1” menggantikan huruf “i”. Peretas mengatur SPF, DKIM, dan DMARC dengan benar: itu domain miliknya, ia berhak melakukannya. Maka para pemeriksa menjawab dengan jujur: ✅ “Domain ini memang berwenang mengirim pesan ini.” Sementara itu, otak pembaca membaca: 😱 “Ini bank saya!”

Alat-alat itu memeriksa siapa yang mengirim. Mereka tidak memahami niat pesan.

Jebakan no. 2: pintu yang terlupakan

Sebuah bank besar memiliki ratusan subdomain: satu untuk promosi, satu untuk kontes lama, satu untuk layanan yang sudah ditutup lima tahun lalu… Di suatu tempat, promo.old-bank.example masih ada, dan tidak ada lagi yang benar-benar mengurusnya.

Jika subdomain itu masih mengarah ke layanan yang sudah tidak ada, atau perlindungannya lemah, penyerang terkadang bisa mengambil alih kendalinya. Ia tidak perlu mendobrak pintu utama: ia cukup mencari pintu samping yang dilupakan semua orang. Dan apa pun yang ia terbitkan di sana membawa nama asli bank tersebut.

Jebakan no. 3: mencuri kunci yang asli

Bagaimana jika peretas bahkan tidak membuat alamat palsu? Jika ia mencuri kata sandi karyawan sungguhan, misalnya lewat phishing sebelumnya, email-emailnya akan keluar dari infrastruktur asli perusahaan. SPF, DKIM, dan DMARC bekerja normal, dan memang seharusnya begitu: semuanya asli. Kali ini bukan lagi identitas palsu. Ini identitas asli yang dipakai oleh orang yang salah.

Jebakan no. 4: berbaur dengan alat yang dipakai semua orang

Perusahaan mengirim buletin dan kampanye melalui platform khusus yang terkenal dan dinilai baik oleh filter. Penyerang bisa mencoba menyalahgunakan platform ini jika konfigurasinya buruk atau jika akun pelanggan di sana diretas. Jadi peretas tidak selalu membangun sistemnya sendiri: terkadang ia menyusup ke sistem orang lain, tempat ia tidak menarik perhatian. Panduan Phishing: cara penipu meloloskan email mereka menjelaskan teknik pengiriman ini secara rinci.

Ilustrasi: sebuah amplop membawa tiga stempel hijau, SPF, DKIM, dan DMARC, serta alamat pengirim support@mybank-pr1vate.example, dengan angka 1 menggantikan huruf i. Di dalamnya, surat mengumumkan “Akun Anda akan ditangguhkan hari ini!” dengan tombol “Klik di sini”, sementara peretas bertopeng bersembunyi di belakangnya. Keterangan: pemeriksaan hanya memverifikasi amplop, bukan isi surat.
Gambar 2: amplopnya bisa benar-benar asli… dan suratnya tetap berbohong.
Kalimat yang perlu diingat

SPF, DKIM, dan DMARC membantu memverifikasi identitas teknis sebuah pesan. Sendirian, mereka tidak bisa menentukan apakah isinya benar. Ini seperti memastikan amplopnya asli tanpa bisa menjamin bahwa surat di dalamnya tidak berbohong.

Terkadang masalahnya dimulai bahkan sebelum peretas datang

Kembali ke lapangan. Server email tidak otomatis aman hanya karena berfungsi.

Jebakan salin-tempel

Seorang administrator mencari “cara cepat memasang server Postfix”. Ia menemukan tutorial, menyalin perintahnya, dan… berhasil. Selesai? Belum tentu. Konfigurasi yang membuat server cepat berjalan belum tentu konfigurasi yang diperkuat, yaitu yang disetel untuk tahan terhadap serangan.

Server yang berubah menjadi mesin spam

Konfigurasi yang buruk dapat mengubah server menjadi open relay (relai terbuka): mesin yang mau meneruskan pesan siapa saja, padahal seharusnya hanya melayani penggunanya sendiri. Bagi penyerang, ini durian runtuh: server jujur dengan reputasi baik yang mengirimkan email untuknya.

Dan tidak perlu mencari secara manual. Siklusnya sederhana: pindai → uji → temukan → eksploitasi, dan semuanya sangat mudah diotomatiskan. Jadi bukan lagi selalu peretas yang duduk di depan layar mencari korban. Sering kali, mesinlah yang mencari mesin lain, siang dan malam.

Selagi kita berpikir, mesin sudah menyerang

Email berbahaya bisa dikirim → diterima → dibuka → diklik → dieksploitasi dalam hitungan menit. Sementara itu, di pihak pertahanan, sistem harus menganalisis pesan, tim harus menerima peringatan, seseorang harus menafsirkannya, lalu aturan penyaringan harus diperbarui. Setiap menit berharga.

Dari sini muncul gagasan sederhana: sistem keamanan yang tidak diawasi siapa pun lama-lama tidak lagi benar-benar aman. Aturan menjadi usang, peretas beradaptasi, peringatan menumpuk tanpa dibaca.

Untuk menghemat menit-menit itulah Baitback dibuat: tempelkan email yang mencurigakan, alat ini menemukan server yang benar-benar mengirimnya beserta penyedia hostingnya, lalu menyiapkan laporannya. Semakin cepat server pengirim dilaporkan, semakin cepat server itu bisa dimatikan.

Bisakah email dibuat anti-gagal?

Kemungkinan besar tidak dengan satu teknologi saja, karena masalahnya berlapis-lapis:

  • 📨 Protokolnya: dirancang di era lain, untuk internet yang lain.
  • 🔐 Infrastrukturnya: kadang salah konfigurasi, kadang sudah tua, kadang terlupakan.
  • 🤖 Sistem deteksinya: mampu menemukan sangat banyak hal, tetapi tidak semuanya.
  • 🧑 Manusianya: mampu mencium jebakan… dan bisa dimanipulasi.

Jika teknologi saja tidak cukup, apa yang dilakukan para peneliti agar deteksi menjadi lebih cerdas? Itulah topik panduan berikutnya: Phishing: permainan kucing dan tikus antara peneliti dan peretas.

Yang perlu diingat
  • Email tidak dirancang untuk membuktikan siapa pengirimnya: SPF, DKIM, dan DMARC ditambahkan belakangan.
  • Pemeriksaan ini memverifikasi identitas teknis pesan (amplop), bukan kejujuran isinya (surat).
  • Domain tiruan, subdomain yang terlupakan, akun curian, atau platform pengiriman yang disalahgunakan semuanya bisa menghasilkan email yang “sah”.
  • Server yang salah konfigurasi bisa menjadi relai bagi spammer, ditemukan secara otomatis oleh bot.
  • Kecepatan itu penting: melaporkan server pengirim sejak dini, misalnya dengan Baitback, memperpendek umur sebuah kampanye.

Menerima email mencurigakan?

Tempelkan ke Baitback: alat ini menemukan server yang mengirimnya beserta penyedia hostingnya, lalu menyiapkan laporan Anda dalam satu langkah.

Analisis email

Semua panduan