Häufige Fragen

E-Mail-Verifizierung findet die Adressen, die bouncen würden, bevor Sie an sie senden. Das ist wichtig, weil eine hohe Bounce-Rate Ihrer Absenderreputation schadet und auch Ihre übrigen Mails in Richtung Spam drückt. Technisch wird dabei festgestellt, ob eine Adresse tatsächlich Post empfangen kann, ohne ihr etwas zu senden. Eine Prüfung untersucht die Syntax der Adresse, bestätigt, dass die Domain existiert und MX-Einträge veröffentlicht, eröffnet ein Gespräch mit dem empfangenden Mailserver und fragt, ob dieser eine Nachricht für dieses Postfach annehmen würde. Das Ergebnis ist ein Verdikt, keine Garantie, denn manche empfangenden Server verweigern die Antwort auf diese Frage bewusst.

Posteingangsanbieter wie Gmail und Outlook beobachten, wie viele Ihrer Mails zurückkommen. Wer an Adressen sendet, die nicht existieren, signalisiert eine veraltete, gekaufte oder schlecht gesammelte Liste, also typische Gewohnheiten von Spammern, und die Anbieter vertrauen Ihrer Domain weniger. Weniger Vertrauen heißt, dass mehr Ihrer Mails im Spam landen, auch die an echte, aktive Kunden. Der Schaden hängt an Ihrer Absenderdomain und IP, nicht an den fehlerhaften Adressen. Deshalb kann ein einziger unachtsamer Versand alles beeinträchtigen, was Sie danach verschicken.

Meist drei Dinge, ungefähr in dieser Reihenfolge. Posteingangsanbieter verzögern Ihre Mails oder sortieren sie in den Spam. Ihre E-Mail-Plattform bemerkt es, weil hohe Bounce-Raten ihre eigene geteilte Reputation gefährden, und kann Ihr Konto prüfen, drosseln oder pausieren, bis die Liste bereinigt ist. Danach braucht die Erholung Zeit: Eine beschädigte Domain muss über Wochen mit sauberem, gleichmäßigem Versand wieder Vertrauen aufbauen, und manche Teams geben auf und wechseln zu einer neuen Domain. Vor dem Versand zu prüfen ist deutlich günstiger als jeder dieser Schritte.

In der Praxis meinen beide Begriffe dasselbe, und alle Anbieter in dieser Kategorie verwenden sie austauschbar. Wo überhaupt unterschieden wird, prüft Validierung, ob eine Adresse wohlgeformt und ihre Domain echt ist, während Verifizierung zusätzlich die Prüfung auf Postfachebene gegen den empfangenden Server umfasst. BounceIntel erledigt beides in einem Aufruf und sagt Ihnen, welche Stufe das Verdikt hervorgebracht hat.

Nein. Die Prüfung endet vor der Zustellung. Sie eröffnet ein SMTP-Gespräch mit dem empfangenden Server, fragt, ob eine Nachricht für diese Adresse angenommen würde, und schließt die Verbindung, bevor irgendein Nachrichtentext übertragen wird. Die Person hinter dem Postfach sieht nichts und erhält nichts.

Bei gewöhnlichen Postfächern der großen Anbieter ist eine Verifizierung verlässlich und dem Verdikt kann man folgen. Die Genauigkeit sinkt in zwei bestimmten, erkennbaren Situationen: bei Catch-all-Domains, die Post für jede Adresse annehmen und daher keine einzelne bestätigen können, und bei Servern, die Greylisting einsetzen oder eine Antwort auf Verifizierungsverkehr anderweitig verweigern. Wir melden beides als eigene Verdikte, statt es in einer Prozentzahl aufzulösen. Wir veröffentlichen keine plakative Genauigkeitszahl, weil keine Zahl in dieser Kategorie unabhängig überprüfbar ist, und eine Zahl, die Sie nicht nachprüfen können, ist keine Tatsache.

