Is Email Verification GDPR-Compliant? What the Rules Say

Email verification is compatible with GDPR, but it is still processing personal data, so the usual rules apply. You need a lawful basis (normally legitimate interests), you should upload only what the check needs, and you need an Article 28 contract with the verifier if it processes the list for you. GDPR's accuracy principle gives verification a clear purpose: keeping the contact data you hold correct.

This guide walks through each requirement with the regulation's own wording, gives a due-diligence checklist for choosing a verifier, and shows what verification does not cover. It is general information, not legal advice. If your situation is unusual, ask a data protection lawyer.

Is verifying an email address "processing"?

Yes. Article 4(2) of the GDPR defines processing as "any operation or set of operations which is performed on personal data", and lists examples including "consultation, use, disclosure by transmission". Uploading a list to a verifier is disclosure by transmission. Checking each address is use.

The question that matters is whether the addresses are personal data. Article 4(1) defines that as "any information relating to an identified or identifiable natural person". In practice:

Address type	Personal data?	Why
jane.doe@company.com	Yes	Identifies a named person
jdoe@company.com	Usually	Identifies a person, especially next to a name column
jane.doe@gmail.com	Yes	A consumer address tied to one person
info@company.com, sales@company.com	Often not on its own	A role address may not relate to an identifiable person, but check what else your file holds about it

For B2B senders, the UK regulator is direct about it. The ICO's business-to-business marketing guidance says "The UK GDPR still applies to B2B marketing if you are processing personal data. For example, if you hold the name of the individual who represents the business."

So a typical cold email list is personal data, and verifying it is processing.

The lawful basis: legitimate interests, backed by accuracy

For most senders the lawful basis for verification is legitimate interests, Article 6(1)(f): processing "necessary for the purposes of the legitimate interests pursued by the controller", unless those interests are overridden by the person's rights.

Two parts of the regulation support verification as a legitimate interest.

The accuracy principle. Article 5(1)(d) requires personal data to be "accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay". An address that no longer reaches anyone is inaccurate for the purpose of contacting that person. Verification is one reasonable step to find and remove it.

The ICO's guide to the accuracy principle puts it in plain terms: "You should take all reasonable steps to ensure the personal data you hold is not incorrect or misleading as to any matter of fact."

Recital 47. It says "The processing of personal data for direct marketing purposes may be regarded as carried out for a legitimate interest" (Recital 47). "May" is doing work there. You still have to run the balancing test.

An important nuance from the ICO

The same ICO page gives an example worth reading closely. An organisation keeping old customers' contact details for marketing "does not have to use data matching or tracing services to ensure its records are up to date", and "it may actually be difficult to show that the processing involved in data matching or tracing for these purposes is fair, lawful and transparent."

Verification is not tracing. It does not look up a person's new address or add data you did not have. It tests whether the address you already hold still accepts mail, and the usual outcome is deleting or suppressing data. That is a much easier case to justify. But the example is a useful warning against verification services that also "append" or "enrich" data. Those are different processing activities that need their own justification.

A short legitimate interests assessment for verification

Record your reasoning in three parts. A few sentences each is enough for most senders.

1. Purpose. "To keep the contact data we hold accurate under Article 5(1)(d), remove addresses that no longer exist, and protect our sending reputation from bounces."
2. Necessity. "Verification checks only the email address. It sends no message. There is no less intrusive way to find dead addresses before sending."
3. Balancing. "The person is not contacted by the check and no new data about them is created. The likely result is deletion of inaccurate data, which is in their interest too."

Data minimisation: upload one column

Send the verifier the email addresses and nothing else. Article 5(1)(c) requires data to be "adequate, relevant and limited to what is necessary".

A CRM export often contains names, job titles, phone numbers, notes and deal values. None of that is needed to check an address. Before you upload:

1. Export only the email column, plus an internal ID if you need to match results back.
2. Keep the full file in your own system.
3. Join the results back to your records with the ID or the address itself.

This also limits the damage if anything goes wrong at the vendor.

Controller and processor: who is responsible for what

You decide why and how the list is checked, so you are the controller. A verifier that checks the list on your instructions is normally a processor.

The ICO's controllers and processors guidance gives the definitions: a controller "determines the purposes and means of the processing", and a processor "processes personal data on behalf of the controller". It adds that "If you are a processor, you have more limited compliance responsibilities."

For EU detail, the European Data Protection Board's Guidelines 07/2020 on controller and processor are the reference text.

