Anmeldungen mit neu registrierten Domains: Missbrauch erkennen und verhindern

Warum neu registrierte Domains bei Missbrauchs-Anmeldungen auftauchen

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.

Was „Domain-Alter“ ist und was es (nicht) aussagt

„Domain-Alter" bezieht sich meist auf eines von zwei Dingen:

• Registrierungsalter: wann die Domain beim Registrar registriert wurde.
• First-seen‑Aktivität: wann die Domain erstmals in Signalen wie DNS‑Datensätzen, E‑Mail‑Traffic oder Sicherheits‑Telemetry aufgetaucht ist.

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.

E-Mail‑Validierungssignale, die gut mit Domain‑Alter harmonieren

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:

• Syntax bestätigt, dass die Eingabe wie eine E‑Mail aussieht.
• DNS‑ und Domain‑Checks bestätigen, dass die Domain echt ist und antwortet.
• MX bestätigt, dass die Domain für E‑Mail eingerichtet ist.
• Disposable‑ und Blocklist‑Checks markieren schnelle Hochrisiko‑Quellen.

Ein einfaches Entscheidungsmodell: Domain‑Alter einordnen, dann handeln

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:

• 0–7 Tage: höchstes Risiko
• 8–30 Tage: erhöhtes Risiko
• 31–180 Tage: mittel bis geringes Risiko
• 180+ Tage: niedrigstes Risiko

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:

• Hard fail: Anmeldung sofort blocken (deutliche ungültige E‑Mail, klarer Disposable‑Treffer, offensichtliche Syntaxfehler).
• Soft fail: den Nutzer weitermachen lassen, aber Reibung hinzufügen (E‑Mail‑Verifizierung, CAPTCHA, Rate‑Limits, manuelle Überprüfung oder Verzögerung des Zugriffs bis zur Verifikation).

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.

Schritt für Schritt: Domain‑Alter mit Validierungsergebnissen kombinieren

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.

1. 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.

2. 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.

3. Kombinieren Sie Signale zu einem klaren Risikoniveau. Halten Sie Regeln so einfach, dass Support und Produkt sie später verstehen können.

4. Führen Sie die Aktion aus: erlauben, Verifizierung verlangen, drosseln oder blocken.

5. 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.

Progressive Verifizierungsregeln, die Reibung für echte Nutzer minimieren

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:

• Niedriges Risiko: normaler Signup
• Mittleres Risiko: E‑Mail‑OTP‑Verifizierung
• Hohes Risiko: CAPTCHA plus E‑Mail‑OTP
• Wiederholte Versuche: temporäre Rate‑Limits und Cooldowns
• Klarer Missbrauch: blocken

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:

• Woche 1: nur überwachen (Entscheidungen protokollieren, nicht blocken)
• Woche 2: nur die risikoreichsten Fälle durchsetzen
• Woche 3: Durchsetzung ausweiten und Schwellenwerte anpassen

Praktische Regelbeispiele, mit denen Sie starten können

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:

• Wenn eine Domain sehr neu ist und kein MX hat (oder die Domain nicht zuverlässig auflösbar ist), blocken und nach einer anderen E‑Mail fragen.
• Wenn eine Domain sehr neu ist, MX hat, aber die Adresse disposable ist, blocken.
• Wenn eine Domain sehr neu ist, die Validierung besteht und sie nicht disposable ist, erlauben Sie die Anmeldung, verlangen Sie aber E‑Mail‑Verifizierung bevor Sie Zugriff auf wertvolle Funktionen gewähren (Trial‑Aktivierung, API‑Schlüssel, Exporte).
• Wenn eine Domain älter ist und die Validierung sauber ist, nutzen Sie Ihren normalen Ablauf.
• Wenn das Domain‑Alter unbekannt ist und die Signale gemischt sind, behandeln Sie es als mittleres Risiko und schränken Sie sensible Aktionen hinter Verifizierung oder Review.

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.

Häufige Fehler und Fallen, die Sie vermeiden sollten

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:

• Alle Domains unter X Tagen blocken
• WHOIS‑Erstellungsdaten als unumstößliche Wahrheit behandeln
• Bei Syntaxprüfungen stehen bleiben
• Nie False Positives messen
• Angreifern erlauben, Ihre Regeln zu sondieren (keine Rate‑Limits bedeutet, sie können Varianten testen, bis sie Lücken finden)

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

Schnelle Checkliste für einen sicheren Rollout

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.

• Bestätigen Sie, welche Ergebnisse Ihre E‑Mail‑Checks liefern: Syntax, Domain/DNS, MX, Disposable‑Erkennung und eventuelle Risikoflags.
• Wählen Sie Domain‑Alter‑Buckets und notieren Sie die Aktion für jedes Bucket.
• Bevorzugen Sie Step‑Up‑Verifizierung statt einer einzigen harten Mauer.
• Protokollieren Sie jede Entscheidung in klarem, einfachem Text (Alter‑Bucket, Validierungs‑Signale, Aktion, Grund).
• Erstellen Sie einen Override‑Weg für legitime Nutzer, die markiert wurden.

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.

Beispiel‑Szenario: Fake‑Trials stoppen, ohne neue Teams zu blocken

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:

• Wenn das Domain‑Alter unter 7 Tagen liegt, verlangen Sie E‑Mail‑Verifizierung, bevor das Konto einen Trial starten kann.
• Wenn das Domain‑Alter unter 24 Stunden liegt und die E‑Mail riskant aussieht (disposable, blocklisted oder fehlendes MX), blocken Sie.
• Wenn das Domain‑Alter 7+ Tage ist und die Validierung sauber ist, erlauben Sie sofortigen Trial.

Vergleichen Sie nun zwei Anmeldungen.

Anmeldung A: ein echtes Startup

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.

Anmeldung B: ein automatischer Spammer

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:

• Trial‑zu‑Aktivierungs‑Rate (gesamt und für Domains unter 7 Tagen)
• E‑Mail‑Bounce‑Rate und Zustellbarkeit
• Missbrauchsrate (Fake‑Trials, Bot‑Anmeldungen, Spam‑Reports)
• Verifizierungsabschlussrate und Zeit‑bis‑Verifizierung
• Support‑Tickets zu Anmeldung und Zugang

Justieren Sie Schwellenwerte langsam. Ziel ist, offensichtlichen Müll zu blocken und echte neue Teams weiterkommen zu lassen.

Nächste Schritte: messen, justieren und eine Validierungsschicht hinzufügen

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:

• Domain‑Alter‑Bucket und die dadurch ausgelöste Aktion
• E‑Mail‑Validierungsresultat (valid, risky, invalid, disposable)
• Ergebnis einige Tage später (Chargeback, Spam‑Report, Bounce, Support‑Beschwerde oder gesunder Nutzer)

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.