E-Mail-Obfuskation: Was ist 2026 eine wirksame Methode?

• Zum Schutz von E-Mail-Adressen vor Spam-Harvestern wurden verschiedene HTML-, CSS- und JavaScript-Obfuskationstechniken getestet und ihre Blockierungsraten verglichen
• Tests mit 426 Text- und 399 Link-Proben ergaben, dass die meisten JS-basierten sowie CSS- und SVG-Techniken eine Blockierungsrate von 100 % erreichten
• Auch ältere Methoden wie HTML-Entities und URL-Encoding zeigten weiterhin eine hohe Schutzwirkung
• Dagegen beeinträchtigen Bilddarstellung, Symbolersetzung und umgekehrte Textrichtung Zugänglichkeit und Nutzbarkeit erheblich
• Für 2026 werden JS-Konvertierung, AES-Verschlüsselung und nutzerinteraktionsbasierte Verfahren als die sichersten und praktikabelsten Mittel zum Schutz von E-Mail-Adressen bewertet

---

Vergleich von E-Mail-Obfuskationstechniken (Stand 2026)

• Verschiedene Obfuskationstechniken zum Verbergen von E-Mail-Adressen vor Spam-Harvestern werden mit statistischen Ergebnissen zu ihrer tatsächlichen Wirksamkeit vorgestellt
• Nachdem jede E-Mail-Adresse mit einer anderen Methode geschützt wurde, wurde für 426 (Text)- und 399 (Link)-Proben gemessen, ob Harvester darauf zugreifen konnten, und daraus die Blockierungsrate berechnet
• Die meisten JavaScript-basierten Techniken sowie einige CSS- und SVG-Verfahren erreichten eine Blockierungsrate von 100 %
• Auch ältere Methoden wie HTML-Entities und URL-Encoding behalten weiterhin hohe Blockierungsraten
• Einige Verfahren beeinträchtigen die Barrierefreiheit oder Nutzbarkeit so stark, dass sie für den praktischen Einsatz ungeeignet sind

1. Schutztechniken für E-Mail-Adressen als Klartext

• Die E-Mail-Adresse wird direkt auf der Seite angezeigt, aber durch verschiedene HTML-, CSS- und JS-Techniken so dargestellt, dass Harvester sie nicht lesen können
• Durch die Kombination mehrerer Techniken zum Schutz einzelner Segmente lässt sich die Wirkung maximieren

• Kein Schutz (No protection)

  • Blockierungsrate 0 % (0 von 426 blockiert)
  • Die E-Mail-Adresse ist unverändert sichtbar und wird von allen Harvestern gesammelt

• HTML-Entities (HTML Entities)

  • Blockierungsrate 95 %
  • Serverseitige Bibliotheken dekodieren dies zwar oft automatisch, in der Praxis werden aber die meisten Harvester blockiert

• HTML-Kommentare (HTML Comments)

  • Blockierungsrate 99 %
  • Es lassen sich nur einfache Harvester blockieren, die HTML-Tags schlecht interpretieren
  • Einfach, aber weiterhin mit hoher Schutzwirkung

• HTML SVG

  • Blockierungsrate 100 %
  • Die E-Mail-Adresse wird als Text innerhalb eines SVG-Objekts versteckt
  • Für Screenreader zugänglich
  • Die Verwendung des <object>-Elements ist zwingend, bei <img> oder inline-SVG besteht das Risiko, dass die Quelle offengelegt wird
  • Wegen der Font-Abhängigkeit ist die Angabe einer Webfont erforderlich

• CSS display:none

  • Blockierungsrate 100 %
  • Nutzt die Einschränkungen von Harvestern aus, die Stilregeln nicht anwenden können
  • Barrierefreiheit bleibt erhalten; statt rein visueller Verbergung wird display:none empfohlen

