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 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.

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 (hook actionValidateCustomerFormFields). 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).

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 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.

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, translatable interface.
• Legacy admin controller (no Symfony controller) for PS8/PS9 compatibility.
• Hooks: actionObjectCustomerAddAfter, actionObjectCustomerUpdateAfter, actionObjectCustomerDeleteAfter, actionValidateCustomerFormFields.
• 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. The form validation hook depends on the PrestaShop version; if your version does not fire it, 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.