Verificação dos e-mails de clientes: guia completo
Instalar, configurar e explorar a verificação da entregabilidade dos e-mails e a limpeza da base de clientes para PrestaShop 8 e 9.
A Verificação dos E-mails de Clientes controla a entregabilidade real de cada endereço de e-mail da sua loja: sintaxe, existência do domínio através dos seus registos MX e, em opção, uma sonda SMTP que interroga o servidor do destinatário. O estado de cada cliente (Válido, Inválido, Em risco, Não verificado) aparece num separador dedicado do back-office, onde pode verificar toda a base por lotes e eliminar com um clique os clientes cujo e-mail não existe, sem nunca apagar um cliente real por engano. Este guia cobre a instalação, a configuração, os níveis de verificação e a limpeza da base.
Instalação
- Descarregue o arquivo
dfemailcheck.zipa partir da sua conta DataFirefly. - Back-office do PrestaShop → Módulos → Carregar um módulo → envie o ZIP.
- Na instalação, o módulo cria a sua tabela
df_email_check, regista os seus hooks e acrescenta o separador Clientes → Verificação de e-mails.
Compatível com PrestaShop 8.0 a 9.x, em PHP 7.4 a 8.3. Sem overrides do tema e sem dependências Composer. Compatível com multiloja e traduzível.
Configuração
Vá a Módulos → Verificação dos E-mails de Clientes → Configurar.
Verificação no registo
Com a opção Verificar na criação da conta ativa, cada novo cliente é controlado automaticamente na criação (hook actionObjectCustomerAddAfter). Nesse momento, só é executada a verificação rápida, de sintaxe e de domínio, para não atrasar o processo de compra. O estado é também recalculado quando um cliente altera o seu endereço de e-mail.
Bloqueio do registo
A opção Bloquear o registo se o domínio for inválido recusa o formulário de registo quando o domínio do e-mail não tem qualquer registo MX nem A (hooks additionalCustomerFormFields e validateCustomerFormFields). O cliente vê então uma mensagem de erro no campo do e-mail. Inativa por predefinição.
A mensagem de erro apresentada ao cliente vem das traduções do módulo, fornecidas em FR, EN, ES, IT, DE e PL, sem português. Antes de ativar o bloqueio numa loja portuguesa, traduza essa cadeia em Internacional > Traduções: é vista por um visitante em pleno registo, num momento em que uma mensagem noutro idioma faz simplesmente perder a conta.
Verificação SMTP (avançada)
A sonda SMTP confirma a existência real da caixa de correio dialogando com o servidor do destinatário (comando RCPT TO), com deteção dos servidores em catch-all. Acompanham-na três definições:
- Verificação SMTP: ativa ou desativa a sonda. Inativa por predefinição.
- Endereço de remetente SMTP: endereço anunciado durante o diálogo (
MAIL FROM). - Tempo limite SMTP: tempo de espera máximo por servidor, em segundos (6 por predefinição).
A verificação SMTP exige o porto 25 de saída, muitas vezes fechado nos alojamentos partilhados. Sem ela, a verificação para no domínio, o que já deteta a grande maioria dos endereços falsos.
Segurança da eliminação
- Proteger os clientes com encomendas: impede a eliminação de qualquer cliente com pelo menos uma encomenda, para evitar encomendas órfãs. Ativa por predefinição.
- Dimensão do lote: número de clientes tratados por passagem nas verificações em massa (50 por predefinição).
Os níveis de verificação
O controlo é feito em três níveis, do mais rápido ao mais preciso:
- Sintaxe: validação do formato do endereço.
- Domínio: procura dos registos MX do domínio, com recurso aos registos A/AAAA.
- SMTP (opcional): diálogo com o servidor do destinatário para confirmar a caixa, com deteção dos servidores catch-all.
Os estados
Cada cliente recebe um dos quatro estados seguintes:
- Válido: sintaxe correta e domínio aceitável (e caixa confirmada, se a sonda SMTP estiver ativa).
- Inválido: sinal negativo certo, ou seja, sintaxe incorreta (
bad_syntax), domínio sem MX nem A (no_mx) ou rejeição SMTP explícita (smtp_rejected). São os únicos clientes elimináveis. - Em risco: servidor em catch-all (
smtp_catch_all), ou seja, o endereço é aceite mas o servidor aceita também endereços inexistentes. Nunca é eliminado automaticamente. - Não verificado: resultado indeterminado, por tempo excedido, porto fechado, greylisting ou cliente nunca controlado. Nunca é eliminado.
O código de detalhe (por exemplo, no_mx ou smtp_catch_all) é apresentado junto do estado na lista, para explicar cada decisão.
O painel
O separador Clientes → Verificação de e-mails mostra no topo cinco contadores: número total de clientes, válidos, inválidos, em risco e não verificados. Por baixo, a lista completa dos clientes pode ser filtrada por estado. Dois botões lançam a verificação:
- Verificar os novos clientes: controla apenas os clientes nunca verificados.
- Verificar tudo de novo: volta a controlar toda a base.
O tratamento é feito por lotes em AJAX, com uma barra de progresso, o que permite tratar bases grandes sem exceder o tempo limite. A sonda SMTP, se estiver ativa, só é usada durante estas verificações em massa.
Eliminar os clientes inválidos
O botão Eliminar os clientes inválidos apaga de uma vez todos os clientes com o estado Inválido. Os clientes que fizeram pelo menos uma encomenda são ignorados enquanto a opção de proteção estiver ativa. Também pode atuar sobre uma seleção concreta, através das ações em massa da lista: Verificar de novo a seleção ou Eliminar a seleção. A eliminação usa o mecanismo nativo do PrestaShop (Customer::delete()) e limpa igualmente a tabela de resultados.
A eliminação de um cliente é definitiva. Verifique o contador de «Inválidos» e, se for preciso, filtre a lista por esse estado para conferir os endereços antes da limpeza.
Do ponto de vista do RGPD, eliminar contas cujo e-mail não existe vai ao encontro do princípio da limitação da conservação: são dados que já não servem qualquer finalidade. Note, porém, que a proteção dos clientes com encomendas é indispensável, porque os documentos de suporte da contabilidade têm de ser conservados 10 anos (artigo 123.º do CIRC e artigo 52.º do CIVA): mantenha-a ativa. Se um cliente com encomendas pedir o apagamento, o caminho é a anonimização, não a eliminação.
Segurança: zero falsos positivos
A regra central do módulo é que um endereço nunca é marcado como Inválido por simples dúvida. Um tempo excedido, um greylisting, um porto SMTP fechado ou uma resposta temporária (4xx) deixam o estado em Não verificado, que nunca é eliminado. Só os sinais negativos certos (sintaxe, ausência de MX/A, rejeição 5xx) tornam um cliente eliminável. Combinada com a proteção dos clientes com encomendas, esta lógica evita apagar um cliente real por engano.
Compatibilidade e notas técnicas
- PrestaShop 8.0 a 9.x, multiloja. Interface fornecida em FR, EN, ES, IT, DE e PL.
- Controlador de administração legacy (sem controlador Symfony), para compatibilidade com PS8 e PS9.
- Hooks:
actionObjectCustomerAddAfter,actionObjectCustomerUpdateAfter,actionObjectCustomerDeleteAfter,additionalCustomerFormFieldsevalidateCustomerFormFields. - Endpoint AJAX de back-office através do 4.º argumento de
getAdminLink(); resposta JSON por um método dedicado. - Tabela
df_email_check: um registo por cliente (e-mail, estado, código de detalhe, data do controlo). - Sem chamadas a serviços de terceiros: a verificação assenta apenas no DNS e, em opção, numa ligação SMTP direta.
Como não há chamadas a serviços externos, os endereços dos seus clientes não saem do seu servidor: é um ponto a favor no seu registo de atividades de tratamento, sem subcontratante a declarar para esta finalidade.
Perguntas frequentes e resolução de problemas
A verificação SMTP devolve sempre «Não verificado». O porto 25 de saída está provavelmente fechado pelo seu alojamento. Desative a sonda SMTP: a verificação do domínio (MX) chega na maioria dos casos.
Há clientes legítimos que aparecem «Em risco». O servidor de correio deles está em catch-all (aceita todos os endereços). É um comportamento do servidor, não um erro; esses clientes nunca são eliminados automaticamente.
A limpeza não elimina qualquer cliente, apesar de o contador de Inválidos ser positivo. Verifique a opção «Proteger os clientes com encomendas»: os clientes inválidos com uma encomenda são propositadamente ignorados.
O bloqueio no registo não é acionado. Alguns módulos de início de sessão rápido ou de janela emergente criam o cliente sem passar pelo formulário normal do PrestaShop; nesse caso, a verificação continua a ser feita logo após a criação da conta, e o cliente aparece então como «Inválido» na lista.
A verificação atrasa o registo? Não. No registo, só é executada a verificação rápida (sintaxe e domínio). A sonda SMTP só intervém nas verificações em massa a partir do back-office.