Anatomie eines Spam-Filters (Teil 2): Die Filter-Architektur

Das ist der zweite Teil unserer Serie. Wenn du dich verloren fühlst, wirf zuerst einen Blick in Teil 1 und arbeite dich von dort nach oben.

Die meisten Menschen stellen sich einen Spam-Filter als ein einzelnes Stück Software vor: eine Black Box, die E-Mails entgegennimmt, allerlei geheime Logikregeln anwendet und am Ende ein einziges Label ausspuckt, “Spam” oder “kein Spam”. Und sie denken so aus einem Grund: Deliverability-Anbieter lieben es, dieses Bild aufrechtzuerhalten, weil es Angst verbreitet und beim Verkauf von Deliverability-Produkten und Beratungsleistungen hilft.

Unsere mehrjährige Recherche hat jedoch ergeben, dass das weitgehend nicht stimmt. Ja, Spam-Filter haben viele bewegliche Teile und komplexe Wechselwirkungen, aber sie sind meist sehr mechanisch und leicht zu verstehen. Und sobald du weißt, WIE sie funktionieren, wird es einfach, mit den Spam-Filtern zu arbeiten und die Zustellbarkeit zu optimieren, statt gegen sie mit gimmickhaften Katz-und-Maus-Features anzukämpfen (z. B. Multi-Domain-Inbox-Rotation).

In diesem Artikel helfen wir dir zu verstehen, wie Spam-Filter arbeiten, damit wir im nächsten Artikel dieses Wissen nutzen können, um die gängigsten Deliverability-Taktiken am Markt zu bewerten (sowie einige bessere, die weniger bekannt sind).

Die Spam-Filter-Pipeline

Spam-Filter sind kein einzelnes Stück Software, sondern eine Pipeline aus verschiedener Software, die zusammenarbeitet, um unerwünschte E-Mails zu blockieren.

Diese Pipeline zu verstehen ist aus zwei Gründen entscheidend. Erstens, weil sie uns erlaubt, das Deliverability-Problem in kleinere, besser handhabbare Teile zu zerlegen. Zweitens, weil sie uns wertvolle Hinweise auf die inhärenten Einschränkungen gibt, denen Spam-Filter-Betreiber unterliegen und die wir zu unserem Vorteil nutzen können.

Was sind diese Einschränkungen?

Die erste Einschränkung ist Expertise. Wie du unten sehen wirst, erfordert effektives Spam-Filtering Expertenwissen in Netzwerktechnik, Betriebssystemen, Software und KI/ML. Weil kein einzelner Anbieter jemals all diese Bereiche meistern kann, muss der Spam-Filter diese Filtermechanismen als einzelne Module betreiben. Das bedeutet, dass jedes Modul von Natur aus immer nur bestimmte Teile der eingehenden E-Mail betrachtet.

Die zweite Einschränkung ist Kosten. Rund 90 % des gesamten E-Mail-Verkehrs sind heute Spam, was den Betrieb solcher Systeme extrem teuer macht. Ein Pipeline-Ansatz erlaubt es diesen Filtern, Kosten massiv zu senken. Zum Beispiel ist das Nachschlagen einer IP in einer Blocklist auf einer lokalen Firewall extrem günstig und schnell, verglichen mit der Analyse einer E-Mail durch KI. Wir wissen also, dass Spam-Filter solche Prüfungen nach vorne ziehen. Wir wissen außerdem, dass E-Mails, die im Netzwerk-Stack blockiert werden, nie von der Software auf dem Betriebssystem gesehen werden. Wenn wir also bestimmte Deliverability-Probleme debuggen, wissen wir sehr leicht, dass wir nicht gleich eine ganze Domain, Inbox oder IP wegwerfen und bei null anfangen müssen.

Mit diesem Pipeline-Modell im Kopf schauen wir uns die einzelnen Komponenten an.

Ebene 1: Netzwerk-Ebene

Firewall

Der Netzwerk- und Firewall-Stack auf einem Server ist bereits darauf optimiert, Anfragen anhand IP-basierter Regeln zu filtern. Das ist unglaublich ressourceneffizient und die Standardmethode für IP-basierte Blocks.

Bei größeren Systemen gibt es eine Firewall, die vor vielen E-Mail-Servern sitzt. Bei kleineren Systemen betreibt jeder Server seine eigene Firewall, und die sind nicht immer synchronisiert (oder es gibt eine gewisse Verzögerung).

Diese Systeme sind außerdem immer für jeden E-Mail-Anbieter einzigartig, das heißt, in einem hängenzubleiben beeinträchtigt nicht die Zustellbarkeit überall. Außerdem haben diese Filter meist eine “Halbwertszeit”: Du wirst je nach Häufigkeit und Schwere deiner Aktivität wieder entsperrt. Das erklärt einen Teil der Volatilität im Verhalten, die wir bei der Zustellbarkeit zu einem bestimmten Anbieter beobachten.

