E-Mails mit Make (Integromat) verifizieren – so geht's

Sie können E-Mails schon heute mit Make (früher Integromat) verifizieren, auch wenn es in der App noch kein gebrandetes Qualisend-Modul gibt. Das Muster besteht darin, ein Szenario rund um das generische HTTP-Modul zu bauen: Ein Auslöser feuert, wenn eine neue Adresse eintrifft, eine HTTP-Anfrage schickt diese Adresse per POST an die Qualisend-API, und ein Router oder Filter liest das Urteil und verzweigt den Flow – sodass nur zustellbare Adressen zu Ihrem ESP oder CRM weiterlaufen und riskante oder unzustellbare geparkt werden. Dieser Leitfaden baut dieses Szenario von Anfang bis Ende auf.

Die kurze Antwort#

Es gibt derzeit keine native App zum Installieren (sie steht auf der Roadmap), also ist das unterstützte Muster ein dreiteiliges Szenario: ein Auslöser (neue Formularübermittlung, neue Zeile oder ein benutzerdefinierter Webhook, auf den Sie ein Formular zeigen lassen), ein Modul HTTP → Eine Anfrage stellen, das die Verifizierungs-API mit der E-Mail aufruft, und ein Router mit Filtern pro Route, die den zurückgegebenen status lesen und entscheiden, was als Nächstes passiert. Bewahren Sie Ihren API-Schlüssel in den Headern des Moduls auf – niemals in einem öffentlichen Formularfeld – und stellen Sie das HTTP-Modul so ein, dass es weiterläuft, falls die API einmal einen Fehler wirft, damit ein vorübergehender Aussetzer niemals einen echten Lead verwirft.

Zwei Wege, um E-Mails mit Make zu verifizieren#

Bevor Sie irgendetwas verdrahten, wählen Sie das Muster, das dazu passt, wie frisch die Daten sein müssen:

1. Echtzeit, pro Übermittlung (ein Szenario). Jede neue Adresse wird in dem Moment verifiziert, in dem sie eintrifft, und sofort weitergeleitet. Das ist das Hauptthema dieses Leitfadens und die richtige Wahl, wenn das Urteil ändert, was als Nächstes passiert – eine Double-Opt-in-E-Mail absichern, einen Lead taggen oder eine gefälschte Anmeldung überspringen.
2. Stapel, im Nachhinein (eine CSV). Lassen Sie Übermittlungen in einer Tabelle oder Ihrem ESP auflaufen, exportieren Sie sie regelmäßig und schicken Sie sie durch einen Stapelverifizierungs-Job. Einfacher, günstiger pro Adresse und die bessere Wahl, wenn Sie nur eine saubere Liste vor einem Versand brauchen statt einer sofortigen Entscheidung.

Die meisten Teams tun am Ende beides: ein Szenario auf dem Live-Eingang plus eine monatliche Listenreinigung, um Adressen abzufangen, die seit der Anmeldung veraltet sind.

Schritt 1: der Auslöser#

Beginnen Sie das Szenario mit dem, was die Adresse erfasst. Make hat Hunderte von Auslösermodulen – „Watch Responses“ in einer Formular-App, „Watch Rows“ in Google Sheets oder Airtable, „New Lead“ in einem CRM. Wenn Ihr Formular-Tool kein eigenes Make-Modul hat, setzen Sie einen benutzerdefinierten Webhook als erstes Modul ein und richten die Webhook-URL Ihres Formulars darauf; Make erzeugt eine eindeutige URL und zeigt Ihnen die Struktur der eingehenden Daten, sobald die erste Übermittlung eintrifft.

Was auch immer Sie wählen, die wichtige Ausgabe ist ein Feld mit der E-Mail-Adresse, auf das spätere Module als zugeordnetes Token verweisen – Make zeigt diese als farbige Pillen an, die Sie in ein Feld klicken und die aus dem Ausgabe-Bundle des Auslösers stammen. In den Beispielen unten ist dieses Token als {{1.email}} geschrieben, wobei 1 das Auslösermodul ist.

Schritt 2: Die Adresse mit dem HTTP-Modul per POST senden#

Fügen Sie ein Modul hinzu und wählen Sie HTTP → Eine Anfrage stellen. Das ist der Schritt, der Qualisend tatsächlich aufruft. Konfigurieren Sie ihn so:

Schalten Sie Antwort parsen ein, damit Make das JSON zurück in zuordenbare Felder liest statt in einen rohen String. Tippen Sie im Feld Anfrageinhalt den Body ein und ziehen Sie die E-Mail-Pille des Auslösers hinein:

{ "email": "{{1.email}}" }

Die Anfrage, die Make in Ihrem Namen abfeuert, sieht so aus – die Platzhalter füllen Sie aus den Entwicklerdokumenten, die den genauen Endpunkt auflisten und die Anfrage in mehreren Sprachen zeigen:

POST https://api.qualisend.com/v1/verify
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{ "email": "jane@example.com" }

