E-Mails mit n8n verifizieren – so geht's

Sie können E-Mails schon heute mit n8n verifizieren, ohne auf eine gebrandete Node zu warten – die generische HTTP-Request-Node von n8n ruft die Qualisend-API problemlos auf, und weil n8n Open Source und selbst hostbar ist, läuft der gesamte Ablauf auf einer Infrastruktur, die Sie kontrollieren, wobei der API-Schlüssel im eigenen Credential-Speicher von n8n liegt. Der Aufbau besteht immer aus denselben drei Nodes: Ein Trigger erfasst die Adresse, eine HTTP-Request-Node sendet sie per POST an Qualisend, und eine IF- oder Switch-Node liest den zurückgegebenen status und leitet jedes Ergebnis weiter. Dieser Leitfaden baut genau diesen Workflow von A bis Z auf.

Die kurze Antwort#

Eine native Qualisend-Node gibt es in n8n noch nicht (sie steht auf der Roadmap), deshalb ist das unterstützte Muster ein Workflow mit generischen Nodes: ein Trigger (Webhook, Formular, neue Zeile, Zeitplan), eine HTTP-Request-Node, die die E-Mail mit Ihrem Schlüssel aus einem gespeicherten Zugangsdatensatz per POST an die Verifizierungs-API sendet, und eine IF- oder Switch-Node, die anhand von result.status verzweigt. Halten Sie den Schlüssel in einem n8n-Credential – niemals inline in die Node oder in ein öffentliches Feld eingefügt – und lassen Sie eine Adresse im Zweifel durch, falls der HTTP-Aufruf je fehlschlägt, damit ein vorübergehender Aussetzer niemals stillschweigend eine echte Anmeldung verwirft.

Zwei Wege, E-Mails mit n8n zu verifizieren#

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

1. Echtzeit, pro Datensatz (ein Live-Workflow). 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 Ergebnis verändert, was als Nächstes passiert – das Freigeben einer Willkommens-E-Mail, das Taggen eines Leads oder das Überspringen einer gefälschten Anmeldung.
2. Batch, im Nachhinein (eine CSV). Lassen Sie Datensätze in einer Tabelle, Datenbank oder einem CRM auflaufen, exportieren Sie sie regelmäßig und schicken Sie sie durch einen Bulk-Verifizierungslauf. Einfacher, günstiger pro Adresse und besser geeignet, wenn Sie vor einem Versand einfach nur eine saubere Liste brauchen statt einer sofortigen Entscheidung.

Die meisten Teams machen am Ende beides: einen Live-Workflow bei der Erfassung plus eine regelmäßige Listenbereinigung, um Adressen abzufangen, die seit der Anmeldung veraltet sind. Falls die Verifizierungs-Pipeline selbst neu für Sie ist, erklärt wie E-Mail-Verifizierung funktioniert, was die API hinter dieser einen Anfrage tatsächlich tut.

Schritt 1: die Trigger-Node#

Starten Sie den Workflow mit dem, was auch immer die Adresse erfasst. n8n bietet Ihnen viele Optionen, und sie alle speisen dieselben nachgelagerten Nodes:

• Eine Webhook-Node, wenn ein Formular oder eine App Einsendungen per POST an eine von Ihnen kontrollierte URL schickt.
• Eine n8n Form Trigger-Node, wenn n8n selbst das Erfassungsformular hosten soll.
• Ein App-Trigger – eine Typeform-, Google-Sheets-, Airtable- oder HubSpot-Node –, der bei einer neuen Einsendung oder Zeile auslöst.
• Eine Schedule Trigger-Node, die einen Datenbank- oder Tabellen-Lesevorgang speist, falls Sie Datensätze lieber zeitgesteuert in kleinen Stapeln durchgehen möchten.

Wenn Ihr Trigger ein bestimmtes Formular-Tool ist, übergibt die Plattform-Anleitung zum Verifizieren von E-Mails aus Typeform an dieselben HTTP-Request- und IF/Switch-Schritte weiter unten – nur die Trigger-Node ändert sich.

Was auch immer Sie wählen: Das Einzige, worauf es ankommt, ist, dass die E-Mail-Adresse im JSON des Items landet, damit spätere Nodes sie referenzieren können – üblicherweise als {{ $json.email }} (passen Sie den Schlüssel an die Ausgabe Ihres Triggers an; eine Webhook-Payload könnte sie als {{ $json.body.email }} bereitstellen, eine Formular-Node unter dem von Ihnen festgelegten Feld-Label). Verwenden Sie n8ns Schaltfläche Execute step am Trigger, um den genauen Pfad zu sehen, bevor Sie die nächste Node bauen.

Schritt 2: die Qualisend-API mit der HTTP-Request-Node aufrufen#

Fügen Sie nach dem Trigger eine HTTP-Request-Node hinzu. Das ist die Node, die Qualisend tatsächlich aufruft. Konfigurieren Sie sie so:

Setzen Sie den JSON-Body über eine Expression, damit die Adresse des Triggers direkt durchfließt:

{ "email": "{{ $json.email }}" }

