Email masih menjadi salah satu saluran komunikasi bisnis yang paling banyak dipakai. Email juga menjadi salah satu target serangan yang paling sering karena sifatnya yang terbuka, sering digunakan untuk verifikasi identitas, dan umumnya diterima oleh seluruh organisasi.

Serangan via email tidak selalu terlihat seperti script Hollywood. Banyak insiden dimulai dari email yang terlihat normal, hanya ada satu detail yang agak aneh: pengirim yang tidak diharapkan, tautan yang mengarah ke domain asing, lampiran yang tidak diminta, atau permintaan yang mendesak untuk segera membalas.

Artikel ini membahas email security mulai dari cara kerja phishing, autentikasi email dengan SPF, DKIM, dan DMARC, email filtering, kebijakan kredensial, hingga respons insiden email.

Email sebagai mata uang serangan

Email sering dipakai untuk:

  • Phishing yang meniru perusahaan, bank, atau mitra

  • Business Email Compromise atau BEC

  • Lampiran berisi malware, ransomware, atau infostealer

  • Link yang mengarah ke website palsu untuk mencuri kredensial

  • Spoofing pengirim agar pesan terlihat sah

  • Social engineering yang memanfaatkan hierarki atau kebiasaan tim

  • Spam yang membebani kotak masuk dan menutup pesan penting

Tidak ada sistem keamanan yang bisa menutupi seluruh risiko hanya dengan satu produk. Email security membutuhkan kombinasi: autentikasi pengirim, filtering, kebijakan akses, training pengguna, dan respons insiden.

Phishing

Phishing adalah upaya memperoleh informasi sensitif dengan menyamar sebagai sumber tepercaya. Dalam konteks email, phishing bisa menarget individu atau organisasi.

Jenis phishing yang umum

Email phishing umum

Pesan meniru bank, marketplace, penyedia layanan, atau vendor. Biasanya meminta klik tautan, memperbarui data, atau memverifikasi akun.

Spear phishing

Spear phishing lebih ditargetkan. Penyerang sudah mengumpulkan informasi tentang target: nama, peran, proyek, hubungan bisnis, atau jadwal. Pesan terlihat lebih relevan sehingga lebih mungkin dipercaya.

Whaling

Whaling menargetkan pemimpin atau pihak yang memiliki akses tinggi. Karena target jarang dan dampaknya besar, insiden ini sering mendapat perhatian lebih dan kerusakan yang lebih besar.

Business Email Compromise atau BEC

BEC biasanya tidak memakai lampiran berbahaya. Penyerang hanya mengirim permintaan transfer, perubahan rekening, pembayaran invoice, atau akses data. Jika pesan terlihat sah dan diteruskan keuangan atau tim operasional, kerugiannya bisa besar sebelum terdeteksi.

Tanda phishing yang sering muncul

  • Pengirim yang tidak sesuai dengan alamat yang terlihat di header

  • Nama perusahaan yang mirip, tetapi domain sedikit berbeda

  • Permintaan yang mendesak

  • Permintaan transfer, perubahan rekening, atau akses data

  • Tautan yang tidak sesuai dengan konteks

  • Lampiran tidak diminta atau format yang tidak biasa

  • Gaya bahasa yang tidak sesuai dengan kebiasaan pengirim asli

  • Pesan yang meminta kamu melewati prosedur verifikasi biasa

Respon yang benar

  • Jangan langsung klik tautan atau buka lampiran.

  • Verifikasi pengirim melalui saluran lain, bukan dengan membalas email yang dicurigai.

  • Laporkan ke tim IT atau security.

  • Jangan masukkan kredensial pada halaman login yang tidak pasti.

  • Jangan mengunduh file eksekusi dari email yang tidak diharapkan.

  • Dokumentasikan detail pesan untuk investigasi.

Pelatihan pengguna

Training anti-phishing sebaiknya berkelanjutan, bukan satu kali saat onboarding. Beberapa praktik yang membantu:

  • Simulasi phishing yang diregistrasi dan diukur

  • Contoh kasus nyata dari industri sejenis

  • Prosedur pelaporan yang jelas dan mudah diakses

  • Pembelajaran dari insiden internal, bukan hanya teori umum

  • Pengingat berkala tentang skema baru

Pelatihan yang menakut-nakuti tanpa contoh yang jelas jarang membuat perubahan perilaku. Yang lebih efektif adalah latihan pendek yang relevan dengan email yang benar-benar diterima tim.

Autentikasi email: SPF, DKIM, dan DMARC

Ketiga mekanisme ini bertujuan menjawab pertanyaan: apakah email ini benar-benar berasal dari domain yang tertera, dan apakah domain tersebut memang mengizinkan pengiriman seperti itu?

SPF atau Sender Policy Framework

SPF adalah catatan DNS yang menentukan server mana yang diizinkan mengirim email untuk domain tersebut.

Contoh record SPF:

v=spf1 ip4:192.0.2.10 include:_spf.google.com -all

