E-Mail-Domain-Verifizierung für Produkt- und Marketingteams erklärt

Warum Domain-Prüfungen wichtig sind (auch wenn die E-Mail gut aussieht)

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:

• Eine echt aussehende E-Mail folgt dem üblichen Muster (Name + @ + Domain).
• Eine nutzbare E-Mail zeigt auf eine Domain, die gerade E-Mails empfangen kann und später wahrscheinlich keine Probleme verursacht.

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.

Was Domain-Verifizierung ist (und was nicht)

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:

• Syntaxprüfung: Ist die Adresse in einem gültigen Format geschrieben (z. B. [email protected]), ohne unzulässige Zeichen?
• Domain-Prüfung: Existiert die Domain und ist sie so eingerichtet, dass sie E‑Mails annimmt?
• Postfachprüfung: Existiert das konkrete Postfach wirklich (erhält z. B. [email protected] Mails)?

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?".

Die Prüfungen hinter den Kulissen: Domain, DNS und MX

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?

Domain existiert (DNS in einfachen Worten)

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.

E‑Mail wird akzeptiert (was MX‑Einträge aussagen)

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:

• Fehlt DNS komplett, ist es wahrscheinlich ein Tippfehler oder eine tote Domain (ablehnen).
• Sind MX-Einträge vorhanden und normal aussehend, ist die Adresse wahrscheinlich zustellbar (akzeptieren).
• Fehlen MX-Einträge oder sind sie fehlerhaft, ist die Domain vermutlich nicht für Mail eingerichtet (blockieren oder zur Korrektur auffordern).
• Existiert die Domain, weist aber auf verdächtige Infrastruktur, ist das höheres Risiko (markieren oder blockieren).

Temporäre vs. permanente Fehler (Retries sind wichtig)

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.

Worüber man entscheiden muss: Annahmeregeln, auf die sich Teams einigen können

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:

• Erlauben: normal weitermachen.
• Warnen: den Nutzer weitermachen lassen, aber zusätzliche Hürden einbauen (zusätzliche Bestätigung, reduzierte Limits oder klare Aufforderung, eine andere E‑Mail zu verwenden).
• Blockieren: die Anmeldung stoppen oder eine andere Adresse verlangen.

Definiert „Warnen“ in einem Satz, damit es nicht zu einer Sammlung von Sonderfällen wird.

Wo die Grenzen liegen

Ein einfacher Anfang ist, häufige Fälle einer Aktion zuzuordnen:

• Wegwerf‑E‑Mail‑Domains: in der Regel blockieren (oder warnen, wenn ihr viele datenschutzorientierte Nutzer habt).
• Rollenadressen (support@, sales@, admin@): oft warnen, da sie geteilt werden und schwerer an eine Person zu binden sind.
• Kostenlose Anbieter (Gmail, Outlook): typischerweise erlauben, außer ihr seid strikt B2B.
• Firmendomains ohne funktionierende Mail‑Konfiguration (kein MX): blockieren oder nur erlauben, wenn der Nutzer per E‑Mail verifiziert.
• Unbekannte oder neue Domains: erlauben, aber überwachen, oder warnen, wenn Betrug ein Thema ist.

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.

Regionale und sprachliche Realitäten

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.

Schritt für Schritt: Domain‑Verifizierungsregeln für die Anmeldung festlegen

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:

• Akzeptieren für normale, zustellbare Domains.
• Warnen für wacklige Fälle, bei denen der Nutzer einen erneuten Versuch unternehmen oder später bestätigen soll.
• Blockieren für klare Hochrisikofälle (bekannte Wegwerf‑Domains, nicht existente Domains, Domains ohne funktionierenden Mail‑Aufbau).

Um den Rollout handhabbar zu halten, konzentriert euch auf ein paar konkrete Schritte:

• Wählt Erfolgsmetriken (Aktivierungsrate, Bounce‑Rate, Trial‑to‑Paid, Betrugsrate).
• Definiert eure Ergebnisse (erlauben, warnen, blockieren) und wo sie gelten (Anmeldung, Einladungsfluss, Checkout).
• Schreibt Nutzertexte, die klar und spezifisch sagen, was als Nächstes zu tun ist.
• Überwacht wöchentlich (Bounces, Conversions und markierte Anmeldungen).
• Prüft anfangs monatlich die Regeln, später vierteljährlich, wenn stabil.

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.

