Come verificare le email con n8n

Puoi verificare le email con n8n già oggi senza aspettare un nodo dedicato: il nodo generico HTTP Request di n8n chiama l'API di Qualisend senza problemi e, poiché n8n è open source e installabile sui tuoi server, l'intero flusso gira su un'infrastruttura che controlli tu, con la chiave API salvata nell'archivio credenziali di n8n. La struttura si basa sempre sugli stessi tre nodi: un trigger acquisisce l'indirizzo, un nodo HTTP Request lo invia a Qualisend con una POST e un nodo IF o Switch legge lo status restituito e instrada ogni risultato. Finché il controllo della casella è ancora pending, un breve loop Wait e GET tra gli ultimi due recupera l'esito finale. Questa guida costruisce quel workflow dall'inizio alla fine.

In breve#

In n8n non esiste ancora un nodo nativo di Qualisend (è nella roadmap), quindi lo schema supportato è un workflow con nodi generici: un trigger (webhook, modulo, nuova riga, pianificazione), un nodo HTTP Request che invia l'email con una POST all'API di verifica con la tua chiave in una credenziale salvata, e un nodo IF o Switch che dirama il flusso in base a result.status. Quando la prima risposta indica che result.smtp è pending, il controllo della casella è ancora in corso, quindi un breve loop Wait e GET recupera l'esito finale prima della diramazione. Tieni la chiave in una credenziale n8n, mai incollata direttamente nel nodo o in un campo pubblico, e lascia passare l'indirizzo per impostazione predefinita se la chiamata HTTP va in errore, così un problema temporaneo non scarta mai in silenzio un'iscrizione vera.

Due modi per verificare le email con n8n#

Prima di collegare qualsiasi cosa, scegli lo schema in base a quanto devono essere aggiornati i dati:

1. In tempo reale, per singolo record (un workflow attivo). Ogni nuovo indirizzo viene verificato nel momento in cui arriva e instradato all'istante. È l'argomento principale di questa guida e la scelta giusta quando l'esito cambia ciò che succede dopo: bloccare un'email di benvenuto, aggiungere un tag a un lead o saltare un'iscrizione falsa.
2. In blocco, in un secondo momento (un CSV). Lascia che i record si accumulino in un foglio, un database o un CRM, esportali periodicamente e passali a un job di verifica in blocco. È più semplice, costa meno per indirizzo ed è più adatto quando ti serve solo una lista pulita prima di un invio, non una decisione istantanea.

La maggior parte dei team finisce per fare entrambe le cose: un workflow attivo sui nuovi ingressi, più una pulizia della lista periodica per intercettare gli indirizzi diventati obsoleti da quando si sono iscritti. Se la pipeline di verifica è una novità per te, come funziona la verifica email spiega cosa fa davvero l'API dietro quella singola richiesta.

Passaggio 1: il nodo trigger#

Avvia il workflow con ciò che acquisisce l'indirizzo. n8n offre molte opzioni, e alimentano tutte gli stessi nodi a valle:

• Un nodo Webhook, se un modulo o un'app invia i dati con una POST a un URL che controlli.
• Un nodo n8n Form Trigger, se vuoi che sia n8n stesso a ospitare il modulo di raccolta.
• Un trigger di app (un nodo Typeform, Google Sheets, Airtable o HubSpot) che si attiva a ogni nuovo invio o nuova riga.
• Un nodo Schedule Trigger che alimenta la lettura di un database o di un foglio di calcolo, se preferisci passare in rassegna i record in piccoli lotti a intervalli regolari.

Se il tuo trigger è uno specifico strumento per moduli, la guida dedicata a verificare le email da Typeform si ricollega agli stessi passaggi HTTP Request e IF/Switch qui sotto: cambia solo il nodo trigger.

Qualunque cosa tu scelga, l'unica cosa che conta è che l'indirizzo email arrivi nel JSON dell'elemento, così i nodi successivi possono farvi riferimento: di solito come {{ $json.email }} (adatta la chiave all'output del tuo trigger; un payload Webhook potrebbe esporlo come {{ $json.body.email }}, un nodo modulo sotto l'etichetta di campo che hai impostato). Usa il pulsante Execute step di n8n sul trigger per vedere il percorso esatto prima di creare il nodo successivo.

Passaggio 2: chiama l'API di Qualisend con il nodo HTTP Request#

Aggiungi un nodo HTTP Request dopo il trigger. È il nodo che chiama davvero Qualisend. Configuralo così:

Imposta il corpo JSON con un'espressione, così l'indirizzo del trigger passa direttamente:

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

La richiesta che n8n invia per tuo conto ha questo aspetto (i segnaposto li compili tu con i dati della documentazione per sviluppatori, che riporta l'endpoint esatto e mostra la richiesta in diversi linguaggi):

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

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

Crea la chiave come credenziale con ambiti definiti, di sola verifica invece che come chiave con accesso completo, così se il JSON del workflow o un log dovessero far trapelare il riferimento, questo punterebbe a una chiave che può solo verificare. In n8n, quella chiave va in una credenziale Header Auth: n8n conserva le credenziali separate dal workflow e le cifra a riposo (sulle istanze installate sui tuoi server, con la tua N8N_ENCRYPTION_KEY), quindi il segreto non compare mai nei parametri del nodo, nei workflow esportati o nei log di esecuzione.

Quando esegui il nodo con Execute step, n8n mostra il corpo della risposta. Sotto result trovi uno status, un codice motivo reason, uno score da 0 a 100, una serie di sub_flags e un campo smtp che indica se il controllo della casella è terminato. Per un nuovo indirizzo su un dominio funzionante, di solito la risposta è questa:

{
  "job_id": "3f2b6c1e-8a4d-4f7e-9c21-5b0d7e9a1c44",
  "result": {
    "status": "unknown",
    "reason": null,
    "score": 60,
    "smtp": "pending",
    "sub_flags": { "disposable": false, "role": false, "free_mail": false, "catch_all": false }
  }
}

Quell'unknown non è ancora un esito. La risposta arriva non appena terminano i rapidi controlli locali (sintassi, dominio e MX, usa e getta, indirizzo generico, errore di battitura), mentre il controllo SMTP della casella è ancora in corso; il passaggio 3 recupera l'esito finale. Quando smtp è invece cached o skipped, result è già definitivo.

Il nodo successivo dirama il flusso in base a questi nomi di campo, quindi tieni presente che lo status si trova in {{ $json.result.status }} e un indicatore aggiuntivo in {{ $json.result.sub_flags.disposable }}. Lo stesso schema di richiesta lato server è alla base della guida alle iscrizioni serverless: n8n ospita semplicemente la chiamata al posto di una funzione che distribuisci tu.

Passaggio 3: recupera l'esito finale quando il controllo della casella è pending#

Diramare il flusso in base a una risposta pending manderebbe la maggior parte delle iscrizioni vere sul percorso unknown. Aggiungi invece, tra il nodo HTTP Request e il tuo router, un breve loop di polling che legga il job creato dalla prima chiamata:

1. Un nodo IF: {{ $json.result.smtp }} is equal to pending. L'output false (cached o skipped) è già definitivo e va direttamente al passaggio 4.
2. Sull'output true, un nodo Wait impostato su 5-10 secondi.
3. Un secondo nodo HTTP Request con metodo GET, la stessa credenziale Header Auth e questo URL (sostituisci Verify email con il nome che hai dato al primo nodo HTTP Request): https://app.qualisend.com/api/v1/jobs/{{ $('Verify email').item.json.job_id }}?include=results
4. Un nodo IF che controlla se il job è terminato: {{ $json.status }} is equal to completed, failed o canceled (tre condizioni combinate con OR). Ricollega il suo output false al nodo Wait.
5. Sull'output true, un nodo Edit Fields (Set) che imposta un campo chiamato result (tipo Object) su {{ $json.results[0] }}, così entrambi i percorsi passano al passaggio 4 gli stessi result.status e result.sub_flags.

Ogni controllo è una normale chiamata API: non consuma crediti, ma rientra nel limite di frequenza al minuto del tuo workspace, quindi un'attesa di 5-10 secondi è più che sufficiente. Non chiamare di nuovo l'endpoint di verifica per "aggiornare" un indirizzo: consumeresti un secondo credito. Un job che termina come failed o canceled non ha alcun esito, quindi trattalo come unknown. E fai in modo che il trigger risponda appena arriva un invio (l'impostazione predefinita Respond: Immediately di un nodo Webhook), così chi si iscrive non aspetta mai questo loop.

Passaggio 4: dirama il flusso in base all'esito con IF o Switch#

Un risultato di verifica su cui non agisci è un credito sprecato. Il punto è proprio instradare gli indirizzi in modo diverso, e n8n ti offre due nodi per farlo.

Opzione A: un nodo IF (la più semplice). Se vuoi solo "tenere gli indirizzi buoni", aggiungi un nodo IF nel punto in cui si incontrano i due percorsi del passaggio 3. Imposta una condizione:

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

Tutto ciò che corrisponde esce dall'output true verso i nodi a valle (aggiunta all'ESP, creazione del contatto, invio dell'email di benvenuto); tutto il resto esce dall'output false, dove puoi scartarlo o parcheggiarlo. Semplice ma grossolano: mette insieme risky, unknown e undeliverable, mentre spesso conviene trattarli in modo diverso.

Opzione B: un nodo Switch (un percorso per ogni risultato). Un nodo Switch in modalità Rules ti permette di creare un ramo separato per ogni status, ciascuno con i propri nodi successivi:

Puoi creare diramazioni anche sugli indicatori aggiuntivi. Se il tuo prodotto è sensibile alla reputazione, aggiungi una regola che invia al ramo di revisione ogni indirizzo in cui {{ $json.result.sub_flags.disposable }} è true, anche quando lo status di per sé va bene: è la stessa scelta su indirizzi usa e getta, generici e gratuiti illustrata nell'analisi degli indirizzi generici, usa e getta e gratuiti. Le regole Switch vengono valutate dall'alto verso il basso, quindi metti per primo il ramo più severo e collega un output fallback per tutto ciò che non corrisponde.

Non lasciare che la chiamata API faccia perdere un buon lead#

Una regola conta più di qualsiasi ramo: fail open. Se il nodo HTTP Request va in errore (l'API è momentaneamente lenta, si raggiunge un limite del piano, un problema di rete), non vuoi che l'intera esecuzione si fermi e perda in silenzio un'iscrizione vera. Apri la scheda Settings del nodo HTTP Request e imposta On Error su Continue (using error output), poi tratta un indirizzo senza esito come unknown: tienilo, mandalo in revisione e ricontrollalo più tardi invece di scartarlo. Applica la stessa impostazione al nodo GET del passaggio 3.

Un'API di verifica è un filtro di qualità, non un controllo di autenticazione. Bloccare un cliente pagante per un'interruzione temporanea è molto peggio che lasciar passare un indirizzo dubbio e intercettarlo alla prossima pulizia della lista. Dato che potresti ospitare n8n sui tuoi server, vale anche la pena impostare sul nodo un timeout ragionevole (qualche secondo) e uno o due retry, così un singolo test lento non blocca una coda di workflow molto attiva.

L'alternativa in blocco: verificare un'esportazione CSV#

n8n è un collante, e il collante ha un costo: ogni indirizzo verificato è un'esecuzione, e una chiamata HTTP per record può sembrare eccessiva, o pesare sul conto, quando non ti serve una decisione istantanea. Passa piuttosto al percorso in batch quando:

• Stai pulendo una lista che esiste già: migliaia di contatti storici, non nuove acquisizioni. Esportali e lancia un unico job in blocco.
• Il tuo volume è abbastanza alto da rendere pesante il costo per esecuzione, e una pulizia notturna o settimanale basta a tenere i dati aggiornati.
• Preferisci non tenere attivo un workflow per una pulizia una tantum.

In tutti e tre i casi, salta il workflow: esporta i record in CSV dal database, dal foglio o dal CRM e carica quel file nello strumento di verifica in blocco di Qualisend. Ottieni gli stessi status, score e indicatori aggiuntivi per ogni riga, scaricabili come file pulito da reimportare. È il modo meno impegnativo per mantenere sana una lista e basso il tuo tasso di bounce senza gestire alcuna automazione, e puoi persino eseguire quell'esportazione con verifica come workflow n8n pianificato a sé stante.

Se stai confrontando il nodo HTTP di n8n con la chiamata diretta all'API dal tuo backend, il confronto tra API illustra i pro e i contro: n8n vince per rapidità di configurazione e instradamento visuale, un'integrazione diretta vince per costi e controllo su larga scala. Se preferisci non ospitare n8n sui tuoi server, lo stesso schema in tre passaggi funziona in Zapier.

Pronto a costruirlo? Prendi una chiave con ambiti definiti e la struttura esatta della richiesta dalla documentazione per sviluppatori, controlla qualsiasi indirizzo con la verifica email gratuita e parti dal piano Free: 100 crediti bastano per collegare l'intero workflow e veder filtrare un indirizzo sbagliato prima che raggiunga la tua lista.