• JS-Zeichenkettenverkettung (Concatenation)

  • Blockierungsrate 100 %
  • Einfach ohne externe Abhängigkeiten umsetzbar
  • Die vollständige E-Mail ist im HTML-Quelltext vorhanden und daher sicherheitstechnisch schwach

• JS Rot18

  • Blockierungsrate 100 %
  • Verwendet eine einfache Zeichenrotation ähnlich ROT13
  • Einfache Harvester können dies nicht entschlüsseln, gegen Sammler, die JS ignorieren, ist es jedoch anfällig

• JS-Konvertierung (Conversion)

  • Blockierungsrate 100 %
  • Im HTML steht nur eine bedeutungslose Zeichenfolge, die von einer JS-Funktion in die echte E-Mail umgewandelt wird
  • Da die meisten Harvester weder DOM noch JS ausführen können, ist eine Rekonstruktion praktisch unmöglich
  • Eine einfache und zugleich sehr wirksame Technik

• JS-AES-Verschlüsselung

  • Blockierungsrate 100 %
  • Schutz der E-Mail mittels AES-256-Verschlüsselung
  • Verwendet die SubtleCrypto API des Browsers und funktioniert nur unter HTTPS
  • Ohne die JS-Datei ist keine Entschlüsselung möglich

• JS-Nutzerinteraktion (User interaction)

  • Blockierungsrate 100 %
  • Die E-Mail wird erst angezeigt, wenn der Nutzer mit der Seite interagiert
  • Harvester müssten dafür DOM ausführen und Nutzerevents simulieren, was praktisch kaum möglich ist

• HTML-Symbolersetzung (Symbol substitution)

  • Blockierungsrate 96 %
  • Ersetzungen wie „AT“ und „DOT“
  • Der Nutzer muss die Adresse selbst anpassen, was die Nutzbarkeit verschlechtert

• HTML-Anweisungen (Instructions)

  • Blockierungsrate 100 %
  • Die E-Mail enthält manuelle Hinweise wie „remove the .fluff“
  • Für Menschen oder KI interpretierbar, aber mit hohem Nutzungsaufwand

• HTML-Bild

  • Blockierungsrate 100 %
  • Die E-Mail-Adresse wird als Bild dargestellt
  • Nicht für Sehbehinderte zugänglich, nicht kopierbar usw. — die Nutzbarkeit bricht zusammen

• CSS content

  • Blockierungsrate 100 %
  • Darstellung der E-Mail über das Pseudoelement ::after
  • Sichtbar, aber nicht kopierbar; außerdem allein aus dem HTML rekonstruierbar
  • Wird als nutzlose Technik bewertet

• CSS-Textrichtung (Text direction)

  • Blockierungsrate 100 %
  • Die Zeichenfolge wird mit direction: rtl umgekehrt
  • Wenn Harvester CSS ignorieren, lässt sie sich leicht entschlüsseln
  • Der Text wird rückwärts kopiert, was die Nutzbarkeit verschlechtert

2. Schutztechniken für anklickbare Links

• Schutz des href-Attributs von mailto:-Links
• Wenn der Linktext die E-Mail enthält, ist zusätzlich eine Text-Obfuskationstechnik nötig

• Kein Schutz

  • Blockierungsrate 0 % (0 von 399 blockiert)
  • Die E-Mail-Adresse ist vollständig offengelegt

• HTML-Entities

  • Blockierungsrate 100 %
  • Trotz automatischer serverseitiger Dekodierung werden die meisten Harvester blockiert

• URL-Encoding

  • Blockierungsrate 95 %
  • Leicht zu dekodieren, blockiert in der Praxis aber dennoch die meisten Harvester

• HTTP-Redirect

  • Blockierungsrate 100 %
  • Versteckt den mailto:-Link so, dass er wie ein normaler Link aussieht
  • In .htaccess wird ein Redirect 302 oder 301 konfiguriert
  • Mit nofollow, noindex wird eine Indexierung durch Suchmaschinen verhindert
  • Für das automatische Ausfüllen von Mailfeldern ist das QSA-Flag erforderlich