What Article 28 requires

Article 28 says the controller "shall use only processors providing sufficient guarantees". The contract must say, among other things, that the processor:

• "processes the personal data only on documented instructions from the controller";
• passes the same obligations on to any sub-processor it uses;
• "deletes or returns all the personal data to the controller after the end of the provision of services", at the controller's choice.

If a vendor reuses customers' lists to build its own database, or keeps results to answer other customers' checks, that goes beyond your instructions. Ask exactly what is stored, for how long, and for whose benefit.

A due-diligence checklist for any verifier

Ask these before the first upload, and keep the answers.

Question	What a good answer looks like
What role do you take for uploaded lists: processor or controller?	A clear answer, consistent with the contract
Do you offer terms that meet Article 28?	Yes, with instructions, sub-processor and deletion terms
What do you store from my upload, and for how long?	Specific items and periods, for example result files kept until deleted, and any per-address cache with its length
Do you use my lists for anything else?	No marketing, no resale, no building a database
Which sub-processors handle the data, and where?	A named list with locations
How are transfers outside the EEA or UK covered?	A stated mechanism under Chapter V (Article 44 onwards)
Can I delete jobs and results myself, or on request?	Yes, with a stated time frame
Does the check send any email to the recipient?	No. An SMTP check ends before any message is sent

For the technical side of choosing a vendor, our guide to what "99% accurate" actually means covers the questions to ask alongside these.

What verification does not cover

Verification answers "does this address still work?", not "may I email this person?". The second question has its own rules.

• A basis for the marketing itself. Whether you may send depends on GDPR and on the electronic-marketing rules where the recipient is (PECR in the UK, national ePrivacy laws in the EU). Our guide to whether it is legal to collect business emails covers the US, UK and EU.
• Telling people where you got their data. Article 14 requires you to tell people "from which source the personal data originate" when you did not collect the data from them. If you use the data to contact them, that is due "at the latest at the time of the first communication".
• Objections. Under Article 21, a person can object "at any time" to direct marketing, and then "the personal data shall no longer be processed for such purposes". That is why you need a suppression list that survives every re-import. See how to build a cold email suppression list.

Worked example: an agency cleaning a client list

An agency in Germany is asked to run outbound for a client. The client hands over a CRM export of 12,000 rows with 14 columns. The figures below are illustrative.

Step	Action	GDPR point it covers
1	Agency and client agree in writing who decides what. The client is controller; the agency is its processor	Article 28 between client and agency
2	Agency checks the verifier's terms, sub-processors and retention	Article 28(2) and (4): sub-processing on the same terms
3	Agency exports 12,000 email addresses and a row ID, 2 of the 14 columns	Data minimisation, Article 5(1)(c)
4	Verification returns, for example, 9,400 valid, 1,500 risky and 1,100 invalid	Accuracy, Article 5(1)(d)
5	The 1,100 invalid addresses are deleted from the client CRM, not just left out of the campaign	Inaccurate data "erased or rectified without delay"
6	Addresses that have objected or unsubscribed are matched against the suppression list before sending	Article 21(3)
7	First emails state where the data came from and how to object	Articles 14 and 21
8	Result files are deleted from the verifier once merged back	Storage limitation, and the Article 28 deletion term

Step 5 is the one most teams skip. Leaving dead addresses in the CRM keeps inaccurate personal data for no purpose. Deleting them is the point of the exercise.

For more on running verification for clients, see email verification for agencies.

How SimpleVerifier handles uploaded lists

These points come from our privacy policy, which describes what the service does today:

• Uploaded files and single checks go to our verification server, hosted by Contabo GmbH in Germany, which checks each address with DNS lookups and a conversation with the recipient's mail server. No email is sent.
• Verification jobs (file name, address count, results and a downloadable results file) are stored against your account so your history follows you, and are deleted on request.
• Confirmed results are cached by address for 14 days, so a repeat check is instant.
• We do not use your lists for marketing, and we do not sell or share them.

Read the full policy, including the list of service providers, before you upload. Pay-as-you-go packs start at $9 for 2,500 verifications, and Pro is $29.99 a month for unlimited checks. See pricing.

The short version

Verification is processing, so treat it like any other processing activity. Legitimate interests is the usual basis, and Article 5(1)(d) gives you the purpose: keep data accurate. Upload one column, put an Article 28 contract in place, ask the vendor what it stores and for how long, and delete what comes back invalid. Then deal separately with whether you may send at all.