Obfuscation Email: Metode yang Efektif di 2026?

• Berbagai teknik obfuscation HTML·CSS·JavaScript diuji untuk melindungi alamat email dari pengumpul spam, lalu dibandingkan tingkat pemblokirannya
• Hasil pengujian pada 426 sampel teks dan 399 sampel tautan menunjukkan bahwa sebagian besar teknik berbasis JS·CSS·SVG mencatat tingkat blokir 100%
• Metode lama seperti entitas HTML·encoding URL juga masih menunjukkan efek pemblokiran yang tinggi
• Sebaliknya, penampilan sebagai gambar·substitusi simbol·pembalikan arah teks sangat merusak aksesibilitas dan kegunaan
• Per 2026, konversi JS·enkripsi AES·metode interaksi pengguna dinilai sebagai sarana perlindungan email yang paling aman dan praktis

---

Perbandingan Teknik Obfuscation Alamat Email (per 2026)

• Menyajikan berbagai teknik obfuscation untuk menyembunyikan alamat email dari pengumpul spam (harvester) beserta efektivitas nyatanya dalam bentuk statistik
• Setiap alamat email dilindungi dengan metode berbeda, lalu diukur apakah bisa diakses harvester pada 426 sampel (teks) dan 399 sampel (tautan) untuk menghitung tingkat blokir
• Sebagian besar teknik berbasis JavaScript dan beberapa teknik CSS·SVG mencatat tingkat blokir 100%
• Metode lama seperti entitas HTML·encoding URL juga tetap mempertahankan tingkat blokir tinggi
• Beberapa teknik sangat merusak aksesibilitas atau kegunaan sehingga tidak cocok untuk penggunaan nyata

1. Teknik perlindungan email teks biasa

• Alamat email ditampilkan langsung di halaman, tetapi dibungkus dengan berbagai teknik HTML·CSS·JS agar tidak bisa dibaca harvester
• Efektivitas dapat dimaksimalkan dengan menggabungkan beberapa teknik untuk melindungi tiap segmen

• Tanpa perlindungan (No protection)

  • Tingkat blokir 0% (0 dari 426 pengirim diblokir)
  • Alamat email terekspos apa adanya dan dikumpulkan oleh semua harvester

• Entitas HTML (HTML Entities)

  • Tingkat blokir 95%
  • Library sisi server memang mendekode otomatis, tetapi dalam praktiknya tetap memblokir sebagian besar harvester

• Komentar HTML (HTML Comments)

  • Tingkat blokir 99%
  • Hanya efektif terhadap harvester dasar yang lemah dalam menafsirkan tag HTML
  • Sederhana, tetapi masih mempertahankan efek pemblokiran tinggi

• HTML SVG

  • Tingkat blokir 100%
  • Alamat email disembunyikan sebagai teks di dalam objek SVG
  • Tetap dapat diakses screen reader untuk pengguna tunanetra
  • Wajib memakai elemen <object>, karena <img> atau SVG inline berisiko mengekspos sumber
  • Bergantung pada font, sehingga perlu menentukan web font

• CSS display:none

  • Tingkat blokir 100%
  • Memanfaatkan keterbatasan harvester yang tidak dapat menerapkan aturan style
  • Aksesibilitas tetap terjaga, dan disarankan memakai display:none alih-alih penyembunyian visual lain

• Konkatenasi string JS (Concatenation)

  • Tingkat blokir 100%
  • Mudah diimplementasikan tanpa dependensi eksternal
  • Seluruh email tetap ada di sumber HTML sehingga lemah dari sisi keamanan

• JS Rot18

  • Tingkat blokir 100%
  • Menggunakan sandi rotasi karakter mirip ROT13
  • Harvester sederhana tidak bisa menguraikannya, tetapi rentan terhadap pengumpul yang mengabaikan JS

• Konversi JS (Conversion)

  • Tingkat blokir 100%
  • HTML hanya berisi string tak bermakna, lalu fungsi JS mengubahnya menjadi email sebenarnya
  • Sebagian besar harvester tidak bisa menjalankan DOM·JS sehingga tidak dapat memulihkannya
  • Teknik yang sederhana namun sangat efektif

