Erfahren Sie, wie Sie Anmeldungen mit neu registrierten Domains erkennen, indem Sie Domain‑Alterssignale, E‑Mail‑Validierungsergebnisse und schrittweise Verifizierungsregeln kombinieren, um Betrug und Bounces zu reduzieren.
Weil sie günstig und einfach zu ersetzen sind. Wenn eine Domain gesperrt wird, registriert ein Angreifer einfach eine neue und macht weiter. Deshalb sieht man bei Missbrauchswellen oft viele Anmeldungen von frischen Domains.
Nein. Viele legitime Nutzer registrieren eine Domain und melden sich am selben Tag an — für ein neues Unternehmen, ein Projekt, eine Veranstaltung oder ein Rebranding. Behandle das Domain-Alter als Hinweis auf Risiko und bestätige es dann anhand von Mail-Setup und Verhaltenssignalen.
Meist bedeutet es entweder, dass die Domain gerade erst registriert wurde, oder dass sie erst kürzlich in Aktivitäten wie DNS-Daten, E-Mail-Traffic oder Sicherheits-Telemetrie aufgetaucht ist. Registrierungsalter und "first-seen"-Aktivität können auseinanderfallen, etwa wenn eine Domain lange ungenutzt war oder den Besitzer wechselte.
Beginnen Sie mit RFC-konformer Syntaxprüfung, um offensichtlichen Müll zu fangen. prüfen Sie dann, ob die Domain in DNS existiert, dann die MX-Einträge, um zu sehen, ob sie Mail empfangen kann, und zum Schluss filtern Sie disposable Provider und bekannte schlechte Infrastruktur. Diese Checks beantworten schnell „Ist das real?“ und „Kann diese Adresse Mail empfangen?"
Fehlende MX bedeutet oft, dass die Domain noch keine Mails empfangen kann, sodass Verifizierung und Onboarding unzuverlässig werden. Bei sehr neuen Domains ist das ein praktischer Grund, die Anmeldung zu verlangsamen oder nach einer anderen Adresse zu fragen, statt sofort Zugang zu sensiblen Funktionen zu gewähren.
Teilen Sie das Domain-Alter in breite Bereiche wie 0–7 Tage, 8–30 Tage, 31–180 Tage und 180+ Tage. Kombinieren Sie dann das Bucket mit dem Validierungsergebnis und wählen Sie eine konsistente Aktion: erlauben, Verifizierung verlangen, drosseln oder blocken.
Ein Hard-Fail blockiert die Anmeldung sofort, wenn die E-Mail offensichtlich unbrauchbar oder hochriskant ist (z. B. ungültige Syntax, nicht existente Domain, Disposable-Treffer). Ein Soft-Fail erlaubt die Kontoanlage, fügt aber Reibung hinzu, etwa E-Mail-Verifizierung, CAPTCHA, Rate-Limits oder eingeschränkten Zugriff bis zur Bestätigung.
Standardmäßig das Konto anlegen, aber sensible Aktionen hinter Verifizierung zurückhalten. Lassen Sie Nutzer z. B. ein Passwort setzen und das Dashboard sehen, verschieben Sie jedoch Trials, API-Schlüssel, Exporte oder Einladungen, bis die E-Mail verifiziert ist.
Behandle unbekanntes Alter als unzuverlässige Information, nicht als negatives Signal. Nutze es als Grund für zusätzliche Checks oder Step-up-Verifizierung und verlasse dich stärker auf Zustellbarkeitsprüfungen wie DNS-Validität, MX-Prüfung und Disposable-/Blocklist-Abgleich.
Führe Regeln zuerst im Monitoring-Modus aus und protokolliere Alter-Bucket, Validierungsergebnis und die getroffene Aktion. Vergleiche das später mit Bounces, Spam-Berichten, Chargebacks oder gesundem Nutzerverhalten. Wenn Sie eine Komplett-Lösung für Kernsignale beim Signup wollen, liefert eine E-Mail-Validierungs-API wie Verimail (verimail.co) Syntax-, Domain-, MX- und Disposable/Blocklist-Checks in einem Aufruf.
Brandneue Domains sind für Angreifer attraktiv, weil sie sich leicht registrieren lassen, günstig und schnell entsorgbar sind. Wenn eine Domain blockiert wird, registrieren sie einfach eine neue und machen weiter. Deshalb treten „neue Domain“-Anmeldungen oft in Wellen gefälschter Konten auf.
Neue Domains haben außerdem kaum Historie. Es gibt weniger öffentliche Signale, an denen man sie beurteilen kann, und sie stehen wahrscheinlich noch nicht auf Blocklisten. Diese weiße Weste lässt Missbrauch einfacher an einfachen Filtern vorbeikommen und verschafft Zeit, bevor die Domain einen schlechten Ruf bekommt.
Wenn dieses Muster zuschlägt, führt es meist zu denselben Geschäftsproblemen: von Bots erstellte Konten, die Supportzeit verschwenden, über Spam, der die Zustellbarkeit schädigt, bis hin zu Fake-Trials zum Scrapen oder Testen, Zahlungsbetrug mit Rückbuchungen und minderwertigen Leads, die Berichte verunreinigen.
Das heißt nicht, dass jede neue Domain schlecht ist. Echte Menschen registrieren täglich Domains: ein neues Unternehmen, ein Side‑Projekt, eine Veranstaltung, ein Rebranding oder ein Team, das von einem kostenlosen Postfach auf eine eigene Domain wechselt. Alle neuen Domains zu blocken bestraft genau die Nutzer, die Sie gewinnen möchten.
Das praktische Ziel ist, Missbrauch zu reduzieren, ohne echte Nutzer zu blockieren. Betrachten Sie das Domain-Alter als Risiko-Hinweis, nicht als endgültiges Urteil. Kombinieren Sie es mit E-Mail-Validierungssignalen (Syntax, Domain‑Setup, Zustellbarkeits‑Hinweise) und nutzen Sie progressive Verifizierung, sodass risikoreichere Anmeldungen etwas mehr Reibung spüren, während normale Nutzer einen glatten Ablauf behalten.
Ein legitimes neues Startup könnte sich mit einer Domain anmelden, die letzte Woche registriert wurde, aber das Mail‑Setup ist solide und das Verhalten wirkt menschlich. Angreifer zeigen oft das Gegenteil: eine frische Domain plus wackelige Konfiguration und automatisiertes, volumenbasiertes Verhalten.
„Domain-Alter" bezieht sich meist auf eines von zwei Dingen:
Das Registrierungsalter hilft, weil viele Missbrauchskampagnen Domains kurz vor Nutzung registrieren. First-seen-Aktivität kann in der Praxis noch nützlicher sein, weil eine Domain monatelang unbenutzt liegen kann und erst heute „aufwacht“, oder weil sie den Besitzer gewechselt hat.
Teams beziehen Domain‑Alter typischerweise aus WHOIS/RDAP‑Daten, Registrar‑ oder Registry‑Feeds (wenn verfügbar), passiven DNS‑ oder „first observed“-Datensätzen und aus der eigenen Produkt‑Historie (wann die Domain erstmals gesehen wurde).
Ein häufiges Problem sind fehlende oder unklare Daten. Einige Registrare schwärzen Details, Privacy‑Services verbergen Felder, und manche TLDs haben inkonsistente Einträge. Wenn das Domain‑Alter unbekannt ist, behandeln Sie es als unzuverlässig, nicht als automatisch negativ. Blockieren Sie nicht standardmäßig. Nutzen Sie es, um zu entscheiden, welche zusätzlichen Prüfungen anzuwenden sind.
Domain‑Alter ist ein Signal, kein Urteil. Viele echte Nutzer erstellen eine Domain und melden sich am selben Tag an. Gleichzeitig verlassen sich viele Fake‑Signups auf frisch registrierte Domains. Der Wert entsteht, wenn Sie Alter mit anderen Signalen kombinieren.
Domain‑Alter ist nützlich, aber es sagt nichts darüber, ob eine Adresse erreichbar ist. Bei Anmeldungen mit neu registrierten Domains kombinieren Sie Alter mit Validierungsprüfungen, die einfache Fragen beantworten wie „Ist das überhaupt eine E‑Mail?“ und „Kann diese Domain Mail empfangen?"
Beginnen Sie mit RFC‑konformen Syntaxprüfungen. Das ist schnell und fängt offensichtlichen Müll wie fehlende Bestandteile, ungültige Zeichen oder eingefügten Text, der gar keine E‑Mail ist. Syntax allein beweist nicht, dass ein Postfach existiert, aber sie entfernt viel Rauschen.
Prüfen Sie danach, ob die Domain in DNS existiert. Viele missbräuchliche Anmeldungen verwenden Tippfehler, zufällige Strings oder nie registrierte Domains. Das ergänzt das Domain‑Alter gut, weil beide Domain‑Level‑Signale sind.
Führen Sie dann eine MX‑Record‑Abfrage durch. Kann die Domain E‑Mails empfangen? Manche neue Domains sind registriert, aber noch nicht für Mail konfiguriert. Wenn Sie E‑Mails für Login‑Codes, Rechnungen oder Onboarding nutzen, ist fehlendes MX ein praktischer Grund, die Anmeldung zu verlangsamen oder zusätzlichen Nachweis zu verlangen.
Abschließend gleichen Sie gegen Disposable‑Provider und bekannte schlechte Infrastruktur ab. Domain‑Alter erkennt keinen lang existierenden Disposable‑Provider, und Blocklisten erfassen nicht immer brandneue Domains. Zusammen schließen sie sich gegenseitig Lücken.
Eine einfache Gedankenstütze:
Sie brauchen keine perfekte Risikobewertung, um zu beginnen. Ein simples Modell reicht: ordnen Sie die Domain in einen Alters‑Bucket ein, kombinieren Sie das mit dem Validierungsergebnis und führen Sie eine konsistente Aktion durch.
Halten Sie die Buckets breit, damit Sie später feinjustieren können:
Kombinieren Sie das Bucket mit einfachen Validierungsresultaten wie valid, invalid, disposable, risky und unknown (z. B. temporäre DNS‑Probleme).
Definieren Sie zwei Arten von Reaktionen, damit das Team nicht improvisiert:
Beispiel: Eine 2 Tage alte Domain mit Disposable‑Treffer ist meist ein Hard‑Fail. Eine 2 Tage alte Domain, die sauber validiert, kann ein Soft‑Fail sein: Konto anlegen, aber Verifizierung vor Trial‑Start verlangen.
Wie streng Sie sein sollten, hängt vom Produkt ab. B2B‑Produkte sehen oft legitime neue Domains (Startups, projektbezogene Domains), daher sind Soft‑Fails sicherer, wenn die Validierung stark aussieht. Consumer‑Apps sehen häufiger Wegwerfverhalten, hier können Sie bei 0–30 Tage‑Domains strenger sein.
Neue Domains sind nicht automatisch schlecht, aber Angreifer nutzen sie, um Identitäten schnell zu rotieren. Behandle Domain‑Alter als ein Signal und bestätige es mit dem, was Sie aus der E‑Mail selbst lernen können.
Validieren Sie die E‑Mail beim Signup (nicht nur Syntax). Bestätigen Sie, dass die Domain existiert, MX‑Einträge vorhanden sind und die Adresse nicht von einem bekannten Disposable‑Provider stammt.
Ermitteln Sie das Domain‑Alter (z. B. über WHOIS/RDAP oder Ihren Provider). Speichern Sie nicht das komplette WHOIS‑Blob. Bewahren Sie nur, was nötig ist: ein Erstellungsdatum, sofern verfügbar, den Lookup‑Status und das Alters‑Bucket.
Kombinieren Sie Signale zu einem klaren Risikoniveau. Halten Sie Regeln so einfach, dass Support und Produkt sie später verstehen können.
Führen Sie die Aktion aus: erlauben, Verifizierung verlangen, drosseln oder blocken.
Protokollieren Sie Eingaben und Ergebnisse. Gute Logs verwandeln die beste Einschätzung von heute in eine zuverlässige Policy von morgen.
Die Maßnahmen sollten sowohl zum Risiko als auch zu den Kosten passen. Eine 2 Tage alte Domain mit gültigem MX, aber als disposable markiert, ist hohes Risiko: blocken. Eine 5 Tage alte Domain mit sauberer Validierung ist mittleres Risiko: Konto erlauben, aber E‑Mail‑Verifizierung verlangen, bevor ein Trial gestartet oder Einladungen versendet werden.
Die meisten Anmeldungen sind legitim, sogar wenn eine Firmen‑Domain brandneu ist. Beginnen Sie mit stillen, wenig spürbaren Checks und fügen Sie Schritte nur hinzu, wenn das Risiko höher ist.
E‑Mail‑Validierung ist eine starke erste Schicht, weil sie schnell und unsichtbar für den Nutzer ist und häufige Probleme wie Tippfehler, ungültige Domains, fehlende MX‑Einträge und Disposable‑Provider abfängt.
Wenn Signale sich stapeln (z. B. sehr neue Domain plus fehlgeschlagene Domain‑Checks), eskalieren Sie mit progressiver Verifizierung. Halten Sie es einfach:
Ein nutzerfreundliches Muster ist, Kontoerstellung von Konto‑Fähigkeiten zu trennen. Statt sofort zu blocken, legen Sie das Konto an, aber schränken Sie es ein, bis die Verifizierung abgeschlossen ist. Lassen Sie Nutzer ein Passwort setzen und das Dashboard sehen, aber limitieren Sie sensible Aktionen wie Einladungen an Teammitglieder, Erstellung von API‑Schlüsseln, Exporte oder Trial‑Start.
Wiederholte Versuche verdienen besondere Behandlung, weil Angreifer schnell iterieren. Tracken Sie Signups pro IP, pro Gerät (wenn Sie das nutzen) und pro Domain. Wenn Sie viele Versuche in kurzer Zeit sehen, eskalieren Sie beim nächsten Versuch schneller.
Führen Sie stufenweise ein, damit Sie echte Nutzer nicht überraschen:
Regeln funktionieren am besten, wenn sie einfach, erklärbar und leicht anpassbar sind. Beginnen Sie mit wenigen Ergebnissen (allow, verify, block) und justieren Sie nach realem Traffic.
Starter‑Regeln, die die meisten Fälle abdecken:
Konkretes Beispiel: Jemand meldet sich mit [email protected] an, die Domain wurde gestern erstellt. Die Adresse besteht die Validierung und die Domain hat MX. Statt zu blocken erlauben Sie die Kontoanlage, verlangen aber E‑Mail‑Verifizierung, bevor Trial‑Credits ausgegeben werden. Wenn dieselbe Anmeldung einen Disposable‑Treffer hätte, würden Sie sofort blocken.
Der schnellste Weg, Schutz unbeliebt zu machen, ist ehrliche Nutzer zu bestrafen. Neu registrierte Domain‑Anmeldungen sind nicht automatisch schlecht. Ein sicherer Ansatz ist, „unbekannt“ von „böswillig“ zu trennen und nur dann Reibung hinzuzufügen, wenn mehrere Signale in dieselbe Richtung weisen.
Die Fehler, die am meisten Probleme machen, sind vorhersehbar:
Um das zu vermeiden, nutzen Sie Domain‑Alter als weiches Signal. Wenn Alterdaten fehlen oder widersprüchlich sind, verlassen Sie sich mehr auf Zustellbarkeitschecks wie Domain‑Verifikation, MX‑Lookup und Disposable‑Matching. Gehen Sie davon aus, dass Ihre Regeln getestet werden, fügen Sie Rate‑Limits und Logging hinzu und prüfen Sie wöchentlich die Ergebnisse (wie viele echte Nutzer wurden blockiert, und welche Checks waren prädiktiv?).
Bevor Sie Regeln für neu erstellte Domain‑Anmeldungen durchsetzen, machen Sie einen kurzen Setup‑Durchlauf, damit Sie offensichtlichen Missbrauch abfangen und echten Nutzern einen klaren Weg offenlassen.
Wenn Sie einem Kollegen Ihre Regeln in zwei Minuten erklären können, ist es bereit für einen ersten Release. Dann passen Sie anhand realer Daten an.
Ein SaaS‑Free‑Trial startet auf Product Hunt und erhält einen Spike an Anmeldungen mit neu registrierten Domains. Der Support wird mit Trial‑Nutzern zugespamt, die nie aktivieren, und das Vertriebsteam sieht die Bounce‑Raten steigen. Sie wollen offensichtlichen Missbrauch stoppen, ohne echte Teams zu bestrafen, die ihre Domain gestern registriert haben.
Eine einfache Regelmenge:
Vergleichen Sie nun zwei Anmeldungen.
Priya meldet sich mit [email protected] an. Die Domain ist 2 Tage alt. Die Validierung zeigt gültige Syntax, die Domain löst auf, MX‑Einträge sind vorhanden und sie ist nicht disposable.
Ergebnis: Sie wird nicht blockiert, aber sie muss ihre E‑Mail verifizieren, bevor sie vollen Trial‑Zugriff erhält. Das kostet Sekunden, nicht Minuten.
Ein Bot meldet sich mit [email protected] an. Die Domain ist 3 Stunden alt. Die Validierung zeigt fehlendes MX (oder einen Disposable‑Treffer), und ähnliche Muster wiederholen sich bei vielen Anmeldungen.
Ergebnis: Die Anmeldung wird sofort blockiert.
Nach dem Start messen Sie, ob der Kompromiss sich lohnt:
Justieren Sie Schwellenwerte langsam. Ziel ist, offensichtlichen Müll zu blocken und echte neue Teams weiterkommen zu lassen.
Behandeln Sie frühe Regeln wie eine Hypothese. Führen Sie sie ein paar Wochen im Monitoring‑Modus aus und protokollieren Sie, was passiert wäre: wer herausgefordert oder blockiert worden wäre und wie viele dieser Anmeldungen später riskant aussahen.
Protokollieren Sie für jeden Anmeldeversuch drei Dinge:
Justieren Sie danach. Wenn echte Nutzer mit brandneuen Domains blockiert werden, ändern Sie dieses Bucket von block zu step‑up‑Verifizierung. Wenn trotzdem noch Missbrauch durchkommt, verschärfen Sie Kombinationsregeln anstatt die Reibung für alle zu erhöhen.
Wenn Sie bereit sind, die E‑Mail‑Seite zu formalisieren, kann eine E‑Mail‑Validierungs‑API die Kernsignale schnell beim Signup liefern. Zum Beispiel gibt Verimail (verimail.co) RFC‑konforme Syntaxprüfungen, Domain‑Verifikation, MX‑Lookup und Echtzeit‑Disposable‑/Blocklist‑Abgleiche in einem einzigen Aufruf zurück, was es einfacher macht, strengere Regeln nur dann anzuwenden, wenn eine Domain sehr neu ist oder die Ergebnisse verdächtig aussehen.
Überprüfen Sie die Schwellenwerte monatlich. Missbrauch ändert sich, und Ihr Produkt ändert sich ebenfalls. Das Ziel ist, konstant Druck auf schlechten Traffic auszuüben, ohne gute Nutzer zu bestrafen.