Kontaktdaten verfallen fortlaufend, die nützliche Antwort ist also ein Rhythmus und keine einmalige Aktion. Prüfen Sie bei der Erfassung, damit nichts Schlechtes hineingelangt, und prüfen Sie ein Segment erneut, bevor Sie ihm schreiben, wenn es länger als ein paar Monate geruht hat. Eine Liste, die ein Jahr ohne Prüfung geblieben ist, sollte als unbekannt gelten, bis sie kontrolliert wurde.

Nein, und jeder Anbieter, der das verspricht, beschreibt etwas, das sich nicht bauen lässt. Ein Postfach kann zwischen dem Zeitpunkt der Prüfung und dem Versand geschlossen werden. Ein volles Postfach kann eine Nachricht eine Stunde nach einer angenommenen Verifizierung ablehnen. Die Verifizierung entfernt die Adressen, die ohnehin nie funktioniert hätten, also die große Mehrheit der vermeidbaren Bounces, und sagt Ihnen, welche der übrigen unsicher sind.

Zustellbar heißt, das Postfach existiert und nimmt Post an: senden. Riskant heißt, die Adresse ist echt, doch etwas mahnt zur Vorsicht, etwa ein Rollenkonto oder eine Catch-all-Domain: mit Augenmaß senden. Nicht zustellbar heißt, die Adresse wird bouncen: nicht senden. Unbekannt heißt, der empfangende Server wollte keine Antwort geben, was eine Information über den Server ist und nicht über die Adresse.

Das Verdikt ist die kategoriale Antwort, der Score die abgestufte. Zwei Adressen können beide zustellbar sein, während die eine ein langjähriges Postfach bei einem großen Anbieter ist und die andere ein frisches Konto auf einer unbekannten Domain. Der Score trägt diesen Unterschied, damit Sie Ihre eigene Schwelle setzen statt unsere zu übernehmen. Dazu kommt ein Konfidenzniveau, das angibt, auf wie viel Evidenz er beruht.

Ein Reason Code benennt den konkreten Befund, der zum Verdikt geführt hat, und ist stabil genug, um im Code darauf zu verzweigen. Das ist der Unterschied zwischen einem Ergebnis, mit dem man arbeiten kann, und einer Zahl, der man glauben muss. Wird eine Adresse gesperrt, sagt der Reason Code, ob Syntax, Domain, Postfach oder die Reputation des Anbieters den Ausschlag gab, sodass sich eine Entscheidung Monate später einer Kollegin, einem Kunden oder einer Prüfung erklären lässt.

Unbekannt heißt, der empfangende Server hat eine Antwort verweigert, nicht dass die Adresse schlecht ist. Manche Server greylisten unbekannte Verbindungen und verzögern beim ersten Kontakt alles. Manche begrenzen oder verweigern Verifizierungsverkehr aus Prinzip. Manche sind im Moment der Prüfung schlicht nicht erreichbar. Unbekannt wie nicht zustellbar zu behandeln bedeutet, gute Adressen wegzuwerfen, und genau deshalb ist es ein eigenes Verdikt und kein in ein anderes eingeschmolzener Fall.

Eine Catch-all-Domain ist so eingerichtet, dass sie Post an alles auf dieser Domain annimmt, ob das Postfach existiert oder nicht, der Server bejaht also jede Frage. Kein Verifizierer kann beweisen, dass hinter einem Catch-all ein bestimmtes Postfach steht, und wer das Gegenteil behauptet, rät. Wir geben die Adresse als riskant mit angehängtem Catch-all-Grund zurück, damit Sie je Segment entscheiden: bei einer warmen Liste oft das Risiko wert, bei Kaltakquise auf einer jungen Versanddomain meist nicht.

Ein Rollenkonto gehört einer Funktion und nicht einer Person: info, support, sales, admin, buchhaltung. Es ist meist zustellbar und wird daher nicht als ungültig markiert, wird aber oft von mehreren oder von niemandem gelesen und erzeugt bei Marketingpost eher eine Beschwerde. Es wird markiert statt entfernt, weil die richtige Antwort davon abhängt, was Sie senden. Behalten Sie sie für transaktionale und Supportpost, und überlegen Sie zweimal, bevor Sie sie in eine Kampagne aufnehmen.

