Erfahren Sie, wie Sie einen E‑Mail‑Risiko‑Score entwerfen, indem Sie Syntax, Domain‑Gesundheit, Wegwerf‑Flags und vergangene Ergebnisse zu einer einfachen, praxisnahen Rubrik kombinieren.
Ein E‑Mail‑Risiko‑Score ist eine kurze Zusammenfassung, wie wahrscheinlich es ist, dass eine Adresse Probleme verursacht, z. B. Bounces, gefälschte Anmeldungen oder Missbrauch. Er hilft, konsistente Entscheidungen zu treffen, wenn eine einfache Bestandsaufnahme „gültig/ungültig“ nicht ausreicht.
E‑Mail‑Validierung beantwortet „Kann diese E‑Mail wahrscheinlich E‑Mails empfangen?“, während ein Risiko‑Score fragt „Wie riskant ist es, diese Anmeldung jetzt zu akzeptieren?“. Eine Adresse kann zustellbar wirken, aber trotzdem riskant sein, weil sie wegwerfbar ist oder Mustern entspricht, die mit Missbrauch verbunden sind.
Fangen Sie mit einer kleinen, leicht erklärbaren Menge an Signalen an: RFC‑konforme Syntaxprüfung, ob die Domain auflöst, ob MX‑Einträge vorhanden sind und ob die Adresse bekannten Wegwerf‑Anbietern entspricht. Fügen Sie historische Ergebnisse hinzu, sobald Sie messen können, was nach der Anmeldung tatsächlich passiert.
Verwenden Sie ein paar klare Bänder, die an Aktionen geknüpft sind, z. B. erlauben, erlauben mit Verifikation und blockieren/prüfen. Halten Sie die Bänder anfangs stabil und passen Sie die Schwellenwerte dann basierend auf beobachteten Ergebnissen wie Bounce‑Rate, Beschwerden oder Missbrauchsereignissen an.
Speichern Sie eine kurze Begründung zusammen mit dem Score, z. B. „Wegwerf‑Provider“ oder „Domain kann keine Mails empfangen“. Wenn ein Kollege nicht in einem Satz sagen kann: „Warum haben wir das blockiert?“, ist das System zu schwer zu bedienen.
Behandeln Sie Timeouts als „unbekannt“ und versuchen Sie eine einmalige Wiederholung, bevor Sie bewerten. Wenn es danach noch unbekannt ist, fügen Sie eine kleine Strafe hinzu statt es als festen Ausfall zu werten — temporäre DNS‑Probleme sollten echte Nutzer nicht dauerhaft als hochriskant kennzeichnen.
Die Erkennung von Wegwerfadressen ist sehr nützlich, sollte aber nicht automatisch „block“ bedeuten. Ein gängiger Ansatz ist, den Score zu erhöhen und eine E‑Mail‑Verifikation oder Einschränkungen für hochpreisige Aktionen zu verlangen. Passen Sie das je nach Konversions‑ und Missbrauchsdaten an.
Zustellbarkeitsrisiko betrifft Erreichbarkeit und Bounces; Betrugsrisiko betrifft schädliches Verhalten wie Rückbuchungen oder Coupon‑Missbrauch. Wenn Sie beides ohne Kennzeichnung mischen, gibt es Diskussionen darüber, was die Zahl bedeutet. Halten Sie daher zwei Scores oder benennen Sie klar, wofür der einzelne Score steht.
Protokollieren Sie die Eingaben, auf die Sie sich gestützt haben, den endgültigen Score, das Band, die getroffene Aktion und eine kurze Begründung, damit Sie Entscheidungen später debuggen können. Beschränken Sie die Aufbewahrung und den Zugriff, da E‑Mail‑Logs sensibel sind; speichern Sie nur das, was für Betrieb und Messung nötig ist.
Tunen Sie anhand von Ergebnissen, nicht nach Bauchgefühl: Prüfen Sie, ob Hochrisiko‑Anmeldungen tatsächlich schlechtere Bounce‑ oder Missbrauchswerte haben als Niedrigrisiko. Ändern Sie immer nur eine Sache auf einmal — oft ist das nur die Schwelle — und vergleichen Sie die Folgen mit einem kleinen Holdout oder A/B‑Test, damit Sie die Trade‑offs zwischen falschen Sperrungen und verhinderter Missbrauch sehen.
Ein E‑Mail‑Risiko‑Score ist eine einfache Zahl (oder ein Label wie niedrig, mittel, hoch), die abschätzt, wie wahrscheinlich es ist, dass eine E‑Mail‑Adresse Probleme für Ihr Unternehmen verursacht. „Probleme“ bedeutet meist gefälschte Anmeldungen, Bounces, Spam‑Beschwerden oder Nutzer, die Sie später nicht mehr erreichen können.
Es ist kein Urteil darüber, ob jemand „gut“ oder „schlecht“ ist. Es ist eine schnelle, konsistente Zusammenfassung von Signalen, die Sie ohnehin haben.
Ein Score hilft, wenn ein pass/fail‑Ansatz zu grob ist. Viele Adressen sehen oberflächlich gültig aus, tragen aber dennoch ein Risiko. Eine E‑Mail kann korrekte Syntax und eine echte Domain haben, trotzdem aber wegwerfbar, falsch konfiguriert oder mit Mustern verknüpft sein, die zuvor zu Missbrauch führten.
Mit einem Risiko‑Score können Sie konsistente Entscheidungen treffen, ohne jede Grenzfall‑Diskussion. Typische Maßnahmen sind:
Erklärbarkeit ist wichtig. Nicht‑technische Teams sollten die Frage „Warum war das hochriskant?“ beantworten können. Streben Sie einfache Gründe an wie „Wegwerf‑Provider“, „Domain kann keine Mails empfangen“ oder „Domain‑Checks fehlgeschlagen“.
Eine einfache Methode, alle auf denselben Stand zu bringen, ist, jede Score‑Band an eine klare Policy zu binden. Zum Beispiel: 0–30 bedeutet geringes Risiko und automatische Freigabe, 31–70 bedeutet moderates Risiko und Verifikation erforderlich, 71–100 bedeutet hohes Risiko und Blocken oder Prüfung. Ziel ist keine perfekte Zahl, sondern eine erklärbare, messbare und anpassbare Entscheidung.
Beginnen Sie mit einer kleinen Menge an Signalen, die leicht zu erklären und schwer zu manipulieren sind. Sie können später immer weitere hinzufügen.
Starten Sie mit strengen Syntaxprüfungen. Das ist mehr als „hat ein @“. RFC‑artige Parser finden fehlende Teile, illegale Zeichen, doppelte Punkte und knifflige Formate, die viele Systeme falsch behandeln. Syntaxprüfungen sind günstig und stoppen offensichtlichen Müll früh, sagen aber nichts darüber, ob das Postfach tatsächlich E‑Mails empfangen kann.
Prüfen Sie als Nächstes die Domain‑Gesundheit. Zwei Prüfungen erledigen den Großteil der Arbeit: existiert die Domain (DNS löst auf) und veröffentlicht sie MX‑Einträge. MX ist nicht perfekt (einige Domains akzeptieren Mail ohne MX), aber es ist ein starkes Indiz für Erreichbarkeit. Eine brandneue Domain ohne Mail‑Setup ist bei der Anmeldung oft riskanter.
Wegwerf‑Provider‑Flags sind bei der Kontoerstellung besonders wichtig. Wegwerf‑Postfächer tauchen bei Missbrauch während Testphasen, Couponjagd und gefälschten Leads auf. Sie müssen diese Adressen nicht immer blockieren, aber Sie sollten sie bewerten.
Sie können auch Reputations‑ähnliche Signale einbeziehen, aber mit Bedacht. Blocklisten und Spam‑Trap‑Indikatoren können Bounces reduzieren, aber es gibt False‑Positives. Behandeln Sie sie als Hinweise mit hoher Vertrauenswürdigkeit und bevorzugen Sie weichere Maßnahmen (zusätzliche Verifikation) gegenüber harten Blocks.
Schließlich fügen Sie Kontext hinzu, den Sie sowieso haben. E‑Mail allein erzählt selten die ganze Geschichte. Nützliche Eingaben sind z. B. Herkunft der Anmeldung, ungewöhnliche Anmeldegeschwindigkeit, wiederkehrende Muster und was bei ähnlichen Anmeldungen zuvor passiert ist.
Beispiel: Während einer Aktion ist eine syntaktisch gültige Adresse auf einer Domain ohne MX plus Wegwerf‑Flag und hoher Anmeldegeschwindigkeit ein stärkeres Signal als jede einzelne Prüfung für sich.
Ein Risiko‑Score funktioniert nur, wenn alle sich darüber einig sind, was „Risiko“ bedeutet. Schreiben Sie zuerst die Entscheidung auf, die er unterstützen soll. Möchten Sie schlechte Anmeldungen blockieren, Bounces reduzieren oder den Supportaufwand senken? Wenn der Score versucht, alles auf einmal zu tun, wird er unübersichtlich und schwer zu justieren.
Diese sind verwandt, aber nicht dasselbe.
Zustellbarkeitsrisiko betrifft, ob Sie die Adresse erreichen können. Es spiegelt sich in Ergebnissen wie harten Bounces, wiederholten Soft‑Bounces oder Schaden an der Absenderreputation wider.
Betrugs‑ oder Missbrauchsrisiko betrifft den Nutzer hinter der Adresse. Es bildet sich ab in Ergebnissen wie Rückbuchungen, Coupon‑Missbrauch, gefälschten Konten, Spam‑Meldungen oder ungewöhnlich geringem Lifetime‑Wert.
Sie können das auf zwei einfache Arten handhaben: zwei getrennte Scores führen, oder einen Score verwenden, diesen aber klar benennen (z. B. „Anmelde‑Missbrauchsrisiko“).
Wählen Sie ein primäres Ergebnis, das der Score vorhersagen soll, und fügen Sie danach sekundäre hinzu. Gute Startziele sind z. B.:
Entscheiden Sie dann, was ein False Positive Sie kostet. Wenn Sie einen echten Kunden blockieren, verlieren Sie Umsatz und Vertrauen. Wenn Sie eine riskante Anmeldung durchlassen, zahlen Sie vielleicht mit Rückbuchungen, Supportzeit oder Zustellbarkeitsproblemen. Ihre Toleranz gegenüber diesen Kompromissen sollte die Schwellenwerte bestimmen.
Zuletzt wählen Sie eine Score‑Skala und deren Bedeutung. Eine 0–100‑Skala ist leicht zu kommunizieren, aber nur, wenn Sie Bänder wie 0–24 niedrig, 25–59 mittel, 60–100 hoch definieren. Verbinden Sie jedes Band mit einer Aktion, damit der Score mehr als eine Zahl ist.
Ein Risiko‑Score ist nur nützlich, wenn Leute ihm vertrauen. Das bedeutet, dass Sie zwei Fragen in einfachen Worten beantworten können sollten: Warum hat diese Anmeldung diesen Score bekommen und was sollten wir als Nächstes tun?
Eine punktbasierte Rubrik ist normalerweise der einfachste Einstieg. Sie verhält sich wie eine Checkliste mit einer Gesamtsumme und ist leicht in eine Policy‑Dokumentation zu schreiben. Ein gewichteter Durchschnitt oder ein kleines Modell kann präziser sein, ist aber schwerer zu erklären, wenn jemand fragt: „Warum wurde das blockiert?“
Hier ein einfacher Gewichtungsansatz mit vier Kernsignalen. Halten Sie die Mathematik langweilig und die Ergebnisse klar:
Das ergibt 100. In diesem Setup bedeutet ein höherer Score höheres Risiko.
Fehlende Daten werden vorkommen, besonders bei DNS‑Timeouts oder temporären Lookup‑Fehlern. Entscheiden Sie vorher, ob „unbekannt“ neutral, leicht riskant oder ein Grund für einen Retry sein soll:
Kalibrieren Sie für Ihr Produkt. Ein B2B‑Einladungsfluss kann strenger bei Domain‑Gesundheit und MX sein (Firmen‑E‑Mails werden erwartet). Ein Consumer‑Signup kann mehr freie E‑Mail‑Domains zulassen, sollte aber bei Wegwerf‑Flags härter sein.
Ein guter Score beginnt damit, unordentliche Signale vergleichbar zu machen. Versuchen Sie nicht, jedes kleine Detail zu bewerten. Konvertieren Sie jedes Signal in ein paar klare Buckets, die ein nicht‑technischer Kollege erkennen und erklären kann.
Wählen Sie 3 bis 4 Buckets pro Signal. Zum Beispiel: Syntax (gültig, fragwürdig, ungültig), Domain‑Gesundheit (gesund, unbekannt, kaputt), Wegwerf‑Flag (nein, vielleicht, ja) und historische Ergebnisse (gute Historie, gemischt, schlecht). Halten Sie die Bucket‑Namen einfach.
Dann weisen Sie Punkte mit einem einfachen Muster zu: gut = wenige Punkte, unsicher = mittlere, schlecht = viele. Wenn Wegwerf‑E‑Mails bei Ihnen die Hauptursache für Missbrauch sind, geben Sie diesem Signal mehr Gewicht als kleinen Syntax‑Fehlern.
Ein praktischer Ablauf:
Der Score zählt nur, wenn er eine konsistente Aktion auslöst. Halten Sie die Bänder wenige und offensichtlich:
Protokollierung ist kein Optional. Speichern Sie die Input‑Buckets (nicht nur den finalen Score) und die getroffene Aktion. Wenn Sie eine E‑Mail‑Validierungs‑API verwenden, speichern Sie die Schlüssel‑Ergebnisse, auf die Sie sich gestützt haben, damit Sie Scores später mit echten Outcomes vergleichen können.
Ein einfacher E‑Mail‑Risiko‑Score funktioniert am besten, wenn er leicht Support, Fraud und Marketing erklärt werden kann. Beginnen Sie bei 0 Punkten (niedrigstes Risiko) und addieren Sie Punkte, wenn ein Signal die Wahrscheinlichkeit erhöht, dass die Adresse bounce‑t, gefälscht ist oder zu Missbrauch führt.
| Signal (aus Ihren E‑Mail‑Validierungssignalen) | Regel | Punkte |
|---|---|---|
| Syntax | RFC‑konform | +0 |
| Syntax | Ungültig oder verdächtig (extra Punkte, schlechtes Quoting) | +40 |
| Domain existiert | Domain löst auf | +0 |
| Domain existiert | NXDOMAIN / nicht auflösbar | +30 |
| MX‑Einträge | MX vorhanden | +0 |
| MX‑Einträge | Kein MX | +25 |
| Wegwerf‑Flag | Nicht wegwerfbar | +0 |
| Wegwerf‑Flag | Wegwerf-/temporärer Anbieter | +35 |
| Domain‑Gesundheit | Normale Sender‑Domain‑Reputation | +0 |
| Domain‑Gesundheit | Neu entdeckt oder hohe Beschwerderate | +15 |
| Historische Ergebnisse | Frühere Bounces für diese Domain/Pattern | +20 |
Edge‑Case‑Hinweis: Wenn die Syntax gültig ist und die Domain auflöst, aber kein MX vorhanden ist, behandeln Sie das standardmäßig als mittleres Risiko, nicht als automatisches Block. Manche Domains sind temporär falsch konfiguriert, und Sie möchten keine echten Nutzer unnötig ablehnen.
Um die Rubrik stabil zu halten, begrenzen Sie den Einfluss neuer Signale (z. B. +10 bis +15) und ändern Sie Schwellen nur nach Vorliegen von Outcome‑Daten.
Eine große Promo kann Ihren Traffic über Nacht verändern. Sie erhalten mehr echte Kunden, ziehen aber auch Bots, Couponjäger und Nutzer mit Wegwerf‑Adressen an, die das Angebot abgreifen und verschwinden. Ein Risiko‑Score hilft zu entscheiden, wer reibungslos anmelden darf und wer eine Zusatzprüfung erhalten soll.
Angenommen, Ihre Scales sind 0–100 (höher = riskanter). Sie führen Validierungs‑Signale (Syntax, Domain‑ und MX‑Checks, Wegwerf‑Flags und eigene Vergangenheitsdaten) durch eine Pipeline und weisen dann Punkte zu.
Hier zwei Anmeldungen aus derselben Kampagne:
| E‑Mail | Signalzusammenfassung | Punkte | Gesamt | Entscheidung |
|---|---|---|---|---|
| [email protected] | Saubere Syntax, Domain löst auf, MX vorhanden, nicht wegwerfbar, Domain hat geringe Bounce‑Historie | +0, +0, +0, +0, +5 | 5 | Erlauben, ohne Reibung |
| dealhunter923@mailbox‑now.xyz | Syntax OK, Domain löst auf, MX vorhanden, Wegwerf‑Flag, Domain hat hohe Bounce‑ und Beschwerderaten | +0, +0, +0, +40, +35 | 75 | Verifikation hinzufügen |
Bei der zweiten Anmeldung kann „Verifikation hinzufügen“ leichtgewichtig sein: E‑Mail‑OTP, Magic Link oder eine Verifikation, bevor der Promo‑Wert eingelöst wird. Sie blocken nicht pauschal — Sie setzen nur dort Bremsen, wo die Signale es rechtfertigen.
Passen Sie Gewichte im Zeitverlauf mit realen Outcomes an, nicht nach Bauchgefühl. Wenn wegwerf‑gekennzeichnete E‑Mails trotzdem konvertieren und aktiv bleiben, reduzieren Sie diese Strafe. Wenn eine bestimmte Domain weiterhin Bounces, Rückbuchungen oder Beschwerden produziert, erhöhen Sie die Domain‑Historie‑Punkte.
Der schnellste Weg, Vertrauen in einen Risiko‑Score zu verlieren, ist, ein Signal als endgültiges Urteil zu behandeln. E‑Mail‑Signale sind unordentlich: Netzwerke haben Aussetzer, Domains werden falsch konfiguriert und echte Menschen nutzen manchmal Adressen, die verdächtig aussehen.
Wegwerf‑Erkennung ist nützlich, aber nicht gleichbedeutend mit Betrug. Wenn Sie das zu stark gewichten, blockieren Sie echte Nutzer, die Privatsphäre wünschen oder nur eine kurze Testphase wollen. Sicherer ist es, es stark zu bewerten und mit Kontext zu koppeln, wie Anmeldegeschwindigkeit, Zahlungsabsicht oder ob die Adresse Domain‑ und MX‑Checks besteht.
DNS‑Timeouts passieren. Bewerten Sie einen Timeout nicht gleich wie „Domain existiert nicht“. Halten Sie einen eigenen Bucket für „jetzt unbekannt“, wiederholen Sie einmal und erhöhen Sie das Risiko nur leicht, sofern andere Signale nicht zustimmen.
Es ist leicht, dieselbe Idee mehrfach zu zählen. Zum Beispiel „kein MX‑Eintrag“ und „Domain‑Verifikation fehlgeschlagen“ können zwei Sichten desselben Problems sein. Wenn Sie beide mit vollem Gewicht addieren, erhöhen Sie das Risiko ohne Genauigkeitsgewinn. Wählen Sie die klarste Sicht oder reduzieren Sie die Gewichte bei Überlappung.
Mit Kampagnenänderungen und Anpassungen der Angreifer stimmen die alten Gewichte irgendwann nicht mehr. Überprüfen Sie Outcomes (Bounces, Beschwerden, Rückbuchungen, Aktivierungsraten) regelmäßig und achten Sie auf plötzliche Verschiebungen.
Halten Sie Tests und Staging getrennt. Testdaten wie [email protected], QA‑Skripte und interne Domains können Ihre „gut vs. schlecht“‑Outcomes verfälschen.
Eine praktische Checkliste zur Vermeidung:
Ein Score ist nur nützlich, wenn er spätere Ereignisse vorhersagt. Behandeln Sie Ihren Risiko‑Score wie eine Prognose, die Sie überprüfen können.
Sammeln Sie Outcomes, die an die Anmeldung gebunden sind: zugestellt vs. gebounced, Beschwerden, Konto‑Missbrauch, Rückbuchungen, Support‑Flags und bestätigter Betrug.
Wählen Sie einige Score‑Bänder (z. B. Niedrig, Mittel, Hoch) und prüfen Sie diese in festen Abständen. Wöchentlich reicht anfangs; bei großen Kampagnen oder Policy‑Änderungen kann tägliche Kontrolle sinnvoll sein.
Suchen Sie nach Trennung: Hochrisiko sollte deutlich schlechtere Outcomes haben als Niedrigrisiko. Messen Sie konsistent einige Metriken:
Wenn die Bänder ähnlich aussehen, bringen die Signale nicht genug Information oder Ihre Schwellen sind falsch. Beispiel: Wenn „Hoch“ die gleiche Bounce‑Rate wie „Niedrig“ hat, gewichten Sie harmlose Signale zu stark oder starke Signale zu schwach.
Ändern Sie eine Sache auf einmal und machen Sie sie messbar. Der sicherste Stellhebel ist meist die Schwelle, nicht das ganze Modell.
Führen Sie einen A/B‑Test oder ein kleines Holdout durch, bevor Sie neue Cutoffs ausrollen. Beispiel: Blockieren Sie in der Testgruppe eine Woche lang nur das oberste 1% der riskantesten Anmeldungen, während die Kontrolle Ihre aktuelle Policy nutzt. Vergleichen Sie Bounce‑, Missbrauchs‑ und Verlustraten bei echten Nutzern.
Die meisten Probleme bei der Einführung kommen von unklaren Aktionen, fehlenden Guardrails oder verrauschten Eingaben.
Ordnen Sie nun den Score einer Aktion zu. Wenn zwei Personen in Ihrem Team bei demselben Score unterschiedliche Aktionen wählen würden, ist die Policy noch nicht einsatzbereit.
Wenn Sie während Kampagnen ein viertes Band brauchen, fügen Sie es explizit hinzu (und halten Sie es operativ einfach): sehr hohes Risiko kann gedrosselt oder geblockt werden.
Eine Rubrik hilft nur, wenn Sie sie täglich betreiben können. Behandeln Sie Ihren Risiko‑Score wie jedes andere Entscheidungssystem: protokollieren Sie genug, um zu debuggen, erklären Sie ihn Menschen und sorgen Sie für Stabilität unter Real‑Traffic.
Beginnen Sie mit Logging, sodass Sie jede Anmeldung reproduzieren können. Erfassen Sie die Roh‑Eingaben (Syntax‑Ergebnis, Domain/MX‑Checks, Wegwerf‑Flag, Blocklisten‑Treffer), den finalen Score und die getroffene Aktion (erlauben, Reibung, Prüfung, blockieren). Speichern Sie eine Request‑ID, damit der Support die vollständige Historie schnell findet.
Machen Sie den Score in einfachen Worten erklärbar. Neben der Zahl speichern Sie eine kurze Begründung, die in fünf Sekunden lesbar ist. Beispiel: „Wegwerf‑Provider + fehlende MX‑Prüfung, Score 82, geblockt."
E‑Mail‑Prüfungen können aus Gründen fehlschlagen, die nichts mit dem Nutzer zu tun haben. Planen Sie für Timeouts, begrenzte Retries, Ratenbegrenzungen und sichere Fallbacks. Wenn Prüfungen fehlschlagen, geben Sie einen konservativen „unbekannt“‑Status zurück, statt den Score springen zu lassen.
E‑Mail‑Logs sind sensibel. Bewahren Sie nur das Nötigste auf, beschränken Sie den Zugriff und setzen Sie eine Aufbewahrungsfrist (z. B. 30–90 Tage für Rohsignale). Für längerfristige Analysen speichern Sie Aggregationen oder gehashte Identifikatoren statt kompletter Adressen.
Starten Sie klein. Ihr erster Score sollte eine klare Rubrik sein, die ein Kollege lesen und ohne Spreadsheet anwenden kann. Wenn Sie nicht erklären können, warum eine Anmeldung 72 statt 28 bekam, werden Sie ihm nicht vertrauen, wenn es darauf ankommt.
Rollout einige Signale, die Sie verstehen, und justieren Sie erst nach echten Outcomes (Bounces, Rückbuchungen, Missbrauchsberichte, erfolgreiche Aktivierungen). Halten Sie die Aktionen einfach, damit sie leicht auszuführen sind:
Die Implementierung ist einfacher, wenn die Kernsignale an einem Ort ankommen. Zum Beispiel liefert Verimail (verimail.co) eine E‑Mail‑Validierungs‑API, die Checks wie RFC‑konforme Syntax‑Validierung, Domain‑Verifikation, MX‑Lookup sowie Wegwerf‑ und Blocklisten‑Abgleich in einer Antwort zurückgibt. Verwenden Sie diese Ergebnisse als Eingaben für Ihre Rubrik und halten Sie die Entscheidungsregeln in Ihrer eigenen Policy, damit sie erklärbar und änderbar bleiben.
Sobald der Score live ist, messen Sie ihn wie ein Produktfeature. Protokollieren Sie Score, Band, getroffene Aktion und später beobachtetes Outcome. Prüfen Sie eine kleine Stichprobe falscher Positiver (geblockt, aber legitim) und falscher Negativer (erlaubt, aber schädlich) und passen Sie dann eine Regel nach der anderen an. Die einfachste Version, die Sie überwachen und anpassen, schlägt ein kompliziertes Modell, das niemand erklären kann.