Verwenden Sie einen für dieses Szenario erzeugten eingeschränkten Schlüssel (scoped key) statt eines Schlüssels mit Vollzugriff, damit der Schlüssel, falls die Ausführungshistorie des Szenarios jemals durchsickert, nur verifizieren kann und sonst nichts. Legen Sie den Schlüssel niemals in das Formular selbst oder ein clientseitiges Feld – er gehört ausschließlich in die Header des HTTP-Moduls, die serverseitig innerhalb von Make laufen.

Wenn Sie auf Einmal ausführen klicken, zeigt Make das Antwort-Bundle. Sie erhalten ein result-Objekt zurück, das einen status, einen reason-Code, einen score von 0–100 und eine Reihe von sub_flags enthält. Eine zustellbare Adresse kommt ungefähr so zurück:

{
  "result": {
    "status": "deliverable",
    "reason": null,
    "score": 95,
    "sub_flags": { "disposable": false, "role": false, "free": false, "catch_all": false }
  }
}

Auf diese Feldnamen verzweigt der nächste Schritt, achten Sie also darauf, wie Make sie zuordnet – Sie verweisen in Filtern auf result: status, result: score und die einzelnen sub_flags. Für das vollständige Bild, was jeder Status bedeutet und wie die Pipeline dorthin gelangt, siehe wie E-Mail-Verifizierung funktioniert.

Schritt 3: Mit einem Router auf das Urteil verzweigen#

Ein Verifizierungsergebnis, auf das Sie nicht reagieren, ist verschwendetes Guthaben. Der ganze Sinn besteht darin, Adressen unterschiedlich zu leiten, und in Make ist das das Router-Modul.

Setzen Sie einen Router hinter das HTTP-Modul, und er fächert sich in so viele Routen auf, wie Sie brauchen. Jede Route erhält ihren eigenen Filter – klicken Sie auf den Schraubenschlüssel an der Linie, die vom Router abgeht –, der den geparsten status aus der HTTP-Antwort prüft:

Make wertet Routen von links nach rechts aus, und sofern Sie eine Route nicht als Fallback markieren (die Route ohne Filter), läuft jede zutreffende Route – halten Sie Ihre Bedingungen auf status also gegenseitig ausschließend, damit nicht eine einzelne Adresse zwei Zweige hinunterläuft. Setzen Sie den Zweig undeliverable/kein Treffer als Fallback, damit nichts unkategorisiert durchrutscht.

Sie können auch auf die Unterflags verzweigen. Wenn Ihr Produkt reputationsempfindlich ist, fügen Sie der Prüfungsroute eine Bedingung hinzu, die auch dann feuert, wenn sub_flags: disposable gleich true ist, selbst wenn der Status ansonsten in Ordnung ist – dieselbe Einschätzung bei Wegwerf-, Rollen- und Freemail-Adressen, die die Aufschlüsselung nach Rollen-, Wegwerf- und Freemail-Adressen durchgeht. Ein einzelner Router-Filter akzeptiert mehrere UND/ODER-Bedingungen, sodass Sie eine status-Prüfung und eine sub_flags-Prüfung auf einer Route kombinieren können.

Lassen Sie das HTTP-Modul keinen guten Lead blockieren#

Eine Regel zählt mehr als jede Verzweigung: fail open (im Fehlerfall durchlassen). Wenn das HTTP-Modul einen Fehler wirft – die API ist kurz langsam, ein Tariflimit ist erreicht, ein Netzwerkaussetzer –, wollen Sie nicht, dass das gesamte Szenario stoppt und stillschweigend eine echte Anmeldung verschluckt. Klicken Sie mit der rechten Maustaste auf das HTTP-Modul, wählen Sie Fehlerbehandlung hinzufügen und hängen Sie eine Resume-Direktive an, die ein Standard-Bundle mit status auf unknown liefert. Das Szenario läuft dann einen Pfad hinunter weiter, der die Adresse als „später prüfen“ behandelt, statt sie zu verwerfen. (Sie können die Fehlerbehandlung des Szenarios auch so einstellen, dass sie unvollständige Ausführungen speichert, damit fehlgeschlagene Läufe für einen erneuten Versuch in die Warteschlange kommen, statt zu verschwinden.)

Eine Verifizierungs-API ist ein Qualitätsfilter, keine Authentifizierungsschranke. Einen zahlenden Kunden wegen eines vorübergehenden Ausfalls zu blockieren, ist ein weitaus schlimmeres Ergebnis, als eine fragwürdige Adresse durchzulassen und sie bei Ihrer nächsten Listenreinigung abzufangen. Dasselbe Fail-open-Prinzip liegt dem serverlosen Anmelde-Muster zugrunde, wo eine langsame Prüfung das Formular niemals ins Stocken bringen darf.

Wann ein Szenario das falsche Werkzeug ist#

