Verificación de Emails de Clientes — Guía completa
Instalar, configurar y aprovechar la verificación de entregabilidad de los emails y la limpieza de la base de clientes para PrestaShop 8 y 9.
Verificación de Emails de Clientes comprueba la entregabilidad real de cada dirección de email de tu tienda: sintaxis, existencia del dominio a través de sus registros MX y, de forma opcional, una sonda SMTP que interroga el servidor del destinatario. El estado de cada cliente (Válido, Inválido, En riesgo, No verificado) se muestra en una pestaña dedicada del back office, donde puedes verificar toda la base por lotes y eliminar con un clic todos los clientes cuyo email no existe — sin borrar nunca a un cliente real por error. Esta guía cubre la instalación, la configuración, los niveles de verificación y la limpieza de la base.
Instalación
- Descarga el archivo
dfemailcheck.zipdesde tu cuenta DataFirefly. - Back office de PrestaShop → Módulos → Subir un módulo → envía el ZIP.
- Al instalarse, el módulo crea su tabla
df_email_check, registra sus hooks y añade la pestaña Clientes → Verificación de emails.
Compatible con PrestaShop 8.0 a 9.x, en PHP 7.4 a 8.3. Sin override de tema, sin dependencia de Composer. Compatible con multitienda y traducible.
Configuración
Ve a Módulos → Verificación de Emails de Clientes → Configurar.
Verificación en el registro
Cuando la opción Verificar al crear la cuenta está activa, cada nuevo cliente se comprueba automáticamente al crearse (hook actionObjectCustomerAddAfter). En ese momento solo se ejecuta la verificación rápida — sintaxis y dominio — para no ralentizar el proceso de compra. El estado también se recalcula cuando un cliente cambia su dirección de email.
Bloqueo del registro
La opción Bloquear el registro si el dominio es inválido rechaza el formulario de registro cuando el dominio del email no tiene ningún registro MX ni A (hook actionValidateCustomerFormFields). El cliente ve entonces un mensaje de error en el campo email. Desactivada de forma predeterminada.
Verificación SMTP (avanzado)
La sonda SMTP confirma la existencia real del buzón dialogando con el servidor del destinatario (comando RCPT TO), con detección de servidores catch-all. La acompañan tres ajustes:
- Verificación SMTP: activa o desactiva la sonda. Desactivada de forma predeterminada.
- Dirección de remitente SMTP: dirección anunciada durante el diálogo (
MAIL FROM). - Timeout SMTP: tiempo máximo de espera por servidor, en segundos (6 por defecto).
La verificación SMTP requiere el puerto 25 saliente, muy a menudo cerrado en el alojamiento compartido. Sin ella, la verificación se detiene en el dominio — lo que ya detecta la gran mayoría de las direcciones falsas.
Seguridad de la eliminación
- Proteger los clientes con pedidos: impide la eliminación de cualquier cliente con al menos un pedido, para evitar pedidos huérfanos. Activada de forma predeterminada.
- Tamaño de lote: número de clientes procesados por pasada durante las verificaciones masivas (50 por defecto).
Los niveles de verificación
El control se realiza en tres niveles, del más rápido al más preciso:
- Sintaxis: validación del formato de la dirección.
- Dominio: búsqueda de los registros MX del dominio, con repliegue a los registros A/AAAA.
- SMTP (opcional): diálogo con el servidor del destinatario para confirmar el buzón, con detección de servidores catch-all.
Los estados
Cada cliente recibe uno de los cuatro estados siguientes:
- Válido: sintaxis correcta y dominio accesible (y buzón confirmado si la sonda SMTP está activa).
- Inválido: señal negativa segura — sintaxis incorrecta (
bad_syntax), dominio sin MX ni A (no_mx) o rechazo SMTP explícito (smtp_rejected). Son los únicos clientes eliminables. - En riesgo: servidor catch-all (
smtp_catch_all) — la dirección se acepta pero el servidor también acepta direcciones inexistentes. Nunca se elimina automáticamente. - No verificado: resultado indeterminado — timeout, puerto cerrado, greylisting o cliente nunca comprobado. Nunca se elimina.
El código de detalle (por ejemplo no_mx, smtp_catch_all) se muestra junto al estado en la lista, para explicar cada decisión.
El panel de control
La pestaña Clientes → Verificación de emails muestra arriba cinco contadores: número total de clientes, válidos, inválidos, en riesgo y no verificados. Debajo, la lista completa de clientes se puede filtrar por estado. Dos botones lanzan la verificación:
- Verificar los nuevos clientes: solo comprueba los clientes nunca verificados.
- Volver a verificar todo: vuelve a comprobar toda la base.
El procesamiento se realiza por lotes mediante AJAX, con una barra de progreso, lo que permite tratar grandes bases sin superar el tiempo límite. La sonda SMTP, si está activa, solo se usa durante estas verificaciones masivas.
Eliminar los clientes inválidos
El botón Eliminar los clientes inválidos borra de una sola vez todos los clientes con estado Inválido. Los clientes que han hecho al menos un pedido se omiten mientras la opción de protección esté activa. También puedes actuar sobre una selección concreta mediante las acciones por lotes de la lista: Volver a verificar la selección o Eliminar la selección. La eliminación usa el mecanismo nativo de PrestaShop (Customer::delete()) y también limpia la tabla de resultados.
La eliminación de un cliente es definitiva. Comprueba el contador «Inválidos» y, si es necesario, filtra la lista por ese estado para revisar las direcciones antes de la purga.
Seguridad — cero falsos positivos
La regla central del módulo: una dirección nunca se marca como Inválida ante una simple duda. Un timeout, un greylisting, un puerto SMTP cerrado o una respuesta temporal (4xx) dejan el estado como No verificado, nunca eliminado. Solo las señales negativas seguras (sintaxis, ausencia de MX/A, rechazo 5xx) hacen que un cliente sea eliminable. Combinada con la protección de los clientes con pedidos, esta lógica evita borrar a un cliente real por error.
Compatibilidad y notas técnicas
- PrestaShop 8.0 a 9.x, multitienda, interfaz traducible.
- Controlador de administración legacy (sin controlador Symfony) para la compatibilidad PS8/PS9.
- Hooks:
actionObjectCustomerAddAfter,actionObjectCustomerUpdateAfter,actionObjectCustomerDeleteAfter,actionValidateCustomerFormFields. - Endpoint AJAX de back office a través del 4º argumento de
getAdminLink(); salida JSON mediante un método dedicado. - Tabla
df_email_check: un registro por cliente (email, estado, código de detalle, fecha de comprobación). - Sin llamada a ningún servicio de terceros: la verificación se basa únicamente en el DNS y, de forma opcional, en una conexión SMTP directa.
FAQ y resolución de problemas
La verificación SMTP siempre devuelve «No verificado». El puerto 25 saliente probablemente esté cerrado por tu alojamiento. Desactiva la sonda SMTP: la verificación del dominio (MX) es suficiente en la mayoría de los casos.
Clientes legítimos aparecen «En riesgo». Su servidor de correo es catch-all (acepta todas las direcciones). Es un comportamiento del servidor, no un error; estos clientes nunca se eliminan automáticamente.
La purga no elimina ningún cliente aunque el contador Inválidos sea positivo. Comprueba la opción «Proteger los clientes con pedidos»: los clientes inválidos que tienen un pedido se omiten deliberadamente.
El bloqueo en el registro no se activa. El hook de validación del formulario depende de la versión de PrestaShop; si tu versión no lo activa, la verificación se realiza igualmente justo después de crear la cuenta, y el cliente aparece entonces como «Inválido» en la lista.
¿La verificación ralentiza el registro? No. En el registro solo se ejecuta la verificación rápida (sintaxis y dominio). La sonda SMTP solo se ejecuta durante las verificaciones masivas desde el back office.