Erstellen Sie eine Allowlist und Denylist für Anmelde‑E‑Mail‑Domains, die Wegwerf‑Domains blockiert, ohne echte Firmen auszusperren. Tipps zu Zuständigkeit und Pflege.
Standardmäßig empfiehlt sich eine Denylist, die bekannte Wegwerf‑E-Mail‑Domains und Domains mit wiederholtem Missbrauch blockiert. Eine Allowlist kommt nur dann hinzu, wenn der Zugang beschränkt sein soll (z. B. Mitarbeiter‑Tools oder Portale für bestimmte Firmen).
Beginnen Sie mit Ihren eigenen Anmeldedaten der letzten 30–90 Tage. Suchen Sie nach Domains mit hohem Anmeldevolumen, aber nahezu keiner Aktivierung, wiederholten Hard‑Bounces oder klaren Missbrauchsberichten und prüfen Sie einige Beispiele, bevor Sie blockieren.
Normalisieren Sie zuerst die Domain: Leerzeichen trimmen, in Kleinbuchstaben umwandeln und eventuell einen abschließenden Punkt entfernen. Matchen Sie dann standardmäßig nur exakte Domains, denn breite Muster blockieren am schnellsten legitime Nutzer.
Eine gute Standardregel ist „Allowlist gewinnt“, damit eine geprüfte Ausnahme echte Nutzer schnell freischalten kann, auch wenn eine breitere Deny‑Regel existiert. Wählen Sie „Denylist gewinnt“ nur, wenn Sie mit mehr Support‑Tickets und langsameren Freischaltungen rechnen.
Vermeiden Sie breite Regeln wie das Blockieren ganzer Länder‑TLDs, Domains mit Bindestrichen oder alles, was „ungewöhnlich“ aussieht. Prüfen Sie vor dem Denylisting, ob die Domain von realen Organisationen (Universitäten, Behörden, große ISPs) genutzt wird, und sehen Sie sich jüngste erfolgreiche Anmeldungen von dieser Domain an.
Zeigen Sie einen klaren Grund und einen einfachen nächsten Schritt an. Zum Beispiel: „Dieser E‑Mail‑Anbieter ist nicht erlaubt. Bitte verwenden Sie eine geschäftliche E‑Mail oder kontaktieren Sie den Support, um eine Ausnahme zu beantragen.“ Stellen Sie sicher, dass der Support sieht, welche Regel den Block ausgelöst hat.
Führen Sie die Regeln zunächst im „Nur‑loggen“‑Modus, um den Effekt zu messen, und rollen Sie dann in kleinen Schritten mit einer schnellen Rollback‑Option aus. Testen Sie gegen eine aktuelle Stichprobe realer Anmeldungen, um einzuschätzen, wie viele gute Nutzer Sie blockieren würden.
Weisen Sie eine klare verantwortliche Rolle für Genehmigungen und Beschwerden zu und protokollieren Sie jede Änderung mit kurzer Begründung und Überprüfungsdatum. Ohne Verantwortung verwildern Listen und führen zu dauerhaften Sperren, die niemand erklären kann.
Als praktische Basis: Denylist wöchentlich prüfen und Allowlist monatlich. Fügen Sie Ablaufdaten für temporäre Sperren und Ausnahmen hinzu, damit sie automatisch fallen, falls niemand die Entscheidung erneuert.
Domainlisten sind eine Policy‑Schicht, kein Beweis dafür, dass eine Adresse echt ist. Kombinieren Sie sie mit E‑Mail‑Validierung, die Syntax, DNS/MX‑Einträge und Signale zu Wegwerf‑Providern prüft, damit Sie weniger legitime Nutzer blockieren und trotzdem schlechte Anmeldungen erfassen.
Domain‑Regeln schützen die Anmeldung vor vorhersehbaren Problemen: gefälschte Konten, zurückkommende E‑Mails (Bounces) und Missbrauch. Wenn sich Menschen mit Wegwerf‑Adressen anmelden können, erhalten Sie Nutzer, die nicht erreichbar sind, höhere Bounce‑Raten und eine unordentlichere Datenbank. Wegwerf‑Domains werden von Bots und Betrügern oft genutzt, weil sie das Erstellen tausender Konten erleichtern.
Eine Allowlist und eine Denylist für Anmelde‑E‑Mail‑Domains ist ein grobes, aber nützliches Mittel. Sie funktioniert am besten, wenn Sie klar definieren, was Sie stoppen wollen. Das Blockieren bekannter Wegwerf‑Provider kann beispielsweise niedrige Qualität bei Anmeldungen schnell reduzieren, noch bevor Sie eine Bestätigungs‑E‑Mail senden.
Es hilft, zwei Ideen zu trennen:
Dieser Unterschied ist wichtig, weil der Kompromiss real ist. Strengere Regeln bedeuten normalerweise weniger schlechte Anmeldungen, aber auch mehr Fehlablehnungen. Wenn Sie zu weit blockieren, lehnen Sie echte Nutzer ab, die sich in gutem Glauben anmelden.
Was zählt also in Ihrem Kontext als legitime Unternehmensdomain? Meistens ist es eine Domain, die zu einer echten Organisation gehört und zuverlässig Nachrichten empfangen kann. Das kann die Hauptdomain eines Unternehmens sein (wie name.com), regionale Domains (z. B. name.co.uk) oder eine vendor‑verwaltete Domain, die für Mitarbeiter verwendet wird. Ziel ist es, riskante Domains zu blockieren, ohne normale geschäftliche E‑Mails zu bestrafen.
Eine Domain‑Liste ist kein reines Feature. Es ist eine politische Entscheidung, die Umsatz, Support‑Aufwand und Vertrauen beeinflusst. Bevor Sie eine Allowlist und Denylist für Anmelde‑E‑Mail‑Domains bauen, legen Sie konkret fest, was Sie verhindern wollen.
Die meisten Teams haben ein primäres Ziel (und ein paar sekundäre): Wegwerf‑Adressen stoppen, Anmelde‑Betrug reduzieren oder die Zustellbarkeit schützen, indem schlechte Daten draußen bleiben. Das Ziel bestimmt, was Sie blockieren und wie streng Sie vorgehen. Das Blockieren von Wegwerf‑Domains ist meist unproblematisch. Das Blockieren von „kostenlosen E‑Mail“‑Domains ist riskant und trifft oft legitime Nutzer.
Schreiben Sie auch auf, was Sie nicht blockieren werden, selbst wenn es verdächtig aussieht. Häufige Beispiele sind zahlende Kunden, eingeladene Nutzer, Partner und interne Konten. Eine einfache Regel wie „Diese Flows erlauben wir, markieren sie aber ggf. zur Prüfung“ verhindert viele unbeabsichtigte Sperren.
Bestimmen Sie, wo die Durchsetzung stattfindet, damit die Regeln überall konsistent angewandt werden: Self‑Service‑Anmeldeformulare, öffentliche APIs, mit Adminrechten angelegte Nutzer, Einladungs‑Flows (oft großzügiger) und sensible Aktionen wie Passwort‑Zurücksetzung oder E‑Mail‑Änderung (vermeiden Sie Überraschungen für bestehende Nutzer).
Legen Sie schließlich Erwartungen an den Support fest. Wenn jemand geblockt wird: Was sieht er, und wie kann er das Problem beheben? Eine gute Block‑Meldung enthält einen einfachen Grund („Dieser E‑Mail‑Provider ist nicht erlaubt“), einen sicheren nächsten Schritt (verwenden Sie eine Geschäfts‑E‑Mail oder kontaktieren Sie den Support) und einen klaren Einspruchsweg.
Eine Allowlist ist die strenge Option: Sie lassen nur Nutzer zu, deren E‑Mail‑Domain in einer vertrauenswürdigen Liste steht. Das funktioniert am besten, wenn Sie bereits wissen, wer Zugriff haben sollte.
Häufige Allowlist‑Fälle sind interne Tools für Mitarbeitende, private Betas mit Einladungen an bestimmte Unternehmen oder B2B‑Kundenportale, bei denen jedes Konto einer bekannten Unternehmensdomain entspricht. In solchen Setups ist das Risiko, echte Personen auszusperren, geringer, weil die richtigen Domains vorhersehbar sind und der Support fehlende Domains leicht ergänzen kann.
Eine Denylist ist die flexible Option: Sie lassen die meisten Domains durch, blockieren aber deutlich minderwertige oder missbräuchliche Domains. Hier blockiert man üblicherweise Wegwerf‑Domains, Domains mit wiederholtem Missbrauch und offensichtliche Muster von Wegwerfadressen.
Eine hybride Strategie ist oft die sicherste für Wachstum: Verwenden Sie eine Denylist als Basis und fügen Sie gezielte Allowlist‑Ausnahmen für wichtige Randfälle hinzu. Zum Beispiel könnte ein großer Kunde eine weniger verbreitete Unternehmensdomain verwenden oder ein legitimer Partner von einer Subdomain kommen, die zuerst verdächtig wirkt.
Halten Sie die Regel‑Sprache einfach, damit sie leicht überprüfbar und schwer missverständlich ist. Verwenden Sie wann immer möglich exakte Domains (z. B. example.com). Entscheiden Sie im Vorhinein, ob Subdomains gleich behandelt werden sollen (ob mail.example.com zählt). Wenn Sie temporäre Ausnahmen verwenden, geben Sie ihnen einen Besitzer und ein Ablaufdatum und bevorzugen Sie kleine, klare Regeln gegenüber cleveren Mustern, die falsche Leute blockieren können.
Eine gute Starterliste ist kein Copy‑&‑Paste‑Download. Sie sollte auf dem basieren, was tatsächlich in Ihrem Anmeldeflow passiert. So bauen Sie eine Allowlist und Denylist, die realen Risiken entspricht, nicht Annahmen.
Beginnen Sie mit Ihren eigenen Daten. Ziehen Sie die letzten 30–90 Tage von Anmeldeversuchen, bestätigten Nutzern, Bounces, Spam‑Beschwerden und allen Betrugs‑ oder Missbrauchsberichten. Gruppieren Sie nach Domain und suchen Sie nach Mustern wie hohem Volumen bei sehr geringer Aktivierung, wiederholten Hard‑Bounces oder derselben Domain, die viele Konten in kurzer Zeit erstellt.
Wenn Sie internes Reporting haben, suchen Sie nach Wiederholungstätern. Eine praktische Faustregel: Domains mit hohem Volumen, aber nahezu keiner Interaktion sollten geprüft werden, nicht automatisch blockiert. Wählen Sie eine kleine Zahl, untersuchen Sie ein paar Adressen und bestätigen Sie das Verhalten, bevor Sie die Domain hinzufügen.
Bauen Sie die „gute“ Seite ebenfalls aus internem Wissen auf. Fragen Sie Sales und Customer Success nach einer kurzen Liste wichtiger Kundendomains und aktiver Interessenten. Diese können Ihre Anfangs‑Allowlist werden (oder zumindest eine „niemals ohne Prüfung blockieren“‑Liste), damit Sie echte Firmen nicht versehentlich ausbremsen.
Notieren Sie für jede Ergänzung kurz, warum sie hinzugefügt wurde: Quelle (Report, Ticket, Betrugsfall, Bounce‑Daten), Datum, wer es genehmigt hat, was Sie beobachteten und wann Sie es wieder prüfen. Kurz und nützlich.
Beispiel: Sie sehen 400 Anmeldungen von einer Domain in einer Woche, aber null Bestätigungen und viele identische IP‑Ranges. Sie protokollieren die Beweise, fügen die Domain zur Denylist hinzu und setzen eine 30‑Tage‑Überprüfung, falls sich das Muster ändert.
Behandeln Sie die E‑Mail‑Domain wie untrusted input. Kleine Formatunterschiede können Ihre Regeln aushebeln.
Normalisieren Sie jede Adresse gleich, bevor Sie sie mit einer Liste vergleichen: Leerzeichen trimmen, in Kleinbuchstaben umwandeln und einen abschließenden Punkt entfernen (manche Systeme behandeln example.com. als gültig). Machen Sie das einmal, möglichst dort, wo die E‑Mail zuerst ins System gelangt, damit alle nachfolgenden Prüfungen denselben Wert sehen.
Entscheiden Sie dann, wie das Matching funktioniert, und halten Sie es schriftlich. „Nur exakte Domain“ ist für die meisten Teams sicherer, weil es Überraschungen vermeidet. „Subdomains einbeziehen“ kann nützlich sein (z. B. mail.disposable.com zusammen mit disposable.com blockieren), kann aber auch legitime Setups treffen, wenn ein Unternehmen ungewöhnliche Subdomains nutzt.
Wählen Sie eine Entschiedungsregel und wenden Sie sie überall an. Viele Produkte entscheiden „Allowlist gewinnt“, damit eine geprüfte Ausnahme echte Nutzer sofort freischalten kann, selbst wenn eine breitere Deny‑Regel existiert. Wenn Sie „Denylist gewinnt“ wählen, rechnen Sie mit mehr Support‑Tickets und langsamerem Entsperren.
Ein sicherer Rollout sieht typischerweise so aus:
Der schnellste Weg, echte Anmeldungen zu verlieren, ist zu breit zu blockieren. Vermeiden Sie Regeln wie „blockiere alle Ländertop‑Level‑Domains“ oder „blockiere alles mit Bindestrich“. Viele echte Firmen nutzen Domains wie company.co.uk, company.com.au oder regionale Setups wie eu.company.com.
Behandeln Sie Subdomains als normal, nicht verdächtig. Ein großes Unternehmen leitet E‑Mails möglicherweise über Subdomains für verschiedene Teams, Regionen oder Akquisitionen. Wenn Ihre Regel nur die „Hauptdomain“ prüft, stellen Sie sicher, dass Fälle wie company.co.uk vs. company.com korrekt funktionieren und mail.company.com nicht fälschlich als „unbekannt“ markiert wird.
Seien Sie vorsichtig bei E‑Mail‑Routing‑Providern. Einige legitime Firmen senden und empfangen E‑Mails über Dienste, die generisch aussehen, und deren MX‑Records ähnlichen Mustern folgen wie Wegwerf‑ oder reine Marketing‑Setups. Domainregeln allein können die Absicht nicht sicher bestimmen.
Eine einfache Sicherheitscheckliste vor dem Hinzufügen einer Deny‑Regel:
Schaffen Sie schließlich einen Ausnahmepath für hochwertige Konten. Nach Fusionen hat ein Kunde vielleicht fünf bis zehn aktive Domains. Machen Sie es Support oder Sales leicht, eine temporäre Allow‑Ausnahme zu beantragen, während Sie Eigentum verifizieren und die Regeln sicher aktualisieren.
Domain‑Regeln versagen meist aus einem banalen Grund: Niemand ist verantwortlich. Geben Sie einem Team oder einer Rolle klare Verantwortung für Genehmigungen und Umgang mit Beschwerden. Es geht nicht um Kontrolle, sondern um Schnelligkeit und Konsistenz, wenn ein echter Kunde geblockt wird.
Ein Basis‑Workflow reicht aus:
Jede Änderung sollte geloggt werden, damit Sie sie später erklären können. Halten Sie das Log kompakt: wer hat es beantragt, wer hat genehmigt, was genau geändert wurde (Domain und Regeltyp), warum (Beweis), wann live gegangen ist und wann erneut geprüft werden soll.
Setzen Sie ein SLA für strittige Sperren, damit legitime Nutzer nicht hängen bleiben. Zum Beispiel: Eingangsbestätigung innerhalb von 4 Geschäftsstunden und Lösung innerhalb eines Geschäftstags, mit einem Notfallpfad für zahlende Kunden.
Bevor Sie eine Domain denylisten, verlangen Sie Beweise, nicht nur Bauchgefühle. Typische Nachweise sind hohes Anmeldevolumen mit klaren Missbrauchsmustern, wiederholte Hard‑Bounces, Spam‑Beschwerden oder eine hohe Übereinstimmung mit bekannten Wegwerf‑Providern.
Beispiel: Support meldet, dass Nutzer von acme‑partners.com sich nicht anmelden können. Der Owner prüft das Log, sieht eine Blockierung wegen 30 Spam‑Anmeldungen in einer Stunde und schaltet stattdessen auf eine temporäre Regel plus strengere Checks, dann erneute Prüfung in 48 Stunden.
Eine Domain‑Liste ist keine einmalige Einrichtung. Sobald Sie aufhören, sie zu pflegen, driftet sie: alte Missbrauchsmuster verschwinden, neue Wegwerf‑Domains tauchen auf und ein einzelner falscher Eintrag kann gute Nutzer still blockieren.
Setzen Sie eine Prüf‑Rhythmus passend zum Risiko. Wöchentlich für die Denylist ist ein üblicher Startpunkt, weil Angreifer schnell agieren. Monatlich für die Allowlist reicht meist, da legitime Domains langsamer wechseln.
Um Listenverfall zu verhindern, sollten temporäre Entscheidungen standardmäßig auslaufen. Wenn Sie eine Domain wegen einer kurzen Spam‑Welle hinzufügen, hängen Sie ein Ablaufdatum und eine kurze Begründung an. Gleiches gilt für Ausnahmen („Diese Domain erlauben wir für Partner X bis Vertragsende“). Nach Ablauf fällt die Regel weg, sofern niemand die Entscheidung mit frischen Beweisen erneuert.
Verfolgen Sie einige Metriken, um zu sehen, ob die Liste hilft oder schadet: Blockrate, Einspruchsrate, False Positives (bestätigte legitime Nutzer, die blockiert wurden), Bounce‑Rate und Domain‑Konzentration (wieviel Traffic von einer Domain kommt).
Achten Sie besonders auf zwei Signale: neue Wegwerf‑Domains und plötzliche Ausbrüche einer einzelnen Domain. Wenn examplemail.co von 2 Anmeldungen pro Tag auf 400 in einer Stunde steigt, untersuchen Sie, bevor Sie pauschal blocken. Schauen Sie auf Geografie, IP‑Muster und ob Adressen syntaktisch gültig sind und echte Mail‑Routing‑Einträge haben.
Schließlich: Einträge aggressiv entfernen. Wenn eine Domain längere Zeit keinen Missbrauch produziert oder ständig False‑Blocks für echte Firmen auslöst, entfernen Sie sie oder ersetzen Sie eine harte Sperre durch weichere Kontrollen wie Ratenbegrenzung, zusätzliche Verifikation oder manuelle Prüfung.
Der schnellste Weg, Vertrauen bei echten Nutzern zu verlieren, ist Domains aufgrund von Vermutungen zu blockieren. Eine Allowlist/Denylist funktioniert nur, wenn sie auf Beweisen basiert, oft überprüft wird und überall gleich angewendet wird.
Ein häufiger Fehler ist zu breit zu blockieren. Teams sperren manchmal ganze TLDs oder einen großen Provider nach einem kurzfristigen Ausbruch. Das fängt fast immer legitime Leute, besonders Auftragnehmer, Studierende und internationale Nutzer.
Ein anderer Fehler ist, eine Domain als Wegwerf zu bezeichnen, nur weil sie neu, unbekannt oder „zufällig“ aussieht. Viele echte Firmen nutzen kleine gehostete Domains, Rebrands oder regionale Provider. Ohne Beweis (Betrugsrate, Bounce‑Rate, Missbrauchsberichte) behandeln Sie „unbekannt“ als „unbekannt“, nicht als „böse”.
Muster, die am meisten schaden:
Sogar eine korrekte Sperre kann Probleme machen, wenn die Nutzererfahrung unklar ist. Wenn jemand geblockt wird, braucht er eine verständliche Erklärung und Handlungsschritte. Loggen Sie den genauen Grund und die Regel, zeigen Sie eine eindeutige Nachricht (vermeiden Sie vage „ungültige E‑Mail“) und halten Sie einen schnellen Ausnahmepfad für bekannte Kunden oder Partner bereit.
Bevor Sie ein Update an Allowlist/Denylist ausrollen, machen Sie eine Sicherheits‑Überprüfung. Die meisten Schäden entstehen durch kleine Inkonsistenzen, fehlenden Kontext oder Änderungen ohne Rückweg.
Beginnen Sie mit den Matching‑Regeln. Entscheiden Sie, ob Sie nur exakte Domains matchen (example.com) oder Subdomains einschließen (mail.example.com). Normalisieren Sie Eingaben immer gleich: Kleinbuchstaben, Trimmen von Leerzeichen und einheitliche Handhabung internationaler Domains. Wenn Ihr System Gmail.com und gmail.com unterschiedlich behandelt, entstehen Lücken und verwirrendes Verhalten.
Stellen Sie sicher, dass jede Regel erklärbar ist. Jeder Eintrag sollte einen kurzen Grund, das Datum und einen Owner haben. „Schlechte Domain“ ist keine Erklärung. „In 1.200 Betrugsanmeldungen letzte Woche gesehen“ ist es.
Halten Sie den Einspruchsweg einfach, aber real. Geben Sie strittigen Einträgen eine zeitlich begrenzte Überprüfung, damit Fehler nicht ewig leben. Und lassen Sie temporäre Ausnahmen nicht versehentlich permanent werden: Wenn Sie einer riskanten Domain für eine Partner‑Einführung erlauben, setzen Sie ein Ablaufdatum und entfernen Sie die Ausnahme, wenn sie nicht erneuert wird.
Nach dem Livegang beobachten Sie die Auswirkungen. Tracken Sie False Positives und beheben Sie sie schnell. Überwachen Sie Bounce‑Rate und Zustellbarkeitsverschiebungen für neu erlaubte Domains. Prüfen Sie kürzliche Anmeldungen stichprobenartig, um sicherzustellen, dass die Regeln wie beabsichtigt arbeiten.
Ein B2B‑SaaS bemerkt einen plötzlichen Anstieg an Konten mit lookalike‑Domains (z. B. "acme‑corp‑support.com" statt der echten Firma) und eine Welle von Wegwerf‑Providern. Sales klagt über schlechte Leads und Support sieht mehr Chargeback‑Versuche. Das Team hat bereits Allowlist und Denylist, aber sie wurden monatelang nicht gepflegt.
Sie beginnen mit einer gemessenen Reaktion, nicht einer großen Säuberung. Zuerst fügen sie eine einzelne gezielte Denylist‑Regel für die schlimmste Wegwerf‑Domain aus den Logs hinzu. Gleichzeitig setzen sie ein temporäres Ratenlimit auf riskante Anmeldungen (gleiche IP‑Ranges, hohe Velocity, wiederholte ähnliche Nutzernamen). Das reduziert Missbrauch, während sie lernen, anstatt ganze Domain‑Kategorien zu blockieren.
Zwei Tage später wird ein echter Kunde geblockt. Ein großer Konzern nutzt eine regionale Subdomain für E‑Mails (z. B. "[email protected]"). Eine breite Regel, die Lookalike‑Subdomains treffen sollte, passt zufällig auch auf diese Adresse. Support eskaliert mit Belegen: Der Interessent hat einen unterschriebenen Auftrag, konsistente IP‑Historie und Mails kommen nicht an, weil die Anmeldung nie abgeschlossen wurde.
Die Lösung ist nicht, die Denylist‑Eintragung zu entfernen. Stattdessen fügen sie eine enge Allowlist‑Ausnahme für die verifizierte Unternehmensdomain hinzu, dokumentieren die Begründung und setzen ein Ablaufdatum, damit die Regel später nochmal geprüft wird.
Nach zwei Wochen überprüft das Team die Ergebnisse: blockierte Anmeldungen steigen auf 6% (von 1%), aber Support‑Einsprüche bleiben niedrig bei 0,2% aller Anmeldungen. Die Bounce‑Rate für Willkommens‑Mails sinkt von 3,4% auf 1,1% und Sales verzeichnet weniger gefälschte Demo‑Anfragen. Der entscheidende Gewinn: Jede Regel hat jetzt einen Owner, eine Begründung und einen Rollback‑Weg.
Allowlists und Denylists sind nützlich, aber grob. Kombinieren Sie sie mit E‑Mail‑Validierung, damit Sie schlechte Adressen auch dann erfassen, wenn die Domain normal aussieht, und echte Nutzer nicht nur wegen einer unbekannten Firmen‑Domain blocken.
Formulieren Sie Ihre Policy in einfacher Sprache: Was Sie blockieren, was Sie erlauben und was zur manuellen Prüfung geht. Das hält Support, Produkt und Engineering auf derselben Seite, wenn jemand fragt, warum eine Anmeldung abgelehnt wurde.
Ein praktischer Ablauf ist: Syntax prüfen, die Domain auf Empfangsfähigkeit prüfen (DNS und MX), auf bekannte Wegwerf‑Provider und Spam‑Traps scannen und dann Allowlist‑ und Denylist‑Regeln anwenden (inklusive Ausnahmen). Loggen Sie das Ergebnis, damit Sie daraus lernen und anpassen können.
Wenn Sie die Regeln einfach halten wollen, aber starke Signale bei der Anmeldung brauchen, ist Verimail (verimail.co) eine Option, die Teams nutzen, um E‑Mails mit RFC‑konformen Syntaxprüfungen, Domain‑ und MX‑Verifikation sowie Wegwerf‑Provider‑Matching in einem API‑Aufruf zu validieren. So bleibt Ihre Liste eine Policy‑Ebene und die Validierung übernimmt die harte Arbeit, zu entscheiden, ob eine Adresse echt und erreichbar aussieht.