Record tersebut menyatakan: - IP 192.0.2.10 diizinkan - Record dari _spf.google.com juga diizinkan - Seluruh pengirim lain ditolak dengan -all

SPF mencegat spoofing yang menggunakan server lain, tetapi tidak mencegat forwarding atau alias yang mengubah envelope sender. Selain itu, SPF hanya memeriksa envelope sender, bukan alamat From yang terlihat oleh pengguna.

DKIM atau DomainKeys Identified Mail

DKIM menambahkan tanda tangan digital pada email. Tanda tangan ini dibuat menggunakan private key milik pengirim. Penerima dapat memverifikasi tanda tangan tersebut menggunakan public key yang dipublikasikan melalui DNS.

DKIM membantu memastikan pesan tidak diubah saat dalam perjalanan dan memang berasal dari domain yang memiliki private key yang sesuai.

DKIM bukan jaminan email tidak berbahaya, tetapi menjadi sinyal bahwa pesan tidak dimodifikasi secara sembarang di tengah perjalanan.

DMARC atau Domain-based Message Authentication, Reporting, and Conformance

DMARC menghubungkan SPF dan DKIM dengan kebijakan yang diterapkan penerima.

Record DMARC mengatur:

  • Apakah email yang lolos SPF atau DKIM yang sah

  • Kebijakan jika autentikasi gagal: none, quarantine, atau reject

  • Alamat untuk menerima laporan aggregat dan forensic

Contoh record DMARC:

v=DMARC1; p=quarantine; rua=mailto:dmarc-agg@example.com

Kebijakan none hanya meminta laporan tanpa memblokir email. quarantine memindahkan email ke spam jika autentikasi gagal. reject menolak email pada saat itu juga.

Penerapan DMARC perlu dilakukan bertahap: - Mulai dari p=none dan kumpulkan laporan - Analisis sumber pengiriman yang sah - Perbaiki konfigurasi SPF, DKIM, atau routing yang bermasalah - Pindah ke p=quarantine - Lanjut ke p=reject setelah konfigurasi stabil

Melompat ke reject tanpa memahami aliran email bisnis dapat memutus aliran penting seperti newsletter, sistem ticketing, atau layanan pihak ketiga.

Email filtering

Email filtering bertujuan memilah mana yang aman, mencurigakan, atau jelas berbahaya sebelum sampai ke kotak masuk pengguna.

Filtering bisa terjadi di beberapa lapisan:

  • Infrastructure layer: firewall, gateway, dan protection di depan mail server

  • Mail server layer: antispam, antivirus, dan policy enforcement

  • Cloud mail provider layer: filter bawaan seperti Gmail atau Microsoft 365

  • Endpoint layer: klien email yang melakukan filtering tambahan

Hal yang umum difilter

  • Lampiran berisi eksekusi file atau format berbahaya

  • Tautan yang terdeteksi menuju domain phishing atau malware

  • Header yang tidak konsisten

  • Perubahan signifikan dari pola pengiriman normal

  • Email dari domain baru yang tidak memiliki reputasi

  • Konten yang cocok dengan indikator kompromasi yang diketahui

Tantangan filtering

  • Email bisnis yang sah kadang mirip dengan ancaman

  • Bahasa bisnis yang kompleks memicu false positive

  • Lampiran berukuran besar dari vendor atau klien

  • Newsletter dan promosi yang diizinkan, tetapi menambah beban

  • Aturan yang terlalu agresif dapat memblokir pesan penting

Filtering yang bagus bukan hanya menambahkan rule yang lebih banyak, tetapi memahami aliran email organisasi dan menyesuaikan kebijakan sesuai risikonya.

Kebijakan email yang perlu diperhatikan

Gunakan domain resmi

Pisahkan domain untuk komunikasi internal, eksternal, dan layanan internal. Hindari menggunakan domain pribadi untuk urusan resmi perusahaan.

Lindungi akun administrator

Akun administrator email memiliki akses tinggi. Akun tersebut sebaiknya dilindungi dengan autentikasi multifaktor, sesi yang terbatas, dan monitoring khusus.

Batasi akses email dari luar

Jika memungkinkan, batasi akses webmail hanya dari jaringan yang dipercaya atau melalui VPN. Jangan mengekspos antarmuka admin secara langsung ke internet.

Aktifkan logging

Catat autentikasi login, perubahan rule, forwarding, akses API, dan aktivitas admin. Log ini berguna ketika terjadi insiden atau whenforensics.

Kebijakan attachment

Larang format yang jelas berisiko tinggi untuk kebutuhan internal. Untuk kebutuhan tertentu, gunakan metode transfer file yang lebih aman.

Kebijakan forwarding dan alias

Forwarding email keluar dapat menembus kontrol keamanan perusahaan. Pantau rule forwarding yang dibuat pengguna dan larang forwarding otomatis ke domain pribadi jika tidak dibutuhkan.

Respons insiden email