Make ist Klebstoff, und Klebstoff hat einen Preis: Jede verifizierte Adresse verbraucht Operationen, und ein HTTP-Aufruf pro Übermittlung kann sich bei großem Volumen summieren oder überzogen wirken, wenn Sie keine sofortige Entscheidung brauchen. Greifen Sie stattdessen zum Stapel-Weg, wenn:

• Sie eine Liste reinigen, die bereits existiert – Tausende historischer Kontakte, kein neuer Eingang. Exportieren Sie sie und lassen Sie einen einzigen Stapeljob laufen.
• Ihr Volumen hoch genug ist, dass die Preisgestaltung pro Operation schmerzt, und eine nächtliche oder wöchentliche Reinigung frisch genug ist.
• Sie lieber kein Live-Szenario für eine Aufgabe pflegen möchten, die nur gelegentlich laufen muss.

Für alle drei überspringen Sie das Szenario: Exportieren Sie die Übermittlungen aus Ihrem Formular-Tool, Ihrer Tabelle oder Ihrem ESP als CSV und laden Sie diese Datei in den Stapelverifizierer von Qualisend hoch. Sie erhalten denselben status, den score und die Unterflags pro Zeile, herunterladbar als bereinigte Datei, die Sie erneut importieren können. Es ist der aufwandsärmste Weg, eine Liste gesund und Ihre Bounce-Rate niedrig zu halten, ohne irgendeine Automatisierung zu pflegen.

Wenn Sie den HTTP-Ansatz von Make gegen einen direkten Aufruf der API aus Ihrem eigenen Backend abwägen, legt der API-Vergleich die Abwägungen dar – ein Make-Szenario gewinnt bei der Einrichtungsgeschwindigkeit und braucht keinen Server, während eine direkte Integration bei Kosten und Kontrolle im großen Maßstab gewinnt. Dasselbe HTTP-Modul-Muster lässt sich auch sauber auf einen selbst gehosteten n8n-Workflow übertragen, wenn Sie der Operationspreisgestaltung von Make entwachsen.

Häufig gestellte Fragen#

Gibt es ein natives Qualisend-Modul für Make?#

Derzeit nicht. Die nativen Plattform-Integrationen von Qualisend werden gerade neu aufgebaut, deshalb gibt es in der Modulliste von Make noch keine gebrandete App, nach der man suchen könnte – sie steht auf der Roadmap. Bis sie erscheint, ist der unterstützte Weg, E-Mails mit Make zu verifizieren, das generische Modul HTTP → Eine Anfrage stellen, das auf die Qualisend-API zeigt, genau wie dieser Leitfaden es beschreibt. Der HTTP-Ansatz ist zudem flexibler: Sie steuern die Anfrage, die Header und die Routing-Logik selbst.

Wie viele Operationen verbraucht das Szenario pro E-Mail?#

Grob eine Operation pro Modul, das läuft: der Auslöser, die HTTP-Anfrage und die aktive Route des Routers zählen jeweils. Eine einzelne verifizierte Übermittlung ist also ein paar Operationen, und 1.000 Übermittlungen sind ein paar Tausend – gut innerhalb der meisten kostenpflichtigen Make-Tarife. Wenn Ihr Volumen die Preisgestaltung pro Operation schmerzhaft macht, leiten Sie diesen Traffic auf den Weg über CSV-Export und Stapelverifizierung um, der überhaupt keine Operationen verbraucht.

Welchen Status sollte ich an mein E-Mail-Tool durchlassen?#

Für eine strenge Schranke nur deliverable. Wenn Sie mehr Adressen behalten möchten, lassen Sie deliverable plus risky/unknown zu, leiten diese aber in ein separates Segment mit niedrigerer Priorität statt in Ihren Haupt-Flow – viele risky-Ergebnisse sind Catch-all-Domains, die dennoch zustellen können. Weisen Sie undeliverable immer ab und erwägen Sie, zusätzlich auf das disposable-Unterflag zu verzweigen, wenn Ihr Produkt reputationsempfindlich ist.

Wie teste ich das Szenario, bevor ich es aktiviere?#

Nutzen Sie die Schaltfläche Einmal ausführen von Make mit einer bekannt guten und einer bekannt schlechten Adresse und beobachten Sie, wie die Sprechblase am HTTP-Modul den zurückgegebenen status anzeigt – bestätigen Sie dann, dass jede Router-Route beim richtigen Input aufleuchtet. Für schnelle einmalige Stichproben außerhalb von Make fügen Sie eine Adresse in den kostenlosen E-Mail-Checker ein und vergleichen das Urteil mit dem, was Ihr Szenario zurückgibt.

Bereit, es zu bauen? Holen Sie sich einen eingeschränkten Schlüssel und die genaue Anfrageform aus den Entwicklerdokumenten, prüfen Sie jede beliebige Adresse im kostenlosen E-Mail-Checker und starten Sie mit dem kostenlosen Tarif – 100 Credits reichen aus, um das gesamte Szenario zu verdrahten und zuzusehen, wie eine schlechte Adresse gefiltert wird, bevor sie jemals Ihre Liste erreicht.