Eine Spam-Falle ist eine Adresse, die nur existiert, um Absender zu erkennen, die ihre Listen nicht pflegen. Unberührte Fallen waren nie gültige Adressen; recycelte Fallen sind aufgegebene Postfächer, die der Anbieter wieder aktiviert. Von außen kann niemand eine Falle mit Sicherheit erkennen, und jeder Anbieter, der einen definitiven Spam-Fallen-Detektor behauptet, übertreibt. Was Verifizierung leistet, ist die Bedingungen zu beseitigen, unter denen Fallen leben: lange ruhende Adressen, Adressen, die nicht mehr auflösen, und Listen, die seit Jahren nicht geprüft wurden.

Ein Hard Bounce ist dauerhaft: Die Adresse existiert nicht, oder die Domain nimmt keine Post an. Er zählt gegen Ihre Absenderreputation und die Adresse sollte sofort gesperrt werden. Ein Soft Bounce ist vorübergehend: ein volles Postfach, ein ausgefallener Server, eine zu große Nachricht. Verifizierung zielt auf die Hard Bounces, denn nur sie sind zugleich im Voraus vorhersehbar und schädlich, wenn sie eintreten.

Vier Stufen, der Reihe nach, mit Abbruch, sobald eine Antwort feststeht. Die Syntax, die fehlerhafte Adressen ohne jeden Netzwerkverkehr abweist. DNS und MX, die bestätigen, dass die Domain existiert und einen Mailserver veröffentlicht. Das SMTP-Gespräch mit diesem Server, in dem das Postfach selbst geprüft wird. Und eine Reihe von Klassifikationssignalen: ob die Domain eine Wegwerfdomain ist, ob die Adresse ein Rollenkonto ist, ob das Postfach deaktiviert oder voll ist und welcher Anbieter dahintersteht.

Im Normalfall deutlich unter einer Sekunde, schnell genug für den Handler eines Anmeldeformulars. Die Variable ist der empfangende Server: Manche antworten sofort, manche verzögern unbekannte Verbindungen bewusst. Setzen Sie ein zu Ihrem Formular passendes Zeitlimit und legen Sie den Rückfall vorher fest. Die meisten Teams nehmen die Adresse an und markieren sie, statt eine Anmeldung wegen einer langsamen Fremdabfrage zu blockieren.

Ja. Die Antwort nennt den Anbieter, etwa Google Workspace oder Microsoft 365, zusammen damit, wie sicher diese Zuordnung ist. Das ist mehr als Neugier: Der Anbieter ist eine der Eingangsgrößen des Scores, und er sagt Ihnen, welche Ihrer Empfänger hinter den Reputationssystemen liegen, die für die Zustellbarkeit am meisten zählen.

Ja, bei jeder Prüfung, als Kennzeichen in der Antwort und nicht als eigenes Produkt. Eine eigene Liste von Wegwerfdomains zu pflegen ist ein Wettlauf, den man verliert, weil neue schneller auftauchen, als irgendwer sie eintragen kann, und genau deshalb gehört das in eine Abfrage und nicht in Ihren Code.

Laden Sie im Dashboard eine CSV hoch, oder schicken Sie die Adressen an den Massenendpunkt und fragen Sie das Ergebnis ab. In beiden Fällen läuft der Auftrag asynchron, es muss also nichts eine Verbindung offen halten, und der Fortschritt ist währenddessen ablesbar. Die Ergebnisse kommen je Adresse in derselben Struktur zurück wie bei einer Einzelprüfung, alles was Sie für die eine gebaut haben, funktioniert also auch für die andere.

Groß genug, dass die praktische Grenze Ihr Credit-Guthaben ist und nicht der Auftrag. Sehr große Listen schickt man am besten als mehrere Aufträge, damit Sie mit den ersten Ergebnissen arbeiten können, während der Rest läuft, und damit ein einzelner erneuter Versuch nicht alles neu startet.