Die Anfrage, die n8n in Ihrem Namen absetzt, sieht dann 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" }

Legen Sie den Schlüssel als auf reines Verifizieren beschränkten Credential an statt als Schlüssel mit vollem Zugriff, sodass er, falls das Workflow-JSON oder ein Protokoll jemals die Referenz leakt, auf einen Schlüssel verweist, der nur verifizieren kann, sonst nichts. In n8n gehört dieser Schlüssel in einen Header-Auth-Credential – n8n speichert Zugangsdaten getrennt vom Workflow und verschlüsselt sie im Ruhezustand (auf selbst gehosteten Instanzen unter Ihrem N8N_ENCRYPTION_KEY), sodass das Geheimnis niemals in den Node-Parametern, exportierten Workflows oder Ausführungsprotokollen auftaucht.

Wenn Sie die Node mit Execute step ausführen, zeigt n8n den Response-Body an. Unter result erhalten Sie einen status, einen reason-Code, einen score von 0–100 und eine Reihe von sub_flags. Eine zustellbare Adresse kommt in etwa so zurück:

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

Diese Feldnamen sind das, worauf die nächste Node verzweigt; beachten Sie also, dass der Status unter {{ $json.result.status }} liegt und ein Unterkennzeichen unter {{ $json.result.sub_flags.disposable }}. Dasselbe serverseitige Anfragemuster liegt dem Serverless-Anmeldeleitfaden zugrunde – n8n hostet den Aufruf lediglich für Sie, statt einer Funktion, die Sie selbst bereitstellen.

Schritt 3: das Ergebnis mit IF oder Switch verzweigen#

Ein Verifizierungsergebnis, auf das Sie nicht reagieren, ist verschwendetes Guthaben. Der ganze Sinn besteht darin, Adressen unterschiedlich weiterzuleiten, und n8n bietet Ihnen dafür zwei Nodes.

Variante A – eine IF-Node (am einfachsten). Wenn Sie nur „nur gute Adressen behalten“ wollen, fügen Sie nach der HTTP-Request-Node eine IF-Node hinzu. Setzen Sie eine Bedingung:

• Value 1: {{ $json.result.status }} – String – is equal to – Value 2: deliverable

Alles, was passt, verlässt den true-Ausgang in Ihre nachgelagerten Nodes (zum ESP hinzufügen, den Kontakt anlegen, die Willkommens-E-Mail senden); alles andere verlässt den false-Ausgang, wo Sie es verwerfen oder parken können. Einfach, aber grob – es wirft risky, unknown und undeliverable in einen Topf, obwohl Sie sie oft unterschiedlich behandeln möchten.

Variante B – eine Switch-Node (jedes Ergebnis einzeln leiten). Eine Switch-Node im Rules-Modus lässt Sie pro Status in einen eigenen Zweig verzweigen, jeder mit seinen eigenen Folge-Nodes:

Sie können auch auf die Unterkennzeichen verzweigen. Wenn Ihr Produkt reputationssensibel ist, fügen Sie eine Regel hinzu, die jede Adresse, bei der {{ $json.result.sub_flags.disposable }} gleich true ist, in den Prüfzweig leitet, selbst wenn der Status ansonsten in Ordnung ist – derselbe Aufruf bei Wegwerf-, Rollen- und Freemail-Adressen, den die Aufschlüsselung von Rollen-, Wegwerf- und Freemail-Adressen durchgeht. Switch-Regeln werden von oben nach unten ausgewertet, setzen Sie also Ihren striktesten Zweig an die erste Stelle und verdrahten Sie einen Fallback-Ausgang für alles, was nicht zutrifft.

Lassen Sie den API-Aufruf keinen guten Lead verwerfen#

Eine Regel zählt mehr als jeder Zweig: fail open – im Zweifel durchlassen. Wenn die HTTP-Request-Node fehlschlägt – die API ist kurz langsam, ein Plan-Limit ist erreicht, ein Netzwerk-Aussetzer –, wollen Sie nicht, dass die ganze Ausführung stoppt und stillschweigend eine echte Anmeldung verschluckt. Öffnen Sie den Settings-Tab der HTTP-Request-Node und setzen Sie On Error auf Continue (using error output), und behandeln Sie dann eine Adresse ohne Ergebnis als unknown: behalten, in die Prüfung leiten und später erneut prüfen, statt sie zu verwerfen.

Eine Verifizierungs-API ist ein Qualitätsfilter, kein Authentifizierungs-Torwächter. Einen zahlenden Kunden wegen eines vorübergehenden Ausfalls zu blockieren, ist ein weitaus schlechteres Ergebnis, als eine fragwürdige Adresse durchzulassen und sie bei Ihrer nächsten Listenbereinigung abzufangen. Weil Sie möglicherweise selbst hosten, lohnt es sich außerdem, der Node einen vernünftigen Timeout (ein paar Sekunden) und ein bis zwei Retries zu geben, damit eine einzelne langsame Prüfung keine ausgelastete Workflow-Warteschlange blockiert.

Die Bulk-Alternative: einen CSV-Export verifizieren#