• HTML SVG

  • Blockierungsrate 100 %
  • Der E-Mail-Link wird innerhalb eines SVG versteckt
  • Barrierefreiheit bleibt erhalten, <object> ist zwingend erforderlich
  • Font-Angabe nötig

• JS-Zeichenkettenverkettung

  • Blockierungsrate 100 %
  • Ohne externe Abhängigkeiten umsetzbar
  • Die E-Mail ist direkt im HTML enthalten und daher nicht sicher

• JS Rot18

  • Blockierungsrate 99 %
  • Zeichenrotation ähnlich ROT13
  • Einfache Harvester können dies nicht entschlüsseln

• JS-Konvertierung (Conversion)

  • Blockierungsrate 100 %
  • Im HTML existiert nur ein falscher Link, den JS in ein echtes mailto: umwandelt
  • Harvester können nur auf HTML zugreifen und den Link daher nicht rekonstruieren
  • Eine einfache und zugleich sehr wirksame Technik

• JS-AES-Verschlüsselung

  • Blockierungsrate 100 %
  • Mit AES-256 verschlüsselter E-Mail-Link
  • Nutzt die SubtleCrypto API des Browsers, HTTPS ist erforderlich

• JS-Nutzerinteraktion

  • Blockierungsrate 100 %
  • Der Link wird erst aktiv, wenn der Nutzer mit der Seite interagiert
  • Für Harvester ist dies schwer nachzubilden

3. Kritik und Gegenargumente

• Zur Behauptung „Spammer crawlen das Web nicht, sondern kaufen geleakte Datenbanken“
  • Die E-Mail-Adressen auf dieser Seite wurden nur auf dieser Seite veröffentlicht und erhielten dennoch tausende Spam-Nachrichten
• Zur Behauptung „Schutz ist nicht nötig“
  • Beliebte Inhalte werden gezielt gesammelt; mit Blick auf virales Potenzial ist Schutz nötig
• Zur Behauptung „Ein Spamfilter reicht aus“
  • Diese Techniken lassen sich kostenlos und ohne Fehlalarme umsetzen; der kombinierte Einsatz mit Filtern ist sinnvoll
• Zur Behauptung „Wenn die Technik bekannt ist, ist sie nutzlos“
  • Die Statistik zeigt, dass dieselben Verfahren seit Jahrzehnten weiterhin wirksam sind

4. Versuchsmethodik

• Mit jeder Obfuskationstechnik geschützte E-Mail-Adressen wurden tatsächlich veröffentlicht und als Honeypot für Harvester betrieben
• Wenn Spam einging, galt die jeweilige Schutztechnik für diese Adresse als überwunden
• Nachrichten wurden nach Spammern gruppiert, um Statistiken auf Basis der Anzahl der Absender zu erstellen
• Damit Spamfilter die Statistik nicht verzerren, wurden eigener Mailserver und eigener Client betrieben
• Da textbasierte und linkbasierte Harvester unterschiedlich arbeiten, wurden getrennte Statistiken geführt
• Die Stichprobe ist noch klein, aber mit zunehmender Zahl von Links dürfte die statistische Aussagekraft steigen

Fazit

• JS-basierte Konvertierungs-, Verschlüsselungs- und Nutzerinteraktionstechniken bieten die höchste Sicherheit und gute Barrierefreiheit
• Auch CSS display:none und die SVG-Objekttechnik sind in Bezug auf Barrierefreiheit und Blockierungsrate stark
• Symbolersetzung, Bilder und umgekehrte Textrichtung sind wegen ihrer starken Beeinträchtigung der Nutzbarkeit nicht zu empfehlen
• Wenn eine E-Mail-Adresse veröffentlicht werden muss, ist eine einfache JS-Konvertierung oder AES-Verschlüsselung nach Stand 2026 die wirksamste Wahl

[GN⁺]

Hacker-News-Kommentare