Ergebnisse gibt es als JSON über die API und als Download-Datei im Dashboard. Die Datei enthält feste Ergebnisspalten, verknüpft über die Adresse, und nicht Ihre ursprünglichen Zeilen, damit sie sich jedes Mal gleich importieren lässt. Verbinden Sie sie über die Adressspalte wieder mit Ihrem eigenen System. Zusätzlich gibt es einen Übersichtsbericht für alle, die die Form der Liste sehen wollen und nicht ihre Zeilen.

Nicht beim Upload über das Dashboard: Doppelte Adressen werden vor dem Start zusammengefasst, sodass jede nur einmal geprüft und berechnet wird. Ein über die API übermittelter Auftrag wird pro Adresse in der Anfrage berechnet, entfernen Sie Dubletten also vorher. So oder so lohnt sich das bei Listen aus mehreren Quellen, wo Dubletten häufig sind und die scheinbare Listengröße aufblähen.

Ja, und sie ist der Hauptweg, das Produkt zu nutzen. Ein REST-Endpunkt verifiziert eine einzelne Adresse, ein weiterer sendet und fragt Massenaufträge ab, beide authentifizieren sich per Bearer-Token. Die Dokumentation enthält Anfrage- und Antwortbeispiele für jeden Endpunkt sowie eine Spielwiese, die Sie direkt von der Seite aus live aufrufen können.

Die Dokumentation zeigt cURL, TypeScript, Python und Go, alle als schlichte HTTP-Aufrufe ohne SDK. Das ist Absicht: Die API ist klein genug, dass ein SDK eine Abhängigkeit hinzufügen würde, ohne Arbeit abzunehmen, und ein einfacher Fetch-Aufruf lässt sich in jeder Sprache lesen und nachvollziehen.

Fehler kommen mit einem stabilen, maschinenlesbaren Code neben dem HTTP-Status zurück, sodass Wiederholungslogik auf den Code verzweigen kann statt eine Meldung zu parsen. Eine Ratenbegrenzung und ein aufgebrauchtes Credit-Guthaben liefern beide 429, aber mit unterschiedlichen Codes, weil das eine nach einer Pause einen erneuten Versuch verdient und das andere nicht. Die Dokumentation listet jeden Code und die zugehörige Handlung.

Ja. Die Dokumentation enthält eine Live-Spielwiese, die echte Anfragen an die echte API stellt, sodass Sie die Form einer tatsächlichen Antwort sehen, bevor Sie Code schreiben.

Sie können mehrere Schlüssel gleichzeitig halten und jeden davon einzeln widerrufen, was genau das ist, was man braucht, um Staging von Produktion zu trennen oder einem externen Mitarbeiter einen Schlüssel zu geben, den man zurückziehen kann, ohne alles andere zu rotieren.

Ein Credit verifiziert eine Adresse, ob sie aus der API, aus einem Massenupload oder aus dem Dashboard kommt. Credits werden in Monatstarifen oder als Pakete nach Verbrauch gekauft, und der Preis pro Credit sinkt mit steigendem Volumen. Es gibt keine gesonderte Gebühr für die API, keine Kosten je Nutzer und keine Mindestvertragslaufzeit.

Eine Prüfung, die den empfangenden Server erreicht, verbraucht einen Credit, egal wie die Antwort ausfällt, unbekannt eingeschlossen, denn die Arbeit wurde geleistet und das Ergebnis ist echte Information über diesen Server. Eine Anfrage, die scheitert, bevor überhaupt eine Verifizierung stattfindet, etwa eine fehlerhafte Anfrage, verbraucht keinen.

Die API gibt 429 mit einem Kontingent-Code zurück, der sich vom Code für die Ratenbegrenzung unterscheidet, sodass Ihre Integration zwischen warten und aufladen unterscheiden kann. Nichts wird gelöscht und kein Auftrag geht verloren: Credits nachlegen und derselbe Auftrag läuft weiter.