Verteilte Echtzeit-Blocklists

Realtime Blocklists (RBLs) sind dezentrale Datenbanken, die bestimmte IPs oder Domains auf Basis von Beschwerden auf eine Blacklist setzen. Jeder E-Mail-Server kann diese Datenbanken extrem kosteneffizient per DNS-Lookup abfragen.

Das Problem mit diesen Blacklists ist, dass jeder eine Beschwerde einreichen kann (entweder automatisch vom eigenen Server oder manuell) und es nur sehr begrenzte Kontrolle darüber gibt, ob diese Behauptungen überhaupt legitim sind. Dadurch könntest du hunderttausend E-Mails ohne Probleme versenden, aber ein einziger strenger, schwieriger Lead, der einen schlechten Tag hat, kann dich auf die Blacklist setzen und dir damit die Zustellung an die nächsten hunderttausend Leads blockieren.

Das ist einer der Hauptfaktoren, die Zustellbarkeit sehr zufällig und willkürlich erscheinen lassen, was eine weitere Quelle der Angst ist, die E-Mail-Marketer rund um Deliverability erleben.

Whois-Lookups

Whois-Datenbanken geben uns einfachen Zugriff auf Informationen über Domains, konkret den Registrar und das Alter der Domain. Diese Abfragen sind schnell, einfach und kostenlos.

Auch wenn wir in diesem Bereich keine explizite Forschung betrieben haben, haben wir sehr klar festgestellt, dass wir regelmäßig über verschiedene RBLs gelistet wurden, wenn wir versuchten, von einer weniger als einen Monat alten Domain zu senden. Das ist meist der Grund, warum Sender, die dem Rat “geblockt? Dann neue Domains hochziehen!” folgen, in einer Abwärtsspirale aus Deliverability-Problemen landen.

Geofiltering

Wenn du eine deutsche Werbeagentur bist, die nur mit deutschen Kunden arbeitet, ist die Wahrscheinlichkeit gering, dass du E-Mails aus anderen Ländern bekommst, noch geringer aus anderen Kontinenten und noch geringer aus bestimmten Ländern, die für ein hohes Spam-Volumen bekannt sind.

Geofiltering von Traffic erlaubt es Administratoren, das Verhalten je nach Relevanz der Geografie des Senders zu ändern. Und auch wenn das nach einer sehr willkürlichen Heuristik klingt, haben wir viele Fälle gesehen, in denen ein Wechsel des Standorts das Spam-Filtering für Kunden gelöst hat. Es ist also etwas, das man bei der Planung der Zustellbarkeit nicht übersehen sollte (also Server in der Nähe der Zielkunden nutzen).

Das ist eine weitere Dimension, die die Variabilität erklärt, die man bei der Zustellbarkeit beobachtet.

Infrastruktur-Lookups

Wir können viel über den Inhalt einer E-Mail aus den Eigenschaften der Infrastruktur ableiten, die sie versendet hat. Zum Beispiel durchlaufen E-Mails, die von Gmail oder Outlook kommen, implizit eine gewisse Prüfung, da diese Dienste beide viel proaktives Blocking und Kunden-Vetting betreiben. Außerdem sind E-Mails von legitimen Anbietern, die den Zugang zu Port 25 erschweren (AWS, Azure, GCP), ein positives Signal, während die Nutzung von Anbietern, die diesen Port frei zugänglich machen (Vultr, OVH Cloud usw.), ein negatives Signal ist.

Diese Lookups sind extrem günstig und eine weitere Dimension, die wir die Zustellbarkeit beeinflussen sahen.

NEBENBEMERKUNG: Im Open-Source-Filter SpamAssassin beträgt die Standardgewichtung für einen vertrauenswürdigen Sender (-3) Punkte, was deinen Score oft im Alleingang von einer sehr eindeutigen “Spam”-Zahl auf grenzwertig legitim ziehen kann. Wir glauben, das ist einer der größten Gründe, warum das Senden von Gmail oder Outlook so lange so gut funktioniert hat, selbst als Amateur-Sender Massen-E-Mails verschickten. Heute ist das eindeutig nicht mehr so.

Log-Analyse-Tools

Fast alle E-Mail-Systeme setzen Log-Analyse-Tools ein, um ungewöhnliche Muster zu erkennen und darauf zu reagieren (z. B. Fail2Ban, Datadog).

Die Idee funktioniert so:

1. Du legst eine Reihe von Signalen fest sowie das Volumen dieser Signale, das als “Red Flag” gilt. Zum Beispiel könnten “fehlgeschlagene Login-Versuche, 100-mal in 60 Sekunden von einer einzigen IP” auf einen Brute-Force-Angreifer hindeuten, der versucht, mit hoher Frequenz zufällig Passwörter zu erraten.

2. Die Log-Analyse-Software läuft im Hintergrund und aggregiert die Log-Daten über feste Zeitfenster, um passende Regeln zu finden. Wird eine gefunden, wird die betreffende IP gesperrt.

Ein neuerer, verbesserter Ansatz nutzt “Anomalie-Erkennung”, bei der Logs kontinuierlich von Machine-Learning-Algorithmen analysiert werden, um große Abweichungen in der Aktivität zu erkennen (das ist einer der Gründe, warum das schrittweise Hochfahren des E-Mail-Volumens eine empfohlene Best Practice ist, um diese Anomalie-Erkennungs-Algorithmen zu vermeiden).

Dieser Mechanismus kann oft erklären, warum du anfangs mit hoher Aktivität von einer brandneuen Domain durchkommst und es einen ganzen Tag dauern kann, bis du deine ersten Deliverability-Probleme siehst. Er erklärt auch, warum das Verhalten über verschiedene Anbieter und unterschiedliche Enterprise-E-Mail-Server so unterschiedlich wirken kann, da diese Regeln immer hochgradig anpassbar und leicht zu individualisieren sind.

Ebene 2: E-Mail-Header und Inhalt

DNS-Records

An diesem Punkt sind SPF, DKIM und DMARC das absolute Minimum, das jeder Sender braucht, um überhaupt eine Chance auf Zustellung zu haben (vom primären Posteingang ganz zu schweigen). Die veröffentlichten Standards werden über die Anbieter hinweg immer höher, das wird euch also allen vertraut sein.

Was weniger vertraut sein dürfte, ist die Bedeutung von Reverse DNS. Das ist ein Mapping, das es erlaubt zu bestätigen, dass eine bestimmte IP tatsächlich zur Domain oder zum Host gehört, der im E-Mail-Inhalt angegeben ist. Auch wenn das simpel klingt, schränkt es eine beliebte Inhouse-Sendearchitektur ein, bei der mehrere Domains und IP-Adressen an einen einzigen Server gebunden werden, was viele Experten für Massenversand tun.

Verteilte Inhaltsprüfung

Weit günstiger als die Analyse des rohen E-Mail-Inhalts ist die Erkennung, ob dieselbe E-Mail in hohem Volumen über das Internet “massenversendet” wurde.

Eine Content-Checker-Software wie Pyzor nimmt eine E-Mail, streift sie intelligent herunter (z. B. Anhänge entfernen, Signaturen entfernen) und erzeugt eine einzige Zeichenkette (einen “Hash”), die sich einfach indexieren, zählen und in großem Maßstab abfragen lässt.

Dieses Verhalten erklärt einige verbreitete Cold-E-Mail-Weisheiten*:

• Keine E-Mail-Signaturen hinzufügen: E-Mail-Signaturen sind sehr leicht zu erkennen, ändern sich nie (anders als der E-Mail-Text) und sind oft über viele verschiedene Sende-Accounts hinweg identisch. Damit sind sie ideal, um eine einzelne Person zu erkennen, die über viele Inboxen und Domains hinweg viele E-Mails versendet.

• Spintax hinzufügen: Auch wenn die meisten Content-Checker keine Probleme haben, Spintax zu erkennen und zu berücksichtigen, ist das der Mechanismus, den dieses Feature zu umgehen versucht.

Dieser Mechanismus kann auch erklären, warum so viele unterschiedliche Sende-Konfigurationen zu so unterschiedlichen Ergebnissen bei der Zustellbarkeit führen. Zum Beispiel schwören hochwertige Cold-E-Mail-Sender darauf, dass “Signaturen keine Rolle spielen”, während andere das Gegenteil beteuern.

* Anmerkung: Wir nennen diese als Beispiele, nicht als Empfehlungen. In künftigen Artikeln werden wir untersuchen, wie effektiv diese Weisheiten tatsächlich sind.

Deklarative Inhaltsprüfungen

Es gibt viele fest kodierte Regeln, die Spam-Check-Software über die Jahre aufgebaut hat, um Spam zu erkennen.

• Spam-Keywords/-Themen: “völlig gratis!”, “Angebot nur heute gültig”, “Bitcoin”

• E-Mail-Struktur: versteckte Bild-Pixel für E-Mail-Tracking, ein hohes Verhältnis von Bildern zu Text, kein Text im E-Mail-Body, eine E-Mail mit weniger als 100 Zeichen usw.