Ketika terjadi insiden email, langkah respons yang umum:

1. Identifikasi cakupan

Tentukan apakah ini satu individu, satu departemen, atau keseluruhan organisasi. Identifikasi email apa yang terlibat, waktu pengiriman, dan siapa yang sudah membalas atau mengklik tautan.

2. Pidahkan akses yang relevan

Jika akun email disusupi, putuskan sesi aktif, reset password, dan periksa apakah ada rule forwarding atau forwarding lain yang dibuat penyerang.

3. Isolasi dampak

Jika ada lampiran berbahaya yang sudah dibuka, periksa endpoint yang terpapar. Jika ada kredensial yang dimasukkan, reset kredensial yang relevan dan periksa aktivitas akun.

4. Dokumentasikan jejak

Catat waktu insiden, header email, tautan, lampiran, akun yang terkena, dan tindakan yang diambil. Dokumentasi ini penting untuk analisa lebih lanjut dan pembelajaran.

5. Komunikasi internal

Beri tahu tim yang terkena dampak tentang cara mengenali pesan serupa ke depan. Jangan menyalahkan pengguna secara terbuka. Fokus pada prosedur pelaporan.

6. Koreksi konfigurasi

Perbaiki kebijakan email, rule filtering, kebijakan kata sandi, atau konfigurasi DMARC jika ternyata ada celah yang memudahkan serangan.

Kebijakan kata sandi dan autentikasi

  • Aktifkan autentikasi multifaktor untuk akun email

  • Gunakan password manager

  • Jangan gunakan kembali password antar layanan

  • Batasi masa aktif sesi

  • Pantau login dari lokasi atau perangkat yang tidak biasa

  • Lakukan revoke akses bagi akun yang tidak aktif

Kesalahan umum email security

Menganggap spam filter cukup

Spam filter membantu, tetapi tidak menangkap spear phishing yang ditargetkan dengan baik.

Mengaktifkan DMARC tanpa memahami aliran email

Jika perusahaan masih mengirim melalui layanan yang tidak mengeluarkan signature DKIM atau spoofed envelope sender yang sah, penerapan DMARC yang terlalu agresif dapat memutus pengiriman penting.

Tidak memperbarui konfigurasi SPF

SPF yang terlalu panjang atau tidak sesuai dengan pengirim yang sah dapat menyebabkan autentikasi gagal.

Menandai semua email eksternal sebagai phishing

Pendekatan yang terlalu agresif dapat membuat tim mengabaikan peringatan yang benar.

Mengabaikan insiden kecil

Banyak pelanggaran besar dimulai dari email yang sedikit aneh, tetapi tidak dilaporkan karena dianggap bukan ancaman besar.

Tools yang umum dipakai

  • Antispam dan antivirus gateway: filter pesan sebelum sampai ke mailbox

  • Mail server dengan built-in filtering: Postfix, Exchange, Zimbra

  • Cloud mail provider: Google Workspace, Microsoft 365

  • Email security gateway khusus: menambah inspeksi lanjutan

  • Sandbox untuk attachment: memisahkan lampiran untuk dianalisis

  • SIEM dan log management: menyusun jejak insiden email

  • Simulator phishing: melatih tim mengenali pola serangan

Tools bukan pengganti kebijakan dan training. Mereka membantu mempercepat deteksi dan merespons, tetapi perilaku pengguna tetap jadi faktor utama.

Perencanaan keamanan email

Langkah yang sebaiknya dilakukan:

  1. Inventaris sumber pengiriman email perusahaan.

  2. Audit record SPF, DKIM, dan DMARC.

  3. Perbaiki konfigurasi yang bermasalah.

  4. Terapkan filtering yang sesuai dengan ukuran organisasi.

  5. Aktifkan MFA untuk semua akun email.

  6. Dokumentasikan prosedur pelaporan dan respons insiden.

  7. Latih pengguna secara berkala.

  8. Pantau log dan lakukan review setelah insiden.

Email security bukan proyek satu kali. Konfigurasi dapat berubah ketika ada layanan baru, pergantian vendor, migrasi mail server, atau perubahan kebijakan perusahaan. Jadwalkan pengecekan berkala minimal beberapa bulan sekali.

Kesimpulan

Email security dimulai dari pemahaman bahwa tidak ada satu lapisan pun yang cukup. Phishing tetap bisa menembus filter jika pengguna tidak dilatih mengenalinya. SPF, DKIM, dan DMARC membantu memastikan autentikasi pengirim, tetapi tidak menutupi risiko lampiran berbahaya, kredensial yang bocor, atau akun yang disusupi.

Perusahaan yang bergantung pada email sebaiknya menggabungkan autentikasi pengirim yang benar, filtering yang disesuaikan, kebijakan akses yang ketat, pelatihan pengguna yang berkelanjutan, dan prosedur respons insiden yang jelas. Kombinasi itu jauh lebih kuat daripada hanya mengandalkan satu produk keamanan.