• Enkripsi AES JS

  • Tingkat blokir 100%
  • Melindungi email dengan enkripsi AES-256
  • Menggunakan SubtleCrypto API di browser dan hanya berfungsi di lingkungan HTTPS
  • Tanpa file JS, dekripsi tidak mungkin dilakukan

• Interaksi pengguna JS (User interaction)

  • Tingkat blokir 100%
  • Email hanya ditampilkan saat pengguna berinteraksi dengan halaman
  • Harvester memerlukan eksekusi DOM + simulasi event pengguna, sehingga secara praktis nyaris mustahil

• Substitusi simbol HTML (Symbol substitution)

  • Tingkat blokir 96%
  • Mengganti dengan “AT”, “DOT”, dan sebagainya
  • Pengguna harus mengoreksi secara manual sehingga kegunaan menurun

• Instruksi HTML (Instructions)

  • Tingkat blokir 100%
  • Menyisipkan instruksi manual seperti “remove the .fluff” di dalam email
  • Bisa dipahami manusia atau AI, tetapi sangat merepotkan pengguna

• Gambar HTML

  • Tingkat blokir 100%
  • Alamat email ditampilkan sebagai gambar
  • Tidak dapat diakses pengguna tunanetra, tidak bisa disalin, dan merusak kegunaan sepenuhnya

• CSS content

  • Tingkat blokir 100%
  • Menampilkan email lewat pseudo-element ::after
  • Secara visual terlihat, tetapi tidak bisa disalin dan bahkan bisa dipulihkan hanya dari HTML
  • Dinilai sebagai teknik yang tidak berguna

• Arah teks CSS (Text direction)

  • Tingkat blokir 100%
  • Membalik string dengan direction: rtl
  • Jika harvester mengabaikan CSS, isinya mudah dibaca kembali
  • Teks tersalin dalam keadaan terbalik sehingga kegunaan menurun

2. Teknik perlindungan tautan yang bisa diklik

• Cara melindungi atribut href pada tautan mailto:
• Jika teks tautan memuat email, perlu juga memakai teknik obfuscation teks secara terpisah

• Tanpa perlindungan

  • Tingkat blokir 0% (0 dari 399 pengirim diblokir)
  • Alamat email sepenuhnya terekspos

• Entitas HTML

  • Tingkat blokir 100%
  • Meski didekode otomatis di sisi server, tetap memblokir sebagian besar harvester

• Encoding URL

  • Tingkat blokir 95%
  • Mudah didekode, tetapi dalam praktiknya tetap memblokir sebagian besar harvester

• Redirect HTTP

  • Tingkat blokir 100%
  • Menyembunyikan tautan mailto: agar tampak seperti tautan biasa
  • Atur redirect 302 atau 301 di .htaccess
  • Cegah pengindeksan mesin pencari dengan nofollow, noindex
  • Perlu flag QSA saat mengisi otomatis field email

• HTML SVG

  • Tingkat blokir 100%
  • Menyembunyikan tautan email di dalam SVG
  • Aksesibilitas tetap terjaga, dan wajib memakai <object>
  • Perlu menentukan font

• Konkatenasi string JS

  • Tingkat blokir 100%
  • Bisa diimplementasikan tanpa dependensi eksternal
  • Tidak aman karena email dimasukkan langsung ke HTML

• JS Rot18

  • Tingkat blokir 99%
  • Rotasi karakter mirip ROT13
  • Harvester sederhana tidak bisa menguraikannya

• Konversi JS (Conversion)

  • Tingkat blokir 100%
  • HTML hanya berisi tautan palsu, lalu JS mengubahnya menjadi mailto: yang sebenarnya
  • Harvester hanya bisa mengakses HTML sehingga tidak dapat memulihkannya
  • Teknik yang sederhana namun sangat efektif

• Enkripsi AES JS

  • Tingkat blokir 100%
  • Tautan email dienkripsi dengan AES-256
  • Menggunakan SubtleCrypto API browser, memerlukan HTTPS

• Interaksi pengguna JS

  • Tingkat blokir 100%
  • Tautan hanya aktif setelah pengguna berinteraksi dengan halaman
  • Sulit bagi harvester untuk mereproduksi hal ini

3. Kritik dan sanggahan

• Soal klaim “spammer tidak mengikis web, mereka membeli database bocor”
  • Alamat email di halaman ini hanya dipublikasikan di halaman ini, tetapi tetap menerima ribuan spam
