E-posta karartma: 2026'da etkili yöntemler neler?

• E-posta adreslerini spam toplayıcılardan korumak için çeşitli HTML·CSS·JavaScript karartma teknikleri denenerek engelleme oranları karşılaştırıldı
• 426 metin ve 399 bağlantı örneği üzerinde yapılan testlerde, JS tabanlı tekniklerin çoğu ile CSS·SVG yöntemlerinin 100% engelleme oranına ulaştığı görüldü
• HTML entity'leri ve URL encoding gibi eski yöntemler de hâlâ yüksek düzeyde engelleme etkisi gösterdi
• Buna karşılık görsel olarak gösterme, sembol değiştirme ve metin yönünü ters çevirme gibi yöntemler erişilebilirlik ve kullanılabilirliği ciddi biçimde bozdu
• 2026 itibarıyla JS dönüşümü, AES şifreleme ve kullanıcı etkileşimi tabanlı yöntemler en güvenli ve pratik e-posta koruma araçları olarak değerlendiriliyor

---

E-posta adresi karartma tekniklerinin karşılaştırması (2026 itibarıyla)

• E-posta adreslerini spam toplayıcılardan (harvester) gizlemek için kullanılan çeşitli karartma teknikleri ve her tekniğin gerçek etkisi istatistiklerle sunuluyor
• Her e-posta adresi farklı bir yöntemle korunduktan sonra, 426 (metin) ve 399 (bağlantı) örneği üzerinde toplayıcıların erişip erişemediği ölçülerek engelleme oranı hesaplandı
• JavaScript tabanlı tekniklerin çoğu ve bazı CSS·SVG teknikleri 100% engelleme oranı kaydetti
• HTML entity'leri ve URL encoding gibi eski yöntemler de hâlâ yüksek engelleme oranlarını koruyor
• Bazı teknikler erişilebilirlik veya kullanılabilirliği ciddi biçimde bozduğu için gerçek kullanımda uygun değil

1. Düz metin e-posta koruma teknikleri

• E-posta adresini sayfada doğrudan gösterirken, çeşitli HTML·CSS·JS teknikleriyle toplayıcının bunu okuyamamasını sağlamaya yönelik yöntemler
• Farklı teknikleri birleştirip segment bazında koruma uygulamak etkiyi en üst düzeye çıkarabilir