• Früher habe ich mir Gedanken über das Einsammeln von E-Mail-Adressen gemacht, aber inzwischen veröffentliche ich meine E-Mail einfach auf meiner Website.
  Die Spam-Filterung ist gut genug.
  Trotzdem war dieser Überblick über die Techniken interessant. Ich fand es überraschend, dass auch einfache Methoden ziemlich effektiv sind.

  • Seit den frühen 2000ern habe ich meine E-Mail-Adresse in Klartext mit einem mailto:-Link auf meinem Blog, und ich bekomme nur ein paar Spam-Mails pro Tag.
    Vielleicht liegt es daran, dass Zohos Filterung gut ist, aber ich glaube nicht, dass sie besonders besser ist als bei großen Diensten.
  • Die meisten Sammel-Bots haben ohnehin schon Millionen von Adressen gesammelt, daher kümmern sie sich nicht um ein paar seltene E-Mail-Adressen.
    Deshalb kann man ruhig seine eigene einfache Methode verwenden, aber wenn man sie veröffentlicht, könnte sie sofort wirkungslos werden.
  • Seit ich die E-Mail-Adresse auf der Website meines Unternehmens veröffentlicht habe, bekomme ich mehr als 1.500 Spam-Mails im Monat.
  • Ich habe meine E-Mail-Adresse ähnlich offengelegt, aber wenn sich mit einfachen Methoden wie HTML-Entities oder display:none über 90 % abfangen lassen, wäre es einen erneuten Blick wert.
  • Ich gehe davon aus, dass E-Mail-Adressen irgendwann ohnehin durchsickern. Allerdings dürften LLM-basierte Spam-Mails Filter zunehmend umgehen können.

• Meine E-Mail-Adresse steht in Commits populärer Open-Source-Repositories auf GitHub über 90-mal im Klartext.
  Trotzdem habe ich in acht Jahren fast nie Spam bekommen.
  Das Format mit < und > verwirrt vielleicht die Sammler.
  Heutzutage scheint der Kauf von E-Mail-Listen häufiger zu sein als direktes Sammeln.

  • Auf meiner Domain habe ich Wildcard-Adressen eingerichtet.
    An Adressen wie git@, contact@, admin@ kommt oft Spam.
    In letzter Zeit kommen sogar CEO-Impersonation-Mails an Fake-Adressen wie finance@.
    Ironischerweise bekommt die E-Mail-Adresse, die ich im HN-Profil im Klartext stehen habe, fast keinen Spam.

• Meine Hypothese ist, dass E-Mail-Sammler kein HTML parsen, sondern einfach nur nach Zeichenfolgen rund um das @-Zeichen suchen.
  HTML zu parsen ist teuer, deshalb kann so eine simple Methode effizient sein.
  Deshalb scheinen HTML-Entities wirksam zu sein.

  • Die Sammler könnten gelernt haben, dass Spam an verschleierte Adressen eine niedrige Antwortquote hat.
    Deshalb ignorieren sie solche Adressen vielleicht von vornherein.
  • Ja, die meisten machen nur eine einfache Byte-Suche, aber im Blackhat-Marketing gibt es verschiedene Scraping-Techniken.
  • Am Ende ist es eine Frage, wie hartnäckig der Gegner ist. Irrationale Angreifer lassen nicht locker.
  • Auch tokenbasierte Extraktion rund um das @ funktioniert mit kleinen Abwandlungen ausreichend gut.