• Soal klaim “tidak perlu perlindungan”
  • Konten populer lebih intens dikumpulkan, sehingga perlindungan tetap perlu jika mempertimbangkan potensi viral
• Soal klaim “cukup pakai filter spam”
  • Teknik-teknik ini bisa diterapkan gratis tanpa false positive, dan sebaiknya dipakai bersama filter
• Soal klaim “kalau tekniknya diketahui jadi tidak berguna”
  • Statistik menunjukkan teknik yang sama masih efektif bahkan setelah digunakan selama puluhan tahun

4. Metodologi eksperimen

• Alamat email yang dilindungi dengan tiap teknik obfuscation benar-benar dipublikasikan dan dijalankan sebagai honeypot untuk harvester
• Jika spam masuk, teknik perlindungan pada alamat tersebut dianggap berhasil ditembus
• Pesan dikelompokkan per spammer untuk menghasilkan statistik berdasarkan jumlah pengirim
• Agar filter spam tidak mendistorsi statistik, penulis membangun sendiri server mail dan klien
• Karena harvester berbasis teks dan berbasis tautan berbeda, statistik dipisahkan
• Ukuran sampel masih kecil, tetapi reliabilitas statistik diperkirakan meningkat seiring bertambahnya jumlah tautan

Kesimpulan

• Teknik konversi·enkripsi·interaksi pengguna berbasis JS memberikan keamanan dan aksesibilitas tertinggi
• CSS display:none dan teknik objek SVG juga unggul dari sisi aksesibilitas dan tingkat blokir
• Substitusi simbol, gambar, pembalikan arah teks dan sejenisnya tidak direkomendasikan karena sangat merusak kegunaan
• Jika email memang perlu dipublikasikan, konversi JS sederhana atau enkripsi AES adalah pilihan paling efektif per 2026

[GN⁺]

Opini Hacker News

• Dulu saya cukup peduli soal pengumpulan email, tapi sekarang saya malah menaruh email saya begitu saja di situs web saya
  Penyaringan spam sudah cukup bagus
  Meski begitu, ulasan teknik seperti ini tetap menarik. Saya cukup terkejut bahwa cara-cara sederhana pun lumayan efektif

  • Sejak awal 2000-an saya menaruh email saya dalam bentuk teks polos dengan tautan mailto: di blog saya, dan spam yang masuk hanya beberapa email per hari
    Mungkin filtering Zoho memang bagus, tapi saya rasa tidak secara khusus lebih baik daripada layanan besar lain
  • Kebanyakan bot pengumpul sudah punya jutaan alamat, jadi mereka tidak terlalu peduli pada beberapa email langka
    Jadi tidak masalah memakai cara sederhana buatan sendiri, tapi kalau dipublikasikan bisa langsung jadi tidak efektif lagi
  • Setelah saya menaruh email di situs web perusahaan saya, saya menerima lebih dari 1.500 spam per bulan
  • Saya juga sudah lama mempublikasikan email saya, tapi kalau metode sederhana seperti HTML entity atau display:none bisa mencegah lebih dari 90%, mungkin layak dipertimbangkan lagi
  • Saya rasa email pada akhirnya tetap akan bocor. Hanya saja, spam berbasis LLM tampaknya makin mungkin lolos dari filter

• Email saya muncul dalam teks polos lebih dari 90 kali di commit repositori open source populer di GitHub
  Tapi selama 8 tahun saya hampir tidak pernah menerima spam
  Mungkin format yang dibungkus dengan < dan > itu membingungkan pengumpul
  Sekarang tampaknya membeli daftar email lebih umum daripada mengumpulkan sendiri

  • Saya mengatur alamat wildcard di domain saya
    Spam sering datang ke alamat seperti git@, contact@, admin@
    Belakangan ini bahkan ada email penyamaran CEO yang datang ke alamat palsu seperti finance@
    Ironisnya, email yang saya taruh dalam teks polos di profil HN hampir tidak pernah menerima spam

