Is email verification GDPR compliant? What to check before you run a list

Email verification can be run in a GDPR-compliant way, but the check itself doesn't make it compliant or non-compliant. What matters is the same set of questions you answer for any processing of personal data: which lawful basis you rely on, whether you send only what the check needs, who processes the addresses on your behalf, and how long anything is kept. An email address tied to a person is personal data, so verification is processing.

This isn't legal advice. It's the checklist a RevOps or growth team can work through before the conversation with your counsel, so that conversation is short.

Pick a lawful basis before you upload a list

GDPR Article 6 lists six lawful bases. For list hygiene, most teams look at legitimate interests, Article 6(1)(f): processing is lawful where it is "necessary for the purposes of the legitimate interests pursued by the controller", unless the person's interests or rights override them. Recital 47 adds that processing strictly necessary for preventing fraud is a legitimate interest, and that direct marketing "may be regarded as" one.

That word "may" is doing work. The UK ICO frames legitimate interests as a three-part test:

1. Purpose. Do you have a legitimate interest? Keeping bounce rates down so your mail reaches the people who asked for it is a concrete one. So is stopping fake signups.
2. Necessity. Is verifying the address necessary for that purpose, or is there a less intrusive way?
3. Balancing. Do the person's interests override yours? A check that sends them nothing and keeps nothing extra is easier to balance than one that builds a profile.

The ICO says you must pass all three before you start. Write your reasoning down. Verification doesn't fix a list that was collected unlawfully. Checking that a scraped or bought address exists answers a deliverability question, not a lawful-basis one.

Send the vendor only the email column

Article 5(1)(c) requires data to be "adequate, relevant and limited to what is necessary". For verification, that's one field. You don't need to upload names, job titles, phone numbers or deal values to find out whether jane@example.com accepts mail.

In practice:

• Export the email column on its own, verify it, and join the results back by address inside your own systems.
• If you call an API from a CRM workflow, pass the address, not the whole contact record.
• Delete the export file when the job is done.

Article 5(1)(d) also says personal data should be "accurate and, where necessary, kept up to date". Removing addresses that no longer exist is one of the less controversial things you can do with a list.

Treat the verification vendor as a processor

When a vendor checks addresses on your instructions, it usually acts as your processor. Article 28 says you may use only processors "providing sufficient guarantees" and that the processing must be governed by a contract. Before you pick a provider, ask:

• Where is the data processed, and by which sub-processors?
• What is stored after the check, in what form, and for how long?
• Can you delete uploaded files yourself?
• Does the vendor reuse your addresses for anything else, such as building its own database?

If a vendor can't answer these in writing, that's your answer. Our guide to choosing an email verification API has the rest of the evaluation list.

What pingutil stores when you verify an address

Here is the factual version for pingutil's email verification, so you can put it in your records of processing:

The check itself runs syntax, the disposable-domain list, DNS and MX, then an SMTP handshake with the recipient's mail server that stops at RCPT TO. No message is sent to the person. The details of that handshake, and why it can't always give an answer, are in SMTP verification limits.

If you only need to know whether an address is disposable or from a free provider, you don't need a mailbox check at all. The cheaper, less intrusive option often passes the necessity test more easily. See email validation vs verification for where that line sits.

Questions to settle with your counsel

• Which lawful basis covers verification for each source of addresses (signups, events, purchased or enriched lists)?
• Is verification mentioned in your privacy notice under list maintenance or fraud prevention?
• Is there a data processing agreement with the verification vendor, and does it list sub-processors?
• How long do you keep invalid addresses? Suppressing an address so you never mail it again is different from storing it for no reason.
• Do any contacts sit outside GDPR scope, under rules like the UK GDPR or US state laws, that change the answer?

Run that list once, record the outcome, and verification becomes a routine part of keeping data accurate. To see the exact fields a check returns before you decide, try an address in the verification demo or read the /v1/verify reference.