• Koruma yok (No protection)

  • Engelleme oranı 0% (426 örnekten 0'ı engellendi)
  • E-posta adresi doğrudan açığa çıktığı için tüm toplayıcılar tarafından toplanıyor

• HTML entity'leri (HTML Entities)

  • Engelleme oranı 95%
  • Sunucu tarafı kütüphaneleri bunu otomatik olarak decode etse de, pratikte çoğu toplayıcıyı engelliyor

• HTML yorumları (HTML Comments)

  • Engelleme oranı 99%
  • Yalnızca HTML tag yorumlama kabiliyeti zayıf olan temel toplayıcıları engelleyebiliyor
  • Basit olmasına rağmen hâlâ yüksek engelleme etkisini koruyor

• HTML SVG

  • Engelleme oranı 100%
  • E-posta adresi SVG nesnesi içindeki metin olarak gizleniyor
  • Görme engelli kullanıcılar için screen reader ile erişilebilir
  • <object> öğesinin kullanılması şart; <img> veya inline SVG, kaynak kodun açığa çıkmasına yol açabilir
  • Font bağımlılığı olduğundan web fontu belirtmek gerekiyor

• CSS display:none

  • Engelleme oranı 100%
  • Stil kurallarını uygulayamayan toplayıcıların sınırlamalarından yararlanıyor
  • Erişilebilirlik korunabiliyor; görsel gizleme yerine display:none kullanılması öneriliyor

• JS string birleştirme (Concatenation)

  • Engelleme oranı 100%
  • Harici bağımlılık olmadan kolayca uygulanabiliyor
  • E-postanın tamamı HTML kaynak kodunda bulunduğu için güvenlik açısından zayıf

• JS Rot18

  • Engelleme oranı 100%
  • ROT13'e benzer bir karakter döndürme şifresi kullanıyor
  • Basit toplayıcılar bunu çözemese de, JS'yi yok sayan toplayıcılara karşı zayıf

• JS dönüşümü (Conversion)

  • Engelleme oranı 100%
  • HTML'de yalnızca anlamsız bir string bulunuyor, JS fonksiyonu bunu gerçek e-posta adresine dönüştürüyor
  • Toplayıcıların çoğu DOM'a erişemediği ve JS çalıştıramadığı için geri dönüştüremiyor
  • Basit ama çok etkili bir teknik

• JS AES şifreleme

  • Engelleme oranı 100%
  • E-posta adresi AES-256 şifreleme ile korunuyor
  • Tarayıcının SubtleCrypto API'si kullanılıyor ve yalnızca HTTPS ortamında çalışıyor
  • JS dosyası olmadan şifre çözme mümkün değil

• JS kullanıcı etkileşimi (User interaction)

  • Engelleme oranı 100%
  • E-posta yalnızca kullanıcı sayfayla etkileşime girdiğinde gösteriliyor
  • Toplayıcının DOM çalıştırması + kullanıcı olayı simülasyonu yapması gerektiğinden pratikte mümkün değil

• HTML sembol değiştirme (Symbol substitution)

  • Engelleme oranı 96%
  • AT, DOT gibi ifadelerle değiştirme yapılıyor
  • Kullanıcının bunu elle düzeltmesi gerektiği için kullanılabilirlik düşüyor

• HTML yönergeleri (Instructions)

  • Engelleme oranı 100%
  • E-postaya remove the .fluff gibi manuel yönergeler ekleniyor
  • Bunu yalnızca insanlar veya yapay zeka yorumlayabiliyor, ancak kullanıcı açısından oldukça zahmetli

• HTML görseli

  • Engelleme oranı 100%
  • E-posta adresi bir görsel olarak gösteriliyor
  • Görme engelli kullanıcılar erişemiyor, kopyalanamıyor; yani kullanılabilirlik çöküyor

• CSS content

  • Engelleme oranı 100%
  • E-posta ::after pseudo-element'i ile gösteriliyor
  • Görsel olarak görünse de kopyalanamıyor ve yalnızca HTML üzerinden de geri çıkarılabiliyor
  • İşe yaramayan bir teknik olarak değerlendiriliyor

• CSS metin yönü (Text direction)

  • Engelleme oranı 100%
  • String, direction: rtl ile ters çevriliyor
  • Toplayıcı CSS'yi yok sayarsa kolayca çözülebiliyor
  • Metin ters kopyalandığı için kullanılabilirlik bozuluyor

2. Tıklanabilir bağlantı koruma teknikleri

• mailto: bağlantılarının href niteliğini korumaya yönelik yöntemler
• Bağlantı metninde e-posta yer alıyorsa, ayrıca metin karartma tekniğiyle birlikte kullanmak gerekiyor

• Koruma yok

  • Engelleme oranı 0% (399 örnekten 0'ı engellendi)
  • E-posta adresi tamamen açığa çıkıyor

• HTML entity'leri

  • Engelleme oranı 100%
  • Sunucu tarafında otomatik decode edilmesine rağmen çoğu toplayıcıyı engelliyor

• URL encoding

  • Engelleme oranı 95%
  • Decode edilmesi kolay olsa da, pratikte çoğu toplayıcıyı engelliyor

• HTTP redirect

  • Engelleme oranı 100%
  • mailto: bağlantısı normal bir bağlantı gibi gizleniyor
  • .htaccess içinde 302 veya 301 redirect ayarlanıyor
  • Arama motoru indekslemesini önlemek için nofollow, noindex kullanılıyor
  • E-posta alanlarının otomatik doldurulması için QSA flag'i gerekiyor

• HTML SVG

  • Engelleme oranı 100%
  • E-posta bağlantısı SVG içine gizleniyor
  • Erişilebilirlik korunuyor, <object> kullanımı zorunlu
  • Font belirtmek gerekiyor

• JS string birleştirme

  • Engelleme oranı 100%
  • Harici bağımlılık olmadan uygulanabiliyor
  • E-posta HTML içinde doğrudan yer aldığı için güvenli değil

• JS Rot18

  • Engelleme oranı 99%
  • ROT13'e benzer bir karakter döndürme yöntemi
  • Basit toplayıcılar bunu çözemiyor

• JS dönüşümü (Conversion)

  • Engelleme oranı 100%
  • HTML'de yalnızca sahte bir bağlantı bulunuyor ve JS bunu gerçek mailto: bağlantısına dönüştürüyor
  • Toplayıcı yalnızca HTML'e erişebildiği için geri çıkaramıyor
  • Basit ama çok etkili bir teknik

• JS AES şifreleme

  • Engelleme oranı 100%
  • AES-256 ile şifrelenmiş e-posta bağlantısı
  • Tarayıcının SubtleCrypto API'si kullanılıyor, HTTPS gerekiyor

• JS kullanıcı etkileşimi

  • Engelleme oranı 100%
  • Bağlantı ancak kullanıcı sayfayla etkileşime girdikten sonra etkinleşiyor
  • Toplayıcıların bunu yeniden üretmesi zor

3. Eleştiriler ve karşı argümanlar

• “Spam gönderenler web'i kazımıyor, sızdırılmış veritabanlarını satın alıyor” iddiasına karşı
  • Bu sayfadaki e-posta adresleri yalnızca bu sayfada yayımlanmış olmasına rağmen binlerce spam aldı
• “Koruma gerekmez” iddiasına karşı
  • Popüler içerikler yoğun biçimde toplandığı için viral olma ihtimali düşünülerek koruma gerekli
• “Spam filtresi varsa yeter” iddiasına karşı
  • Bu teknikler yanlış pozitif oluşturmadan ücretsiz uygulanabiliyor; filtrelerle birlikte kullanılması tercih edilmeli
• “Yöntem bilinince işe yaramaz” iddiasına karşı
  • On yıllardır aynı tekniklerin hâlâ etkili olduğu istatistiklerle doğrulanıyor

4. Deney metodolojisi

• Her karartma tekniğiyle korunan e-posta adresleri gerçekten yayımlanarak toplayıcılar için honeypot olarak kullanıldı
• Spam ulaştığında, ilgili adresin koruma tekniğinin aşıldığı kabul edildi
• Mesajlar spam gönderen bazında gruplanarak gönderen sayısına göre istatistik çıkarıldı
• Spam filtrelemenin istatistikleri çarpıtmaması için doğrudan bir posta sunucusu ve istemci kuruldu
• Metin tabanlı ve bağlantı tabanlı toplayıcılar farklı olduğundan istatistikler ayrı tutuldu
• Örneklem sayısı henüz küçük olsa da, bağlantı sayısı arttıkça istatistiklerin güvenilirliğinin artması bekleniyor

Sonuç

• JS tabanlı dönüşüm, şifreleme ve kullanıcı etkileşimi teknikleri en yüksek güvenlik ve erişilebilirlik düzeyini sağlıyor
• CSS display:none ve SVG nesne yöntemi de erişilebilirlik ve engelleme oranı açısından güçlü seçenekler
• Sembol değiştirme, görsel kullanımı ve metin yönünü ters çevirme gibi yöntemler kullanılabilirliği ciddi biçimde bozduğu için önerilmiyor
• E-posta adresini yayımlamak gerekiyorsa, basit bir JS dönüşümü veya AES şifreleme yöntemi 2026 itibarıyla en etkili seçenek olarak öne çıkıyor

[GN⁺]

Hacker News yorumları

• Eskiden e-posta toplama konusuna dikkat ederdim ama artık e-postamı web sitemde açıkça yayınlıyorum
  spam filtreleme yeterince iyi
  Yine de bu teknik inceleme ilgi çekiciydi. Basit yöntemlerin bile oldukça etkili olmasına şaşırdım

  • 2000’lerin başından beri blogumda e-postamı mailto: bağlantısıyla düz metin olarak yayınlıyorum, ama günde sadece birkaç spam geliyor
    Belki Zoho’nun filtrelemesi iyidir ama büyük servislerden özellikle daha iyi olduğunu düşünmüyorum
  • Toplayıcı botların çoğu zaten milyonlarca adres topladığı için birkaç nadir e-postayla uğraşmıyor
    Bu yüzden kendine özgü basit bir yöntem kullanmak sorun olmayabilir, ama bunu paylaşırsan hemen etkisiz hale gelebilir
  • Şirketimin web sitesine e-posta adresimi koyduktan sonra ayda 1.500’den fazla spam almaya başladım
  • Ben de benzer şekilde e-postamı açık ettim ama HTML entity’leri ya da display:none gibi basit yöntemlerle %90’dan fazlası engellenebiliyorsa yeniden düşünmeye değer
  • E-postanın eninde sonunda sızacağını düşünüyorum. Yalnız LLM tabanlı spamin giderek filtreleri aşma ihtimali artıyor gibi görünüyor

• E-posta adresim GitHub’daki popüler açık kaynak depoların commit’lerinde 90’dan fazla kez düz metin olarak yer alıyor
  Ama 8 yıldır neredeyse hiç spam almadım
  < ve > ile çevrili biçim toplayıcıları şaşırtıyor olabilir
  Bugünlerde doğrudan toplamak yerine e-posta listesi satın almak daha yaygın gibi görünüyor

  • Alan adımda wildcard adresler tanımlı
    git@, contact@, admin@ gibi adreslere sık sık spam geliyor
    Son zamanlarda finance@ gibi sahte adreslere CEO taklidi yapan mailler de geliyor
    İşin ironik yanı, HN profilimde düz metin olarak duran e-posta adresime neredeyse hiç spam gelmiyor

• Benim hipotezim, e-posta toplayıcılarının HTML parse etmediği, sadece @ karakterinin etrafındaki dizeleri aradığı yönünde
  HTML parse etmek maliyetli olduğu için böyle basit bir yaklaşım verimli olabilir
  Bu yüzden HTML entity’leri etkili gibi görünüyor

  • Toplayıcılar, obfuscate edilmiş adreslere gönderilen spamlerin düşük yanıt oranına sahip olduğunu öğrenmiş olabilir
    Bu yüzden bu tür adresleri tamamen görmezden geliyor olabilirler
  • Evet, çoğu basit byte araması yapıyor ama black-hat marketing tarafında çeşitli scraping teknikleri de var
  • Sonuçta mesele karşı tarafın ne kadar ısrarcı olduğu. Mantıksız saldırganlar sonuna kadar peşini bırakmaz
  • @ çevresindeki token’lara dayalı çıkarım da küçük değişikliklerle gayet işe yarar

• Yazı iyi yazılmış ama alan adının tamamına sahip olup her alıcıya benzersiz e-posta verme yönteminden bahsetmemesi üzücü
  Spam gelirse sadece o adresi engellersin
  Ya da hiç e-posta kullanmadan yaşamak da mümkün. Bugünlerde çoğu iş geçici e-posta ile halledilebiliyor

  • Ben de 20 yıldır böyle kullanıyorum
    Ama spam’in çoğu arkadaşlarımın ya da ailemin adresimi uygulamalarla paylaşması yüzünden geliyor
    Açık e-posta adreslerini basit bir JavaScript birleştirme yöntemiyle %100 engelleyebildim
  • Eskiden her kişi için ayrı benzersiz e-posta üretmeye çalıştım ama sonunda whitelist tabanlı tek bir adrese sadeleştirdim
    Etkisi benzer ve yönetmesi çok daha kolay

• Web sitesinde gizli bir tarpit e-posta adresi bulundurma yöntemi var
  CSS ile gizleniyor, insanlar görmüyor, bot mail gönderirse ilgili IP 24 saat engelleniyor

  • Ama bu, Google gibi büyük mail sunucularını bile engelleme riski taşıyor
    Çünkü Gmail hesaplarından gelen spam de var, bu yüzden yan etkisi büyük
  • Benzer bir fikir olarak Project Honey Pot var

• İçerik iyi ama başlık için ‘Email address obfuscation’ daha uygun olurdu diye düşünüyorum
  Yine de böyle yazılar görünce spamer’ların da bir şeyler öğrenebileceğini düşünmeden edemiyorum

  • “email” yerine “email address” dememek kafa karıştırıcı. Bağlama göre bu kolayca “e-posta mesajı” olarak da okunabiliyor
  • Greg Egan’ın sitesindeki iletişim bilgisi gösterimi o kadar karmaşıktı ki çözülemedi

• Eskiden “me at foobar dot com” gibi yazımın hâlâ işe yarayıp yaramadığını merak edip test ettim
  LLM kullanarak çeşitli e-posta obfuscation yöntemlerini çözmeyi denedim; CSS veya JS tabanlı olmayanların çoğu yorumlanabiliyordu
  Yine de bugünlerde spam filtreleri iyi çalıştığı için düz metin e-posta yayınlamak büyük sorun olmadı
  Hatta servis bildirim mailleri daha can sıkıcı

  • Daha iyi bir yöntem, ziyaretçinin biraz CPU kullanarak benzersiz token e-postası üretmesi olabilir
    Kötüye kullanım olursa sadece o adresi devre dışı bırakırsın
    İstemci ve mail sunucusu böyle bir API desteklese ideal olurdu
  • LLM tabanlı toplayıcılar, insanlardan bile daha iyi talimat yorumlayabiliyor olabilir
    Bu yüzden basit regex botlarını durduran temel obfuscation hâlâ işe yarıyor diye düşünüyorum
  • Konuyla ilgili xkcd 1808 karikatürü de var

• Bu yılın başında C ile bir Brainfuck interpreter yaparken bunu e-posta obfuscation için denedim
  Her e-postayı bir Brainfuck programı olarak sakladım, JS interpreter da çalıştırıp düz metni gösteriyordu
  JS dış bir alan adından yükleniyordu ve referer doğrulamasından sonra gerçek kod gönderiliyordu
  Elbette JS çalıştıran toplayıcılara karşı işe yaramaz ama yaratıcı bir obfuscation deneyi olarak ilginçti

  • Bu yöntemin, JS içinde sadece XOR şifreleme yapmaktan farkı ne, merak ediyorum
  • Eğer toplayıcı ekran görüntüsünü LLM’e ya da OCR’a verirse bu yöntem etkisiz kalır gibi görünüyor

• Bu yazı biraz da e-posta toplayıcılarını daha akıllı hale getirme rehberi gibi görünüyor

  • Evet ama JS ya da CSS çalıştırmak, SVG render etmek gibi işler hâlâ maliyetli işlemler, bu yüzden büyük ölçekli botlar için yük oluşturuyor