Wie Produkt und Marketing Erfolg messen sollten

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:

• Anmelde‑Conversion‑Rate (Besuch bis Kontoerstellung)
• Aktivierungsrate (neue Nutzer, die eine sinnvolle Erstaktion durchführen)
• Hard‑Bounce‑Rate bei Onboarding‑ und Kampagnen‑E‑Mails
• Spam‑Beschwerde‑Rate und Abmelderate
• Betrugs‑ und Missbrauchssignale (Duplikate, Gutscheinmissbrauch, ungewöhnliche Anmeldungs‑Spikes)

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.

Häufige Fehler und Fallen vermeiden

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:

• Alle kostenlosen E‑Mail‑Provider standardmäßig blockieren (tötet oft Anmeldungen von Studenten, Kleinstunternehmen und Evaluatoren).
• Temporäre DNS‑Probleme als permanente Fehler behandeln (führt zu falschen Ablehnungen).
• Bei Syntaxprüfungen aufhören (dann akzeptiert ihr Tippfehler und Domains ohne Mail‑Setup).
• Wegwerflisten veralten lassen (sie ändern sich schnell).
• Vage Fehlermeldungen wie „Ungültige E‑Mail“ verwenden (Nutzer wissen nicht, was sie korrigieren sollen).

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:

• Bei Timeouts erneut versuchen oder soft‑failen; harte Fehler nur bei klaren Signalen (wie nicht existierender Domain oder fehlendem Mail‑Routing).
• Kostenlose Provider erlauben, es sei denn, Daten sprechen dagegen, und Ausnahmen leicht machen.
• Wegwerf‑Erkennung aktuell halten.
• Fehlermeldungen so schreiben, dass sie den nächsten Schritt erklären (z. B.: „Wir konnten diese Domain gerade nicht verifizieren. Bitte versuchen Sie es erneut oder verwenden Sie eine andere E‑Mail.“).

Edge‑Cases, die in der Praxis auftreten

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:

• Ein- oder zweimal kurz erneut versuchen.
• Anmeldung erlauben, aber E‑Mail‑Bestätigung vor Aktivierung verlangen.
• Nur blockieren, wenn Ergebnisse klar ungültig sind.
• Risikofälle (z. B. wahrscheinlich Wegwerf‑Provider) für zusätzliche Verifikation markieren.
• „Unbekannt“ separat protokollieren, um Muster zu erkennen.

Schnellcheckliste vor dem Rollout neuer Regeln

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.

Pre‑Launch‑Checks

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.

• Bestätigt, dass die Domain E‑Mails empfangen kann (Domain existiert und hat funktionierendes Mail‑Routing, oft nachgewiesen durch MX‑Record‑Prüfung).
• Entscheidet, wie ihr mit Wegwerf‑ und Hochrisiko‑Domains verfahrt (blockieren, warnen, Limits oder zusätzliche Verifikation).
• Legt fest, wie mit Rollenadressen wie info@, sales@, support@ umgegangen wird.
• Definiert, was bei unsicheren Ergebnissen passiert (Timeouts und temporäre DNS‑Probleme).
• Stellt sicher, dass ihr Auswirkungen messen könnt (Bounce‑Rate, Spam‑Beschwerden, Trial‑Aktivierung, „fälschlich blockiert“-Berichte).

Fallback‑Plan explizit machen

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 einfaches Beispiel: Regeln für Trial‑Anmeldung abstimmen

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.

Nächste Schritte: dokumentieren, ausrollen und aktuell halten

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:

• Was „Pass“ und „Fail“ für die Domain‑Verifizierung bedeuten
• Was bei Fail passiert (blockieren, warnen oder mit Reibung erlauben)
• Bekannte Ausnahmen (Partner, Großkunden, interne Domains)
• Wer Änderungen genehmigen kann und wer die Metriken verantwortet
• Einige konkrete Beispiele und das erwartete Ergebnis

Rollt in Stufen aus, damit ihr echte Nutzer nicht abschneidet:

• Woche 1: nur warnen und Fehlertypen protokollieren
• Woche 2: offensichtliche schlechte Fälle blockieren (nicht existente Domain, kein Mail‑Server)
• Woche 3: Wegwerf‑ und höher‑riskante Signale verschärfen
• Laufend: falsch positive Blockierungen prüfen und gezielte Ausnahmen hinzufügen

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.