# Customer Email Verification — Complete Guide

> Customer Email Verification checks the real deliverability of every email address in your store: syntax, domain existence through its MX records and, optionally, an SMTP probe that queries the recipient…

- Page: <https://www.datafirefly.com/en/documentation/dfemailcheck/>
- Language: en
- Last updated: 2026-08-28
- Other languages: [fr](https://www.datafirefly.com/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), [pt](https://www.datafirefly.com/pt/documentation/dfemailcheck/index.md), [nl](https://www.datafirefly.com/nl/documentation/dfemailcheck/index.md)
- Index: <https://www.datafirefly.com/en/documentation/llms.txt>

Customer Email Verification checks the real deliverability of every email address in your store: syntax, domain existence through its MX records and, optionally, an SMTP probe that queries the recipient server. Each customer's status (Valid, Invalid, Risky, Unchecked) appears in a dedicated back-office tab, where you can verify the whole base in batches and delete every customer whose email does not exist in one click — without ever erasing a real customer by mistake. This guide covers installation, configuration, verification levels and database cleanup.

## Installation

1. Download the `dfemailcheck.zip` archive from your DataFirefly account.
2. PrestaShop back office → **Modules** → **Upload a module** → send the ZIP.
3. On install, the module creates its `df_email_check` table, registers its hooks and adds the **Customers → Email Verification** tab.

Compatible with PrestaShop 8.0 to 9.x, on PHP 7.4 to 8.3. No theme override, no Composer dependency. Multistore-compatible and translatable.

## Configuration

Go to **Modules → Customer Email Verification → Configure**.

### Verification at signup

When the **Verify on account creation** option is enabled, every new customer is checked automatically on creation (hook `actionObjectCustomerAddAfter`). Only the fast check — syntax and domain — runs at this point, so the checkout funnel is not slowed down. The status is also recalculated when a customer changes their email address.

### Registration blocking

The **Block registration if domain invalid** option rejects the registration form when the email domain has no MX or A record (hooks `additionalCustomerFormFields` and `validateCustomerFormFields`). The customer then sees an error on the email field. Disabled by default.

### SMTP verification (advanced)

The SMTP probe confirms the mailbox really exists by talking to the recipient server (the `RCPT TO` command), with catch-all server detection. Three settings go with it:

- **SMTP verification**: enables or disables the probe. Disabled by default.
- **SMTP sender address**: the address announced during the dialogue (`MAIL FROM`).
- **SMTP timeout**: maximum wait per server, in seconds (6 by default).

SMTP verification requires **outbound port 25**, very often closed on shared hosting. Without it, verification stops at the domain — which already catches the vast majority of fake addresses.

### Deletion safety

- **Protect customers with orders**: prevents the deletion of any customer with at least one order, to avoid orphan orders. Enabled by default.
- **Batch size**: number of customers processed per pass during bulk verifications (50 by default).

## Verification levels

The check runs at three levels, from fastest to most precise:

- **Syntax**: validation of the address format.
- **Domain**: lookup of the domain's MX records, falling back to A/AAAA records.
- **SMTP (optional)**: dialogue with the recipient server to confirm the mailbox, with catch-all server detection.

## Statuses

Each customer receives one of the following four statuses:

- **Valid**: correct syntax and a reachable domain (and a confirmed mailbox if the SMTP probe is on).
- **Invalid**: a definite negative signal — bad syntax (`bad_syntax`), a domain with no MX or A (`no_mx`), or an explicit SMTP rejection (`smtp_rejected`). These are the only deletable customers.
- **Risky**: catch-all server (`smtp_catch_all`) — the address is accepted but the server also accepts non-existent addresses. Never deleted automatically.
- **Unchecked**: an inconclusive result — timeout, closed port, greylisting, or a customer never checked. Never deleted.

The detail code (for example `no_mx`, `smtp_catch_all`) is shown next to the status in the list, to explain every decision.

## The dashboard

The **Customers → Email Verification** tab shows five counters at the top: total number of customers, valid, invalid, risky and unchecked. Below, the full customer list can be filtered by status. Two buttons launch the verification:

- **Verify new customers**: only checks customers that were never verified.
- **Re-verify everything**: re-checks the entire base.

Processing runs in batches over AJAX, with a progress bar, which makes it possible to handle large bases without timing out. The SMTP probe, when enabled, is only used during these bulk verifications.

## Deleting invalid customers

The **Delete invalid customers** button erases, in one pass, every customer with the _Invalid_ status. Customers who placed at least one order are skipped while the protection option is on. You can also act on a specific selection through the list's **bulk actions**: _Re-verify the selection_ or _Delete the selection_. Deletion uses PrestaShop's native mechanism (`Customer::delete()`) and also cleans up the results table.

Deleting a customer is permanent. Check the "Invalid" counter and, if needed, filter the list on that status to review the addresses before the purge.

## Safety — zero false positives

The module's core rule: an address is never marked _Invalid_ on mere doubt. A timeout, greylisting, a closed SMTP port or a temporary (4xx) response leave the status as _Unchecked_, never deleted. Only definite negative signals (syntax, missing MX/A, 5xx rejection) make a customer deletable. Combined with the protection of customers with orders, this logic avoids erasing a real customer by mistake.

## Compatibility and technical notes

- PrestaShop 8.0 to 9.x, multistore. Interface shipped in FR, EN, ES, IT, DE and PL.
- Legacy admin controller (no Symfony controller) for PS8/PS9 compatibility.
- Hooks: `actionObjectCustomerAddAfter`, `actionObjectCustomerUpdateAfter`, `actionObjectCustomerDeleteAfter`, `additionalCustomerFormFields`, `validateCustomerFormFields`.
- Back-office AJAX endpoint via the 4th argument of `getAdminLink()`; JSON output through a dedicated method.
- `df_email_check` table: one record per customer (email, status, detail code, check date).
- No third-party service call: verification relies only on DNS and, optionally, on a direct SMTP connection.

## FAQ and troubleshooting

**SMTP verification always returns "Unchecked".** Outbound port 25 is probably closed by your host. Disable the SMTP probe: domain verification (MX) is enough in most cases.

**Legitimate customers appear "Risky".** Their mail server is catch-all (it accepts every address). This is server behavior, not an error; these customers are never deleted automatically.

**The purge deletes no customer even though the Invalid counter is positive.** Check the "Protect customers with orders" option: invalid customers who have an order are deliberately skipped.

**Registration blocking does not trigger.** Some quick-login or popup modules create the customer without going through the standard PrestaShop form; in that case, verification still runs right after the account is created, and the customer then appears as "Invalid" in the list.

**Does verification slow down signup?** No. At signup, only the fast check (syntax and domain) runs. The SMTP probe only runs during bulk verifications from the back office.