Unternehmen

Für Teams, deren E-Mails im Posteingang ankommen müssen.

Eine Kampagne geht raus, die Bounce-Rate schnellt hoch, und die Absenderdomain nimmt Schaden: Mails landen im Spam, und jemand muss erklären, warum. BounceIntel sorgt dafür, dass so eine Liste gar nicht erst versendet wird, und zeigt genau, warum jede Adresse entfernt wurde.

01Warum es uns gibt

Ein Ergebnis taugt nur so viel wie die Begründung dahinter.

Jedes Team, das E-Mails versendet, stößt irgendwann an dieselbe Wand. Eine Kampagne geht raus, die Bounce-Rate schnellt hoch, die Absender-Domain trägt den Reputationsschaden davon, und jemand muss im Meeting erklären, was schiefgelaufen ist. Das Prüfwerkzeug, das genau das verhindern sollte, liefert eine Farbe und eine Prozentzahl, und keines von beidem ist eine Erklärung.

BounceIntel geht von der gegenteiligen Annahme aus: Das Interessante an einer Prüfung sind die Belege, nicht das Fazit. Jede Prüfung liefert die Ursachencodes, die zum Ergebnis geführt haben, die Signale dahinter und eine Konfidenz, die ehrlich sagt, wie viel die Pipeline tatsächlich in Erfahrung bringen konnte.

Das verändert, wozu das Werkzeug dient. Es hört auf, ein Filter zu sein, dem man blind vertraut, und wird zu einer Quelle, die Sie zitieren können: in einem Deliverability-Review, in einer Datenschutz-Folgenabschätzung oder gegenüber der Kollegin, die wissen will, warum viertausend Adressen aussortiert wurden.

02So funktioniert es

Fünf Stufen, und ein Ergebnis, das seinen Rechenweg zeigt.

Dieselbe Pipeline steckt hinter dem kostenlosen Prüfer auf der Startseite, hinter dem Dashboard, hinter einem Massen-Upload und hinter der API. Es gibt keinen Premium-Pfad, der gründlicher prüft.

01

Syntax und Normalisierung

Die Adresse wird nach den Regeln des Standards geprüft, nicht nach einem irgendwo aufgelesenen regulären Ausdruck. Sieht eine Domain wie ein Vertipper bei einem großen Anbieter aus, sagen wir das, statt still zu scheitern: ein hier abgefangener Tippfehler ist ein Credit, der später nicht ausgegeben wird.

02

Domain- und MX-Auflösung

Wir lösen die Domain auf und lesen ihre MX-Einträge. Eine Domain ohne MX kann überhaupt keine Post empfangen: eine endgültige Antwort, noch bevor eine einzige Verbindung geöffnet wird, und die am günstigsten zu entfernende Klasse ungültiger Adressen.

03

Anbieterregeln

Große Anbieter setzen eigene Regeln für den lokalen Teil durch (Mindestlängen, unzulässige Zeichen, reservierte Wörter) und weisen Adressen zurück, die dagegen verstoßen, ganz gleich ob ein Postfach existieren könnte. Diese Regeln vor dem SMTP-Dialog anzuwenden spart den Umweg und liefert einen präziseren Ursachencode.

04

SMTP-Abfrage

Wir eröffnen einen Dialog mit dem empfangenden Server und fragen nach dem Empfänger, ohne je eine Nachricht zuzustellen. Dort zeigen sich Catch-all-Konfigurationen, deaktivierte und volle Postfächer, und dort verrät sich ein Server, der für jede Adresse dieselbe Antwort gibt.

05

Bewertung und Ursachencodes

Die Signale werden zu einem Score, einer Kategorie, einer Handlungsempfehlung und den zugehörigen Ursachencodes verdichtet. Reichen die Belege für keine belastbare Antwort, lautet das Ergebnis „unbekannt“. Das ist ein Befund, kein Fehlschlag, und es so zu behandeln verhindert, dass gute Adressen aussortiert werden.

03Grundsätze

Die Regeln, an die wir uns halten.

Die meisten davon kosten uns etwas. Das ist ungefähr der Test, ob ein Grundsatz echt ist.

01

Unsicherheit wird benannt, nicht kaschiert

Eine Catch-all-Domain lässt sich von außen tatsächlich nicht auflösen. Wir kennzeichnen sie und sagen, was das für Ihr Risiko bedeutet, statt zu raten, damit das Dashboard entschlossen aussieht.

02

Ihre Adressen sind nicht unser Datensatz