• Hipotesis saya adalah pengumpul email tidak mem-parsing HTML, melainkan hanya mencari string di sekitar karakter @
  Parsing HTML mahal, jadi pendekatan sederhana seperti ini mungkin lebih efisien
  Itu mungkin sebabnya HTML entity cukup efektif

  • Mungkin juga pengumpul belajar bahwa spam yang dikirim ke alamat yang diobfusikasi punya tingkat respons rendah
    Jadi alamat seperti itu mungkin langsung diabaikan
  • Betul, kebanyakan hanya melakukan pencarian byte sederhana, tapi di dunia black-hat marketing ada berbagai teknik scraping
  • Pada akhirnya ini soal seberapa gigih lawannya. Penyerang yang tidak rasional akan terus mengejar sampai akhir
  • Ekstraksi berbasis token di sekitar @ juga masih bisa bekerja dengan sedikit variasi

• Tulisan ini bagus, tapi sayang tidak menyebut metode memiliki seluruh domain lalu memberi email unik untuk tiap penerima
  Kalau spam datang, tinggal blokir alamat itu saja
  Atau bahkan hidup tanpa email sama sekali. Sekarang banyak hal bisa diselesaikan dengan email sementara

  • Saya juga sudah menjalankan cara itu selama 20 tahun
    Tapi sebagian besar spam muncul karena teman atau keluarga membagikan alamat saya ke aplikasi
    Untuk email publik, cara sederhana berupa penyambungan JavaScript bisa mencegahnya 100%
  • Dulu saya mencoba membuat email unik untuk setiap orang, tapi akhirnya disederhanakan menjadi satu alamat berbasis whitelist
    Efeknya mirip dan jauh lebih mudah dikelola

• Ada cara menyembunyikan alamat email tarpit di situs web
  Disembunyikan dengan CSS sehingga manusia tidak melihatnya, lalu jika bot mengirim email ke sana, IP tersebut diblokir selama 24 jam

  • Tapi ini berisiko memblokir server email besar seperti Google
    Karena spam juga bisa datang dari akun Gmail, efek sampingnya cukup besar
  • Konsep serupa juga ada di Project Honey Pot

• Isinya bagus, tapi menurut saya judul yang lebih tepat adalah 'Email address obfuscation'
  Meski begitu, tulisan seperti ini juga bisa jadi bahan belajar bagi para spammer

  • Memakai “email” alih-alih “email address” terasa membingungkan. Dalam konteks tertentu orang bisa membacanya sebagai “pesan email”
  • Bentuk penulisan kontak di situs Greg Egan terlalu rumit sampai-sampai mustahil diuraikan

• Dulu saya penasaran apakah bentuk seperti “me at foobar dot com” masih efektif, jadi saya mengujinya
  Saya memakai LLM untuk memecahkan berbagai cara obfuscation email, dan selain yang berbasis CSS atau JS, kebanyakan bisa ditafsirkan
  Meski begitu, sekarang filter spam bekerja cukup baik sehingga mempublikasikan email dalam teks polos bukan masalah besar
  Justru email notifikasi layanan yang lebih mengganggu

  • Cara yang lebih baik adalah membiarkan pengunjung memakai sedikit CPU untuk membuat email token unik
    Jika ada abuse, alamat itu saja yang dibuang
    Akan ideal jika klien dan server email mendukung API seperti ini
  • Pengumpul berbasis LLM mungkin bisa menafsirkan instruksi lebih baik daripada manusia
    Karena itu, obfuscation dasar untuk menghentikan bot regex sederhana masih tetap berguna
  • Ada juga komik terkait xkcd 1808

• Awal tahun ini saya membuat interpreter Brainfuck dalam C dan sempat memakainya untuk obfuscation email
  Setiap email disimpan sebagai program Brainfuck, lalu interpreter JS menjalankannya untuk menampilkan teks polos
  JS dimuat dari domain eksternal, dan setelah validasi referer baru kode sebenarnya dikirim
  Tentu ini tidak berguna terhadap pengumpul yang menjalankan JS, tapi sebagai eksperimen obfuscation kreatif cukup menarik

  • Saya penasaran apa bedanya pendekatan ini dengan sekadar enkripsi XOR di JS
  • Kalau pengumpul memasukkan screenshot ke LLM atau OCR, cara ini sepertinya akan lumpuh

• Tulisan ini juga terlihat seperti panduan untuk membuat pengumpul email lebih pintar

  • Benar, tapi menjalankan JS atau CSS, merender SVG, dan semacamnya tetap pekerjaan mahal sehingga membebani bot skala besar