# Verificación de Emails de Clientes — Guía completa > 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… - Página: - Idioma: es - Actualizado el: 2026-08-28 - Otros idiomas: [fr](https://www.datafirefly.com/documentation/dfemailcheck/index.md), [en](https://www.datafirefly.com/en/documentation/dfemailcheck/index.md), [de](https://www.datafirefly.com/de/documentation/dfemailcheck/index.md), [it](https://www.datafirefly.com/it/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) - Índice: 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 1. Descarga el archivo `dfemailcheck.zip` desde tu cuenta DataFirefly. 2. Back office de PrestaShop → **Módulos** → **Subir un módulo** → envía el ZIP. 3. 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 (hooks `additionalCustomerFormFields` y `validateCustomerFormFields`). 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 disponible en FR, EN, ES, IT, DE y PL. - Controlador de administración legacy (sin controlador Symfony) para la compatibilidad PS8/PS9. - Hooks: `actionObjectCustomerAddAfter`, `actionObjectCustomerUpdateAfter`, `actionObjectCustomerDeleteAfter`, `additionalCustomerFormFields`, `validateCustomerFormFields`. - 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.** Algunos módulos de conexión rápida o de popup crean el cliente sin pasar por el formulario estándar de PrestaShop; en ese caso, 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.