# Verifica Email Clienti — Guida completa > Verifica Email Clienti controlla la reale recapitabilità di ogni indirizzo email del tuo negozio: sintassi, esistenza del dominio tramite i suoi record MX e, in opzione, una sonda SMTP che… - Pagina: - Lingua: it - Aggiornato il: 2026-08-28 - Altre lingue: [fr](https://www.datafirefly.com/documentation/dfemailcheck/index.md), [en](https://www.datafirefly.com/en/documentation/dfemailcheck/index.md), [es](https://www.datafirefly.com/es/documentation/dfemailcheck/index.md), [de](https://www.datafirefly.com/de/documentation/dfemailcheck/index.md), [pl](https://www.datafirefly.com/pl/documentation/dfemailcheck/index.md), [pt](https://www.datafirefly.com/pt/documentation/dfemailcheck/index.md), [nl](https://www.datafirefly.com/nl/documentation/dfemailcheck/index.md) - Indice: Verifica Email Clienti controlla la reale recapitabilità di ogni indirizzo email del tuo negozio: sintassi, esistenza del dominio tramite i suoi record MX e, in opzione, una sonda SMTP che interroga il server del destinatario. Lo stato di ogni cliente (Valido, Non valido, A rischio, Non verificato) viene mostrato in una scheda dedicata del back office, dove puoi verificare l'intero database a lotti ed eliminare con un clic tutti i clienti il cui email non esiste — senza mai cancellare per errore un cliente reale. Questa guida copre l'installazione, la configurazione, i livelli di verifica e la pulizia del database. ## Installazione 1. Scarica l'archivio `dfemailcheck.zip` dal tuo account DataFirefly. 2. Back office PrestaShop → **Moduli** → **Carica un modulo** → invia lo ZIP. 3. All'installazione, il modulo crea la sua tabella `df_email_check`, registra i suoi hook e aggiunge la scheda **Clienti → Verifica email**. Compatibile con PrestaShop 8.0 a 9.x, su PHP 7.4 a 8.3. Nessun override del tema, nessuna dipendenza Composer. Compatibile con multinegozio e traducibile. ## Configurazione Vai in **Moduli → Verifica Email Clienti → Configura**. ### Verifica alla registrazione Quando l'opzione **Verifica alla creazione dell'account** è attiva, ogni nuovo cliente viene controllato automaticamente alla creazione (hook `actionObjectCustomerAddAfter`). In quel momento viene eseguita solo la verifica rapida — sintassi e dominio — per non rallentare il processo d'acquisto. Lo stato viene inoltre ricalcolato quando un cliente cambia il proprio indirizzo email. ### Blocco della registrazione L'opzione **Blocca la registrazione se il dominio non è valido** rifiuta il modulo di registrazione quando il dominio dell'email non ha alcun record MX né A (hook `additionalCustomerFormFields` e `validateCustomerFormFields`). Il cliente vede allora un messaggio di errore sul campo email. Disattivata per impostazione predefinita. ### Verifica SMTP (avanzata) La sonda SMTP conferma l'esistenza reale della casella dialogando con il server del destinatario (comando `RCPT TO`), con rilevamento dei server catch-all. La accompagnano tre impostazioni: - **Verifica SMTP**: attiva o disattiva la sonda. Disattivata per impostazione predefinita. - **Indirizzo mittente SMTP**: indirizzo annunciato durante il dialogo (`MAIL FROM`). - **Timeout SMTP**: tempo massimo di attesa per server, in secondi (6 per impostazione predefinita). La verifica SMTP richiede la **porta 25 in uscita**, molto spesso chiusa sull'hosting condiviso. Senza di essa, la verifica si ferma al dominio — il che rileva già la grande maggioranza degli indirizzi falsi. ### Sicurezza dell'eliminazione - **Proteggi i clienti con ordini**: impedisce l'eliminazione di qualsiasi cliente con almeno un ordine, per evitare ordini orfani. Attivata per impostazione predefinita. - **Dimensione del lotto**: numero di clienti elaborati per passaggio durante le verifiche massive (50 per impostazione predefinita). ## I livelli di verifica Il controllo avviene su tre livelli, dal più rapido al più preciso: - **Sintassi**: validazione del formato dell'indirizzo. - **Dominio**: ricerca dei record MX del dominio, con ripiego sui record A/AAAA. - **SMTP (opzionale)**: dialogo con il server del destinatario per confermare la casella, con rilevamento dei server catch-all. ## Gli stati Ogni cliente riceve uno dei quattro stati seguenti: - **Valido**: sintassi corretta e dominio raggiungibile (e casella confermata se la sonda SMTP è attiva). - **Non valido**: segnale negativo certo — sintassi errata (`bad_syntax`), dominio senza MX né A (`no_mx`) o rifiuto SMTP esplicito (`smtp_rejected`). Sono gli unici clienti eliminabili. - **A rischio**: server catch-all (`smtp_catch_all`) — l'indirizzo viene accettato ma il server accetta anche indirizzi inesistenti. Mai eliminato automaticamente. - **Non verificato**: risultato indeterminato — timeout, porta chiusa, greylisting o cliente mai controllato. Mai eliminato. Il codice di dettaglio (per esempio `no_mx`, `smtp_catch_all`) è mostrato accanto allo stato nell'elenco, per spiegare ogni decisione. ## La dashboard La scheda **Clienti → Verifica email** mostra in alto cinque contatori: numero totale di clienti, validi, non validi, a rischio e non verificati. Sotto, l'elenco completo dei clienti è filtrabile per stato. Due pulsanti avviano la verifica: - **Verifica i nuovi clienti**: controlla solo i clienti mai verificati. - **Ri-verifica tutto**: ricontrolla l'intero database. L'elaborazione avviene a lotti via AJAX, con una barra di avanzamento, il che permette di trattare grandi database senza superare il tempo limite. La sonda SMTP, se attiva, viene usata solo durante queste verifiche massive. ## Eliminare i clienti non validi Il pulsante **Elimina i clienti non validi** cancella in una sola volta tutti i clienti con stato _Non valido_. I clienti che hanno effettuato almeno un ordine vengono ignorati finché l'opzione di protezione è attiva. Puoi anche agire su una selezione precisa tramite le **azioni di gruppo** dell'elenco: _Ri-verifica la selezione_ o _Elimina la selezione_. L'eliminazione usa il meccanismo nativo di PrestaShop (`Customer::delete()`) e pulisce anche la tabella dei risultati. L'eliminazione di un cliente è definitiva. Controlla il contatore «Non validi» e, se necessario, filtra l'elenco su questo stato per verificare gli indirizzi prima della pulizia. ## Sicurezza — zero falsi positivi La regola centrale del modulo: un indirizzo non viene mai contrassegnato come _Non valido_ per un semplice dubbio. Un timeout, un greylisting, una porta SMTP chiusa o una risposta temporanea (4xx) lasciano lo stato su _Non verificato_, mai eliminato. Solo i segnali negativi certi (sintassi, assenza di MX/A, rifiuto 5xx) rendono un cliente eliminabile. Combinata con la protezione dei clienti con ordini, questa logica evita di cancellare per errore un cliente reale. ## Compatibilità e note tecniche - PrestaShop 8.0 a 9.x, multinegozio. Interfaccia disponibile in FR, EN, ES, IT, DE e PL. - Controller di amministrazione legacy (nessun controller Symfony) per la compatibilità PS8/PS9. - Hook: `actionObjectCustomerAddAfter`, `actionObjectCustomerUpdateAfter`, `actionObjectCustomerDeleteAfter`, `additionalCustomerFormFields`, `validateCustomerFormFields`. - Endpoint AJAX di back office tramite il 4° argomento di `getAdminLink()`; output JSON tramite un metodo dedicato. - Tabella `df_email_check`: un record per cliente (email, stato, codice di dettaglio, data di controllo). - Nessuna chiamata a un servizio di terze parti: la verifica si basa solo sul DNS e, in opzione, su una connessione SMTP diretta. ## FAQ e risoluzione dei problemi **La verifica SMTP restituisce sempre «Non verificato».** La porta 25 in uscita è probabilmente chiusa dal tuo hosting. Disattiva la sonda SMTP: la verifica del dominio (MX) è sufficiente nella maggior parte dei casi. **Clienti legittimi appaiono «A rischio».** Il loro server di posta è catch-all (accetta ogni indirizzo). È un comportamento del server, non un errore; questi clienti non vengono mai eliminati automaticamente. **La pulizia non elimina alcun cliente anche se il contatore Non validi è positivo.** Controlla l'opzione «Proteggi i clienti con ordini»: i clienti non validi che hanno un ordine vengono volutamente ignorati. **Il blocco alla registrazione non si attiva.** Alcuni moduli di accesso rapido o popup creano il cliente senza passare dal modulo standard di PrestaShop; in tal caso la verifica viene comunque eseguita subito dopo la creazione dell'account, e il cliente appare allora come «Non valido» nell'elenco. **La verifica rallenta la registrazione?** No. Alla registrazione viene eseguita solo la verifica rapida (sintassi e dominio). La sonda SMTP viene eseguita solo durante le verifiche massive dal back office.