Nichts, was Sie einreichen, dient dazu, ein Verzeichnis aufzubauen, ein Produkt anzureichern, das wir verkaufen, oder irgendetwas zu trainieren. Massenadressen werden nie in unsere Datenbank geschrieben, sondern nur in den Report, den Sie herunterladen und der verfällt.

03

Eine Pipeline, eine Antwort

Die kostenlose Prüfung auf der Startseite führt denselben Code aus wie ein Enterprise-API-Aufruf. Es gibt keinen billigeren, ungenaueren Weg, der sich hinter einem niedrigeren Preis versteckt.

04

Erklärbarkeit als Standard

Ursachencodes gehören zu jeder Antwort; sie sind kein kostenpflichtiges Extra und kein Debug-Schalter. Wenn wir Ihnen das Warum nicht nennen können, hat das Ergebnis Ihr Vertrauen nicht verdient.

05

Wir sagen zu Aufträgen auch Nein

Gescrapte Listen, gekaufte Listen und Adress-Enumeration lehnen wir ab; Konten, die das tun, werden geschlossen. Ein Prüfdienst, der seine Eingaben nicht kontrolliert, wird zum Werkzeug genau derer, vor denen er schützen sollte.

06

Aufbewahrung ist ein Standard, keine Einstellung

Reports verfallen von selbst. Einen zu löschen löscht die Adressen, denn es liegt keine zweite Kopie in einer Datenbank, die man irgendwann vergisst.

04In Zahlen

Größenordnung, nüchtern benannt.

Volumen ersetzt keine Genauigkeit, macht sie aber messbar: Je mehr Postfächer eine Pipeline gesehen hat, desto besser kennt sie das Verhalten der einzelnen Anbieter.

1B+
Geprüfte E-Mail-Adressen, Tendenz steigend
40
Ursachencodes in der veröffentlichten Taxonomie
< 500ms
Medianlatenz einer Einzelprüfung
EU
Wo die Prüfung läuft und die Daten liegen

05FAQ

Fragen, bevor Sie uns eine Liste schicken

Wer steht hinter BounceIntel?

Ein unabhängiges Unternehmen mit Sitz in der Europäischen Union. Der Dienst, den Sie unter api.bounceintel.com aufrufen, ist unser eigener: selbst entwickelt und selbst betrieben, nicht von einem anderen Anbieter weiterverkauft. Die Registerangaben stehen auf der Kontaktseite und in unseren Rechtsdokumenten.

Speichern Sie die Adressen, die ich hochlade?

Nicht in unserer Datenbank. Eine Massenliste existiert nur in den für Sie erzeugten Report-Dateien: Sie liegen außerhalb des Web-Roots, sind ausschließlich über einen authentifizierten Download erreichbar und werden mit Ablauf der Aufbewahrungsfrist gelöscht. Was wir behalten, ist aggregiert: wie viele als sicher, riskant, ungültig oder unbekannt zurückkamen.

Warum kommen manche Prüfungen als „unbekannt“ zurück?

Weil manche Mailserver nicht preisgeben, ob ein Postfach existiert, und andere vorübergehend nicht erreichbar sind. In solchen Fällen ein Ergebnis zu erfinden ist der Weg, auf dem ein Prüfwerkzeug gute Kunden aussortiert. Wir sagen Ihnen, was passiert ist, und überlassen Ihnen die Entscheidung.

Wie wird eine Catch-all-Domain behandelt?

Ein Catch-all nimmt jede Adresse an, also kann kein externer Test ein echtes von einem erfundenen Postfach unterscheiden. Wir erkennen die Konfiguration, bewerten das Risiko anhand der übrigen verfügbaren Signale (Anbieterverhalten, Domain-Reputation, historische Zustellergebnisse) und weisen die Konfidenz ehrlich aus.

Darf ich das für eine gekaufte Liste nutzen?

Nein. Unsere Nutzungsrichtlinie verbietet gekaufte, gescrapte und über Broker bezogene Listen, und wir setzen das durch. Die Prüfung bestätigt, dass rechtmäßig vorhandene Adressen noch aktiv sind; sie macht keine unzulässige Liste verwendbar.

Gibt es einen Auftragsverarbeitungsvertrag?

Ja, und er gilt automatisch als Teil unserer Bedingungen; Sie müssen nichts unterschreiben, damit er uns bindet. Wenn Ihr Einkaufsprozess eine gegengezeichnete Fassung oder die separat unterzeichneten Standardvertragsklauseln verlangt, sagen Sie Bescheid, dann richten wir das ein.

Schicken Sie uns die Liste, bei der Sie am unsichersten sind.

100 Credits bei der Registrierung, ohne Karte, und dieselbe Pipeline, auf der ein Enterprise-API-Aufruf läuft.