Das sind Regeln, die in den meisten Filtern über Jahrzehnte im Kampf gegen diverse Scam-Kampagnen aufgebaut wurden. Und wenn man tief einsteigt, sieht man sehr leicht, wie legitimer Cold-E-Mail-Traffic mit Spam verwechselt werden kann (zum Beispiel das Versprechen, einem Interessenten mit deiner SaaS “Millionen zu sparen”, versus das Versprechen, ihm über einen Betrug “Millionen zu machen”).

Diese Regeln unterscheiden sich stark je nach eingesetzter Software (z. B. Barracuda vs. SpamAssassin), was die Volatilität, die wir bei Deliverability-Ergebnissen sehen, weiter erklären kann.

KI-/ML-basierte Inhaltsprüfungen

Die letzte Inhaltsprüfung besteht darin, ML-/KI-Modelle die gesamte Nachricht betrachten zu lassen und einen Prognose-Score zu erzeugen, ob eine bestimmte E-Mail Spam ist oder nicht. Das wird wahrscheinlich mehrere Scores erzeugen, die die bisherige Posteingangs-Aktivität des Nutzers, die Aktivität über verschiedene E-Mail-Mandanten hinweg usw. berücksichtigen.

Diese Ebene erzeugt mehrere Schichten von Variabilität beim Testen der Posteingangs-Platzierung, wegen der Individualisierung auf Nutzerebene rund um Spam- und Inbox-Regeln (zum Beispiel habe ich so viel Spam gemeldet, dass Gmail mir seit über zwei Jahren keine SDR-E-Mail mehr angezeigt hat). Das erfordert daher sehr sorgfältige Planung.

Ebene 3: Menschliches Feedback

Spam-Meldungen

Nichts hat größeren Einfluss darauf, wie deine E-Mails zugestellt werden, als jemand, der auf “Als Spam melden” drückt. Für Empfänger ist das eine recht große Sache, denn es impliziert, dass sie nie wieder von diesem Sender hören wollen, was für niemanden typisch ist, der eine echte Beziehung zum Sender hat (wenn ich z. B. ein Konto bei meiner Bank habe und sie mir eine E-Mail von einem Vermögensberater schickt, den ich nicht mag, würde ich das niemals als Spam melden, um keine legitime E-Mail meines Anbieters zu verpassen).

Als Spam gemeldet zu werden ist ein nukleares Ereignis, das um jeden Preis zu vermeiden ist. Leider gilt diese Meldung, ähnlich wie bei den RBLs, verteilt über alle E-Mail-Empfänger, wobei sie eine relative Gewichtung je nach Empfänger zu haben scheint (das ist an diesem Punkt nicht abschließend geklärt, wir planen dazu eine künftige Studie).

Kontaktlisten

Einen Sender zu einer Kontaktliste hinzuzufügen setzt den Sender auf eine dauerhafte Whitelist auf Nutzerebene. Das passiert, wenn der Nutzer einen Kontakt anlegt oder einmal auf eine E-Mail des Senders antwortet.

Das macht das Testen der Zustellbarkeit besonders schwierig. Sobald eine E-Mail einmal gegen eine Inbox auf Zustellung und Platzierung getestet wurde, kann sie nie wieder wirklich auf dieselbe Weise gegen dieselbe Inbox oder Domain getestet werden, was die volatile Erfahrung, die Sender mit E-Mail-Zustellbarkeit machen, weiter verstärkt.

Wie man die Komplexität in den Griff bekommt

Wenn du bis hierhin gekommen bist, fühlst du dich vielleicht überfordert.

• Es gibt so viele Komponenten.

• Viele Komponenten interagieren miteinander, was viele Permutationen bedeutet, über die man nachdenken muss.

• Das wird in einem verteilten System noch komplexer (z. B. betreibt Gmail unterschiedliche E-Mail-Server in unterschiedlichen Rechenzentren).

• Das wird noch komplexer, wenn dir klar wird, dass verschiedene Anbieter Informationen teilen (z. B. Blacklists).

Du fragst dich vielleicht: “Wie um alles in der Welt baue ich ein System, das all das berücksichtigt?” Oder: “Wenn etwas schiefgeht, wo fange ich überhaupt mit dem Debuggen an?”

So haben wir uns auch gefühlt. Aber zum Glück stellt sich heraus, wenn man all diese Teile zusammenführt, dass es nur eine Handvoll optimaler Architekturen für den Cold-E-Mail-Versand gibt, die gut funktionieren.

In Teil 3 besprechen wir drei Architekturen und Ansätze, mit denen du Outbound mit vernünftig hoher Zuverlässigkeit umsetzen kannst, samt der vielen damit verbundenen Trade-offs.