E-Mail-Domain-Verifizierung einfach erklärt: was geprüft wird, was sie nicht nachweist und wie Produkt- und Marketingteams sich auf Anmelde-Regeln einigen können.
Eine E-Mail-Adresse kann perfekt aussehen und trotzdem beim Versenden der Bestätigungsnachricht fehlschlagen. „[email protected]“ hat die richtige Form und besteht eine grundlegende Formatprüfung, aber das heißt nicht, dass die dahinterliegende Domain tatsächlich E-Mails empfangen kann.
Der Unterschied ist einfach:
Wenn Teams Domain-Prüfungen überspringen, zeigen sich die Probleme später: Bounce-Raten steigen, gefälschte oder minderwertige Anmeldungen rutschen durch (inklusive Wegwerf-Adressen), die Zustellbarkeit verschlechtert sich mit der Zeit und das Reporting wird unruhig.
Ein häufiges Szenario: Ein Free Trial startet und die Anmeldungen schnellen nach oben, aber ein Teil der Nutzer klickt nie die Verifizierungs-E-Mail, weil sie nie ankommt. Support-Tickets häufen sich, Marketing gibt dem E-Mail-Tool die Schuld, Produkt beschuldigt „schlechte Leads“. Oft waren viele dieser Adressen von Anfang an nicht erreichbar.
E-Mail-Domain-Verifizierung hilft, das früh zu erkennen. Sie prüft, ob die Domain nach dem „@“ so eingerichtet ist, dass sie E-Mails empfangen kann, und kann häufige Risikosignale markieren (wie Wegwerf-Anbieter), sodass schlechte Adressen Ihre Datenbank nicht heimlich verunreinigen.
Das Ziel ist nicht, Menschen blind zu blockieren. Es geht darum, sich auf Annahmeregeln zu einigen, die zum Geschäft passen: was man erlaubt, wann man warnt und was man ablehnt.
E-Mail-Domain-Verifizierung prüft, ob der Domain‑Teil einer E-Mail-Adresse (der Teil nach dem @) so aussieht, dass er E-Mails empfangen kann. Es ist mehr als „sieht das wie eine E-Mail aus?“ und weniger als „ist das eine echte Person mit funktionierendem Postfach?“
Drei Dinge werden oft vermischt:
Die Domain-Verifizierung ist die mittlere Ebene. Sie bestätigt in der Regel, dass die Domain echt ist und dass ihre DNS‑Einstellungen Mail‑Routing‑Einträge enthalten (oft via MX-Record-Prüfung). Wenn eine Domain keine Mail‑Konfiguration hat, wird das Versenden dorthin fast immer fehlschlagen.
Was sie nicht beweisen kann: Sie kann nicht bestätigen, dass das konkrete Postfach existiert, dass eine Person es besitzt oder dass der Nutzer darauf zugreifen kann. Eine Domain kann korrekt konfiguriert sein, während eine einzelne Adresse darunter falsch, gesperrt oder nie angelegt ist.
Eine praktische Denkweise: Domain‑Verifizierung beantwortet „ist das prinzipiell zustellbar?“ nicht „ist dieser Nutzer real?".
Wenn jemand eine E-Mail-Adresse eingibt, ist der Teil nach dem @ eine Domain (wie example.com). Domain‑Verifizierung stellt eine Frage: Sieht diese Domain so aus, als könne sie gerade E‑Mails empfangen?
DNS ist das Telefonbuch des Internets. Eine Domain „existiert“, wenn dieses Telefonbuch Einträge dafür hat. Fehlen DNS‑Einträge komplett, ist die Domain wahrscheinlich falsch getippt, abgelaufen oder nie eingerichtet.
Auch wenn eine Website lädt, kann E‑Mail trotzdem kaputt sein. Viele Domains sind registriert, werden aber kaum genutzt oder nur für eine Website konfiguriert. E‑Mail braucht eigene Einstellungen.
MX‑Records sind DNS‑Einträge, die der Welt sagen, wohin E‑Mails für eine Domain zugestellt werden sollen. Hat eine Domain gültige MX‑Einträge, deutet das meist darauf hin, dass sie für E‑Mail eingerichtet ist.
Fehlen MX‑Einträge, bedeutet das nicht automatisch, dass die Adresse gefälscht ist, aber es ist ein starkes Signal, dass die Domain nicht für Mail eingerichtet ist (oder fehlkonfiguriert). Für die meisten Anmeldeabläufe ist fehlendes oder ungültiges MX ein guter Grund, die Adresse zu blockieren oder um eine andere Adresse zu bitten.
Teams stimmen sich üblicherweise auf Ergebnisse wie diese ab:
Nicht jeder Fehler ist endgültig. Manchmal zeitüberschreiten DNS‑Server oder ein Mail‑Provider hat eine kurze Störung. Das sind temporäre Fehler und sollten erneut versucht werden. Permanente Fehler (z. B. „Domain existiert nicht“ oder „kein solcher Eintrag“) in der Regel nicht.
Bevor über Tools gestritten wird, einigt euch auf Ergebnisse. Annahmeregeln sind Entscheidungen darüber, was passiert, wenn eine Adresse riskant aussieht. Das Ziel ist nicht perfekte Erkennung, sondern konsistentes Verhalten, auf das sich Nutzer, Support und Reporting verlassen können.
Die meisten Teams arbeiten gut mit drei Aktionen:
Definiert „Warnen“ in einem Satz, damit es nicht zu einer Sammlung von Sonderfällen wird.
Ein einfacher Anfang ist, häufige Fälle einer Aktion zuzuordnen:
Sobald ihr diese Linien zieht, implementiert dieselbe Logik überall dort, wo die E‑Mail ins System kommt (Anmeldeformulare, Einladungen, CSV‑Importe, Partnerportale). Inkonsistente Regeln sind eine leise Quelle für Support‑Tickets.
Wenn ihr international verkauft, ist „kostenloser Anbieter“ oft lokal. Das Blockieren unbekannter regionaler Anbieter kann Anmeldungen in bestimmten Ländern reduzieren, ohne dass es jemand merkt. Entscheidet, ob eure Regeln global oder marktspezifisch sind und wer Ausnahmen verwaltet.
Schreibt auch den Trade‑off auf. Strengere Regeln reduzieren Betrug und Bounces, können aber echte Nutzer blockieren und den Support belasten. Lockerere Regeln erhöhen die Conversion, können aber Fake‑Anmeldungen steigen lassen und die Zustellbarkeit schädigen. Wenn dieser Trade‑off dokumentiert ist, messen Produkt und Marketing Erfolg gleichartig.
Beginnt damit, euch darauf zu einigen, was für euer Geschäft eine „gute“ Anmeldung ist. Liegt der Schwerpunkt auf schneller Aktivierung, weniger Bounces, besserer Lead‑Qualität oder geringerem Betrug? Wenn Produkt weniger Supporttickets will und Marketing bessere Zustellbarkeit, schreibt diese Ziele auf. Sonst ändern sich Regeln je nach der letzten Beschwerde.
Wählt dann Ergebnisse, die zum realen Risiko passen, nicht zum Bauchgefühl. Ein einfaches Muster ist:
Um den Rollout handhabbar zu halten, konzentriert euch auf ein paar konkrete Schritte:
Haltet Meldungen praktisch. Wenn eine Domain die MX‑Prüfung nicht besteht, zeigt nicht „DNS‑Fehler“. Sagt: „Diese E‑Mail‑Domain kann keine E‑Mails empfangen. Versuchen Sie eine andere Adresse.“ Wenn ihr warnt, bietet einen Weg an: „Sie können fortfahren, müssen Ihre E‑Mail aber bestätigen, um das Konto zu aktivieren."
Schließlich baut eine Feedback‑Schleife ein. Verfolgt, wie oft jedes Ergebnis auftritt und was diese Nutzer danach tun. Wenn „Warnen“-Nutzer gut konvertieren und nicht bounce, lockert die Regel. Wenn blockierte Nutzer immer wieder in Betrugsberichten auftauchen, verschärft sie.
Erfolg ist nicht nur „mehr Anmeldungen“. Das Ziel ist, Anmeldungen für echte Menschen einfach zu halten und gleichzeitig teure Probleme später zu reduzieren: Bounces, Beschwerden und Fake‑Accounts.
Verfolgt zwei Bereiche nebeneinander: Funnel‑Volumen oben und nachgelagerte Qualität. Steigt die Conversion, aber Bounces und Beschwerden explodieren, habt ihr nicht gewonnen.
Metriken, die die meisten Teams wöchentlich prüfen können:
Wenn möglich, verbindet E‑Mail‑Qualität mit Geld. Ein kleiner Rückgang der Bounces kann die Sender‑Reputation schützen, E‑Mails im Posteingang halten und unnötige Ausgaben für falsche Leads reduzieren.
Um strikte vs. lockere Regeln zu wählen, führt einen einfachen A/B‑Test über mindestens einen vollen Geschäftszyklus durch (oft 1–2 Wochen). Vergleicht Conversion und Qualitätsmetriken und entscheidet basierend auf dem Nettowert, nicht einer einzelnen Kennzahl.
Die meisten Probleme bei E‑Mail‑Prüfungen sind keine technischen, sondern politische Probleme. Eine Regel, die sicher klingt, kann echte Kunden blockieren oder Müll durchlassen.
Ein klassischer Fehler ist, eine Formatprüfung mit echter Validierung zu verwechseln. Ein Regex kann sagen, ob eine Adresse wie [email protected] aussieht. Er kann nicht sagen, ob die Domain E‑Mails empfangen kann oder ob die Adresse wahrscheinlich bounce. Domain‑Verifizierung konzentriert sich auf das, was nach dem @ passiert, nicht nur auf die Form des Textes.
Häufige Fallen:
Ein einfaches Beispiel: Jemand meldet sich von einem Café‑WLAN für ein Trial an. Ein DNS‑Lookup läuft einmal in einen Timeout. Wenn euer System sofort blockiert, habt ihr gerade einen echten Lead an eine Netzwerkstörung verloren.
Bessere Defaults reduzieren Betrug, ohne gute Nutzer zu bestrafen:
Die meisten Anmeldungen sind einfach. Knifflig wird es dort, wo Domain‑Verifizierung kein klares Ja oder Nein liefern kann, auch wenn ein echter Mensch dahintersteht.
Internationale und weniger verbreitete Domains können Teams überraschen. Kunden nutzen Länderdomains (wie .de oder .br) oder neuere Domainendungen. Manche Domains verwenden Nicht‑Latein‑Zeichen (IDNs), die in Logs seltsam aussehen können, aber gültig sind.
Neue Domains sind ein weiterer Fall. Ein Startup kauft eine Domain und sammelt Anmeldungen, bevor DNS‑Änderungen vollständig propagiert sind. Für ein paar Stunden kann dieselbe Domain in einer Region gültig und in einer anderen nicht erscheinen.
Firmendomains können ebenfalls ungewöhnlich sein. Große Unternehmen nutzen manchmal Split‑DNS (je nach Standort unterschiedliche Antworten) oder stark abgesicherte Setups, die nicht typisch aussehen.
Auch intermittierende Lookup‑Fehler treten auf. Nutzer hinter VPNs, Firmennetzwerken oder aggressiven Sicherheitslösungen können temporäre Timeouts auslösen. Das ist nicht dasselbe wie eine schlechte Domain.
Wenn ein Tool „unbekannt“ zurückgibt, bedeutet das meist „konnte gerade nicht bestätigt werden“, nicht „Fake“. Eine praktische Richtlinie:
Bevor ihr Anmelde‑Regeln ändert, stellt sicher, dass alle dasselbe Verständnis davon haben, was „gut“ und „schlecht“ ist. Eine kleine Änderung kann Anmeldungen, Trial‑to‑Paid‑Konversion und Zustellbarkeit unterschiedlich beeinflussen.
Testet Regeln an einer Stichprobe jüngerer Anmeldungen (inklusive guter Kunden und offensichtlichem Müll). Notiert, was ihr blockieren würdet und warum, damit das Team die Trade‑offs prüfen kann.
Die meisten Diskussionen entstehen in der grauen Zone, nicht bei offensichtlichen Fälschungen. Schreibt den Fallback‑Pfad für unsichere Fälle und wer die Entscheidung trifft, wenn Metriken widersprüchlich sind (Marketing will weniger Bounces, Produkt will weniger blockierte echte Nutzer).
Ein B2B‑SaaS‑Team bemerkt, dass Trial‑Anmeldungen um 18 % wachsen, aber Sales berichtet, dass „neue Leads“ nicht antworten. Marketing sieht steigende Bounces, und Produkt findet viele Accounts mit Wegwerf‑Adressen.
Sie verschärfen Regeln, ohne echte Anmeldungen zu töten.
Zuerst wählen sie eine klare Anfangs‑Policy: Wegwerf‑Domains werden bei der Anmeldung blockiert. Rollenadressen (info@, sales@, support@) sind erlaubt, aber das Formular zeigt eine freundliche Warnung: „Für schnellere Einrichtung und Kontowiederherstellung nutze bitte deine Arbeits‑E‑Mail." Produkt verantwortet UX und Wortlaut, Marketing den Ton, und Sales definiert, was als brauchbarer Lead zählt.
Nach zwei Wochen prüfen sie die Ergebnisse gemeinsam. Die Conversion sinkt leicht, aber die Bounce‑Rate fällt deutlich. Fake‑Accounts in den ersten 24 Stunden gehen zurück, und Sales berichtet weniger Tote Leads, auch wenn das Gesamtvolumen etwas niedriger ist.
Sie passen anhand der Daten an. Marketing optimiert die Nachricht, um Reibung zu reduzieren. Produkt ergänzt einen klaren „Erneut versuchen“-Hinweis, wenn eine Adresse blockiert wird, damit echte Nutzer nicht steckenbleiben. Außerdem fügen sie Monitoring hinzu: wöchentliche Zählung blockierter Wegwerf‑E‑Mails, Bounce‑Rate, Trial‑to‑Activation‑Rate und Anteil der Anmeldungen mit Rollenadressen.
Behandelt eure Regeln wie eine Produktentscheidung, nicht als einmalige Änderung. Wenn Produkt und Marketing sich auf Ergebnisse einigen (weniger Fake‑Anmeldungen, weniger Bounces, weniger Support‑Tickets), fällt die Entscheidung, was zu blockieren und was zu erlauben, viel leichter.
Schreibt ein gemeinsames Dokument, das jeder verstehen kann:
Rollt in Stufen aus, damit ihr echte Nutzer nicht abschneidet:
Wenn ihr diese Prüfungen über einen Dienst laufen lassen wollt, ist Verimail (verimail.co) eine E‑Mail‑Validierungs‑API, die RFC‑konforme Syntaxprüfungen, Domain‑Verifizierung, MX‑Record‑Lookups und Echtzeit‑Abgleich mit Wegwerf‑/Blocklisten kombiniert, sodass ihr dieselben Regeln in Formularen und Backend anwenden könnt.
Setzt eine einfache Erinnerung (monatlich reicht für die meisten Teams), um Bounce‑Rate, Anmelde‑Completion‑Rate und wie viele Nutzer gewarnt oder blockiert wurden, zu prüfen und dann anhand der Daten anzupassen.