Credits nach Verbrauch bleiben auf dem Konto. Tarif-Credits erneuern sich mit dem Zyklus des Tarifs. Die Preisseite nennt die Bedingungen jedes Tarifs ausdrücklich und nicht in einer Fußnote, denn verfallende Credits sind die häufigste unangenehme Überraschung in dieser Kategorie.

Für jede Zahlung wird eine Rechnung ausgestellt, die im Abrechnungsbereich verfügbar ist. Für Jahreslaufzeiten, größere Volumina oder Beschaffungsanforderungen schreiben Sie uns, und wir kalkulieren auf Ihr tatsächliches Volumen, statt Sie in die nächstgelegene veröffentlichte Stufe zu drängen.

Neue Konten starten mit einem Credit-Kontingent, sodass Sie eine echte Stichprobe Ihrer eigenen Daten prüfen können, bevor Sie sich entscheiden. Eine Karte ist dafür nicht erforderlich.

Sie werden verarbeitet, um das angefragte Verdikt zu erzeugen, und für sonst nichts. Ihre Adressen werden nicht verkauft, nicht weitergegeben, keiner Liste hinzugefügt und nicht dafür verwendet, eine Datenbank aufzubauen, die an irgendwen weiterverkauft wird. Die Datenschutzerklärung führt das aus, und der Auftragsverarbeitungsvertrag macht es vertraglich verbindlich.

Verifizierungsergebnisse bleiben so lange in Ihrem Konto verfügbar, wie Sie sie brauchen, und die Daten eines Massenauftrags können im Dashboard gelöscht werden, sobald Sie die Ergebnisse heruntergeladen haben. Die Aufbewahrungsfristen stehen in der Datenschutzerklärung.

Ja. Es gibt eine DSGVO-Seite, die beschreibt, wie die Verordnung speziell auf E-Mail-Verifizierung anzuwenden ist, einen Auftragsverarbeitungsvertrag für jeden Kunden und eine veröffentlichte Liste der Unterauftragsverarbeiter, die an der Erbringung des Dienstes beteiligt sind. Alle drei sind aus der Fußzeile jeder Seite verlinkt.

Die Verifizierungsplattform und ihre Datenbank werden in der Europäischen Union gehostet. Einige unterstützende Dienste, darunter Zahlungen und transaktionale E-Mail, arbeiten teilweise außerhalb; die Seite der Unterauftragsverarbeiter nennt jeden Dritten, was er tut und wo er sitzt, sodass Sie Ihre Lieferantenprüfung abschließen können, ohne nachfragen zu müssen.

API-Schlüssel werden einmal angezeigt und gehasht gespeichert, ein Schlüssel lässt sich von unserer Seite also nicht wiederherstellen, nur ersetzen. Jeder Schlüssel ist einzeln widerrufbar. Der Zugriff auf Produktionssysteme ist auf die Personen beschränkt, die ihn brauchen, und die Sicherheitsmaßnahmen, die wir betreiben, sind auf den Rechtsseiten beschrieben statt als Abzeichen dargestellt.

Schreiben Sie dem Support direkt. Es gibt keine Ticket-Warteschlange zu durchlaufen und keine Stufe, die erst gekauft werden muss, bevor ein Mensch antwortet. Nennen Sie die Adresse oder die Auftrags-ID, um die es geht, dann fällt die Antwort konkret statt allgemein aus.

Ja. Das Volumen wird über das Konto gebündelt, und genau das macht es für eine Agentur oder ein Team mit mehreren Kunden lohnend: ein Guthaben, ein Preis, getrennte Schlüssel.

Ja, in den Kontoeinstellungen, und die Löschung wird bestätigt statt still ausgeführt. Sie entfernt das Konto und die zugehörigen Daten, mit der einzigen Ausnahme der Unterlagen, die wir gesetzlich aufbewahren müssen und die die Datenschutzerklärung aufführt.

Website und Produktoberfläche sind auf Englisch, Französisch, Spanisch, Italienisch und Deutsch verfügbar. Der Support antwortet auf Englisch.