n8n ist Klebstoff, und Klebstoff hat einen Preis: Jede verifizierte Adresse ist eine Ausführung, und ein HTTP-Aufruf pro Datensatz kann sich wie Overkill anfühlen – oder sich summieren –, wenn Sie keine sofortige Entscheidung brauchen. Greifen Sie stattdessen zum Batch-Weg, wenn:

• Sie eine Liste bereinigen, die bereits existiert – Tausende historischer Kontakte, nicht neue Erfassung. Exportieren Sie sie und führen Sie einen einzigen Bulk-Lauf aus.
• Ihr Volumen hoch genug ist, dass der Overhead pro Ausführung schmerzt, und eine nächtliche oder wöchentliche Bereinigung aktuell genug ist.
• Sie lieber keinen Live-Workflow für eine einmalige Bereinigung laufen lassen möchten.

Für alle drei Fälle überspringen Sie den Workflow: Exportieren Sie die Datensätze aus Ihrer Datenbank, Tabelle oder Ihrem CRM als CSV und laden Sie diese Datei in Qualisends Bulk-Verifizierer hoch. Sie erhalten denselben status, score und dieselben Unterkennzeichen pro Zeile, herunterladbar als bereinigte Datei, die Sie wieder importieren können. Es ist die aufwandsärmste Methode, eine Liste gesund und Ihre Bounce-Rate niedrig zu halten, ohne irgendeine Automatisierung zu pflegen – und Sie können diesen Export-und-Verify sogar als eigenen zeitgesteuerten n8n-Workflow laufen lassen.

Wenn Sie n8ns HTTP-Node gegen den direkten Aufruf der API aus Ihrem eigenen Backend abwägen, legt der API-Vergleich die Abwägungen dar – n8n gewinnt bei der Geschwindigkeit der Einrichtung und beim visuellen Routing, eine direkte Integration gewinnt bei Kosten und Kontrolle in großem Maßstab. Wenn Sie lieber nicht selbst hosten möchten, funktioniert dasselbe Drei-Schritt-Muster in Zapier.

Häufig gestellte Fragen#

Gibt es eine native Qualisend-Node für n8n?#

Derzeit nicht. Die nativen Plattform-Integrationen von Qualisend werden gerade neu aufgebaut, deshalb gibt es in n8n noch keine eigene Node, nach der Sie suchen könnten – sie steht auf der Roadmap. Bis sie verfügbar ist, ist die unterstützte Methode, E-Mails mit n8n zu verifizieren, die generische HTTP-Request-Node, die auf die Qualisend-API zeigt, genau so, wie es dieser Leitfaden beschreibt. Der Ansatz über die HTTP-Node ist zudem flexibler: Sie steuern die Anfrage, den gespeicherten Zugangsdatensatz, den Timeout und die Verzweigungslogik selbst.

Wo speichert n8n meinen Qualisend-API-Schlüssel?#

Im Credential-Speicher von n8n, nicht im Workflow. Legen Sie einen Header-Auth-Credential an, der Authorization: Bearer YOUR_API_KEY enthält, und referenzieren Sie ihn aus der HTTP-Request-Node. n8n hält Zugangsdaten getrennt von den Workflow-Definitionen und verschlüsselt sie im Ruhezustand – auf einer selbst gehosteten Instanz unter Ihrem N8N_ENCRYPTION_KEY –, sodass das Geheimnis niemals in den Node-Parametern, im exportierten Workflow-JSON oder in den Ausführungsprotokollen auftaucht. Verwenden Sie einen auf reines Verifizieren beschränkten Schlüssel, damit eine geleakte Referenz nichts anderes tun kann als verifizieren.

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

Für ein striktes Tor 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 Hauptflow – viele risky-Ergebnisse sind Catch-all-Domains, die durchaus noch zustellen können. Lehnen Sie undeliverable immer ab und erwägen Sie, zusätzlich auf das disposable-Unterkennzeichen zu verzweigen, wenn Ihr Produkt reputationssensibel ist.

Wie teste ich den Workflow, bevor ich ihn aktiviere?#

Nutzen Sie n8ns Execute step an der HTTP-Request-Node mit einer bekannt gültigen und einer bekannt ungültigen Adresse und prüfen Sie, dass sich {{ $json.result.status }} wie erwartet ändert – kontrollieren Sie anschließend, dass Ihre IF- oder Switch-Node jede Adresse in den richtigen Zweig leitet. Für schnelle, einzelne Stichproben außerhalb von n8n fügen Sie eine Adresse in den kostenlosen E-Mail-Checker ein und vergleichen das Ergebnis mit dem, was Ihr Workflow zurückgibt.

Bereit, es zu bauen? Holen Sie sich einen beschränkten Schlüssel und die genaue Anfrageform aus den Entwicklerdokumenten, prüfen Sie eine beliebige Adresse im kostenlosen E-Mail-Checker und legen Sie mit dem kostenlosen Plan los – 100 Credits reichen, um den gesamten Workflow zu verdrahten und zuzusehen, wie eine schlechte Adresse gefiltert wird, bevor sie je Ihre Liste erreicht.