• Der Artikel ist gut geschrieben, aber ich finde es schade, dass die Methode nicht erwähnt wird, bei der man die ganze Domain besitzt und jedem Empfänger eine eigene E-Mail-Adresse gibt.
  Wenn Spam kommt, sperrt man einfach nur diese Adresse.
  Oder man lebt gleich ganz ohne E-Mail. Heutzutage lässt sich das meiste mit temporären E-Mail-Adressen lösen.

  • Ich nutze so ein System auch seit 20 Jahren.
    Der Großteil des Spams entsteht aber dadurch, dass Freunde oder Familie meine Adresse in Apps weitergeben.
    Öffentlich sichtbare E-Mail-Adressen konnte ich mit einer einfachen JavaScript-Verknüpfung zu 100 % blockieren.
  • Früher wollte ich für jede Person eine eigene E-Mail-Adresse erzeugen, habe es am Ende aber auf eine einzelne Adresse mit Whitelist vereinfacht.
    Die Wirkung ist ähnlich und die Verwaltung deutlich einfacher.

• Es gibt die Methode, auf einer Website eine Tarpit-E-Mail-Adresse zu verstecken.
  Sie wird per CSS verborgen, sodass Menschen sie nicht sehen, und wenn ein Bot dorthin E-Mails schickt, wird die betreffende IP 24 Stunden lang blockiert.

  • Das birgt allerdings das Risiko, sogar wichtige Mailserver wie Google zu blockieren.
    Da Spam auch von Gmail-Konten kommt, sind die Nebenwirkungen erheblich.
  • Ein ähnliches Konzept ist Project Honey Pot.

• Guter Inhalt, aber ich finde, der Titel „Email address obfuscation“ wäre passender.
  Allerdings könnten auch Spammer aus solchen Artikeln etwas lernen.

  • „email“ statt „email address“ zu schreiben ist verwirrend. Im Kontext liest es sich oft als „E-Mail-Nachricht“.
  • Der Kontakt-Hinweis auf Greg Egans Website war so kryptisch, dass ich ihn nicht entschlüsseln konnte.

• Ich habe früher getestet, ob Formulierungen wie „me at foobar dot com“ noch wirksam sind.
  Als ich mithilfe eines LLM verschiedene Methoden zur E-Mail-Verschleierung auflösen ließ, waren die meisten Varianten interpretierbar, sofern sie nicht auf CSS oder JS basierten.
  Trotzdem funktionieren Spam-Filter heute so gut, dass selbst die Veröffentlichung einer Klartext-Adresse kein großes Problem war.
  Eher lästig sind Service-Benachrichtigungen per E-Mail.

  • Eine bessere Methode wäre, den Besucher ein wenig CPU verwenden zu lassen, um eine E-Mail mit eindeutigem Token zu erzeugen.
    Wenn es Missbrauch gibt, verwirft man einfach nur diese Adresse.
    Ideal wäre es, wenn Client und Mailserver so eine API unterstützen würden.
  • LLM-basierte Sammler könnten Anweisungen besser interpretieren als Menschen.
    Deshalb halte ich grundlegende Verschleierung, die einfache Regex-Bots stoppt, weiterhin für sinnvoll.
  • Dazu gibt es auch den Comic xkcd 1808.

• Anfang des Jahres habe ich beim Bau eines Brainfuck-Interpreters in C versucht, ihn zur E-Mail-Verschleierung zu nutzen.
  Jede E-Mail-Adresse wurde als Brainfuck-Programm gespeichert, und ein JS-Interpreter führte es aus und zeigte den Klartext an.
  Das JS wurde von einer externen Domain geladen und lieferte den eigentlichen Code erst nach Referer-Prüfung aus.
  Gegen Sammler, die JS ausführen, bringt das natürlich nichts, aber als kreatives Experiment zur Verschleierung war es interessant.

  • Ich frage mich, worin der Unterschied zu einer einfachen XOR-Verschlüsselung in JS besteht.
  • Wenn ein Sammler Screenshots an ein LLM oder OCR übergibt, wäre diese Methode wohl wirkungslos.

• Dieser Artikel wirkt teilweise wie eine Anleitung, E-Mail-Sammler intelligenter zu machen.

  • Stimmt, aber JS oder CSS auszuführen oder SVG zu rendern sind weiterhin kostspielige Operationen, die für Bots im großen Maßstab belastend sind.