# Verificação dos e-mails de clientes: guia completo

> 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,…

- Página: <https://www.datafirefly.com/pt/documentation/dfemailcheck/>
- Idioma: pt
- Atualizado em: 2026-09-09
- Outros idiomas: [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), [it](https://www.datafirefly.com/it/documentation/dfemailcheck/index.md), [pl](https://www.datafirefly.com/pl/documentation/dfemailcheck/index.md), [nl](https://www.datafirefly.com/nl/documentation/dfemailcheck/index.md)
- Índice: <https://www.datafirefly.com/pt/documentation/llms.txt>

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

1. Descarregue o arquivo `dfemailcheck.zip` a partir da sua conta DataFirefly.
2. Back-office do PrestaShop → **Módulos** → **Carregar um módulo** → envie o ZIP.
3. 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`, `additionalCustomerFormFields` e `validateCustomerFormFields`.
- 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.