Verifyre

GDPR and email verification: is verifying your list compliant?

Email verification is compatible with GDPR when done under a lawful basis with a processor agreement, minimal data and short retention. What to ask a vendor and what to record.

Yes, email verification is compatible with GDPR when it is done under a lawful basis, through a processor bound by a data processing agreement, with minimal data and short retention. An email address is personal data and checking it is processing, so the normal rules apply: know why you are doing it, use a vendor that only does what you tell it, keep the results no longer than needed, and be able to show your reasoning. Verification does not create consent and does not make an unlawful list lawful, but it does support the accuracy principle GDPR itself imposes. This is general information, not legal advice.

Is an email address personal data?

Almost always. Under GDPR, personal data is any information relating to an identifiable person. firstname.lastname@company.com identifies a person directly. Even a pseudonymous address like skyfox77@gmail.com relates to an identifiable individual, because the provider can link it to one. The only common exception is a generic role address such as info@company.com that identifies an organisation rather than a person, and even that can be personal data in a one-person business.

Sending an address to a verification service, receiving a verdict about it and storing that verdict are all processing operations. So the question is not whether GDPR applies, but how to comply.

What is the lawful basis for verifying email addresses?

For most organisations the basis is legitimate interest (Article 6(1)(f)). The interests are concrete:

  • Accuracy. Article 5(1)(d) requires that personal data be accurate and kept up to date, with reasonable steps taken to erase or rectify inaccurate data. An email address that no longer works is inaccurate data. Verifying and removing it is a step towards complying with the principle, not a departure from it.
  • Security and system integrity. Blocking disposable and invented addresses at signup prevents fake accounts, fraud and abuse, which recital 49 recognises as a legitimate interest.
  • Sender reputation. Keeping bounces under the 2% line protects the organisation's ability to deliver mail to everyone else on the list, including transactional messages people rely on.

Legitimate interest requires a balancing test: the processing is necessary for the interest, and the person's rights do not override it. Verification scores well on that test because the impact on the individual is minimal (nobody receives a message, nothing about them is disclosed, and a wrong address is simply not mailed). Write the assessment down; a one-page legitimate interest assessment is enough.

Where you already hold the address under consent (a newsletter signup, say), verifying it is a reasonable step within the purpose the person agreed to, because they expect you to be able to reach them at it.

What must a verification vendor offer?

The vendor is your processor, and Article 28 sets out what the relationship needs. In practice, check for:

  • A data processing agreement (DPA) that you can sign or that is incorporated into the terms, covering the Article 28 clauses.
  • Data minimisation. The vendor needs the address and nothing else. It should not ask for names, IPs or list metadata to perform a check.
  • Retention limits. Results should be deleted after a fixed period you can see, and the vendor should not keep your addresses indefinitely. Verifyre's GDPR page states the retention periods and the security page covers storage.
  • No onward use. Your list must never be used to train, enrich, resell or cross-reference other customers' lists. A vendor that offers "append" or "enrichment" products built from customer uploads is a warning sign.
  • Sub-processor transparency. A published list of sub-processors (hosting, DNS, support tooling) with notice of changes.
  • Deletion on request of both the uploaded addresses and the results, with confirmation.
  • Transfer safeguards. If data leaves the EU or UK, standard contractual clauses or an adequacy decision, and the vendor should say where processing happens.
  • No message sent. Verification should stop before the SMTP DATA command, so no email is ever delivered to the person as a side effect of checking them.

What questions should you ask a vendor?

QuestionWhat a good answer looks like
Do you sign a DPA?Yes, available without negotiation, Article 28 terms included
What data do you need to verify an address?The address only
How long do you keep uploaded lists and results?A fixed, stated period, typically 30 to 90 days, with earlier deletion on request
Do you use my data for anything else?No; no enrichment, no shared database built from customer uploads
Who are your sub-processors?A public list with change notifications
Where is the data processed and stored?Named regions, with transfer safeguards if outside the EU or UK
Does verification send an email?No, the check stops before DATA
How do I delete everything?A self-service delete plus a documented request route
Do you have a security page and incident process?Yes, with breach notification timelines

What does verification not do?

It is worth being precise about the limits, because they are where organisations get into trouble.

  • It does not create consent. A verified address is a working address, not a permitted one. If the person never agreed to marketing and you have no other basis, verification changes nothing.
  • It does not make a purchased list lawful. A bought list's problem is sourcing, not accuracy. Cleaning it tells you which addresses exist; it does not tell you whether you may contact them. See email verification for cold outreach for how B2B teams approach legitimate interest.
  • It is not proof of ownership. Only a confirmation click proves the person who typed the address controls it, which is why double opt-in still matters for consent records. Double opt-in vs single opt-in sets out when each is appropriate.
  • It does not override a withdrawal. An address on your suppression list stays suppressed however deliverable it is.

What records should you keep?

A short file is enough, but it should exist before a regulator or a data subject asks:

  1. The legitimate interest assessment for verification, one page, dated.
  2. The signed DPA and the vendor's sub-processor list as at signing.
  3. Your retention setting and the schedule that deletes verification results.
  4. An entry in your record of processing activities (Article 30) naming the vendor, the purpose and the retention period.
  5. The verification logs themselves while retained, so you can show which addresses were removed and why.

For bulk cleaning, the bulk list cleaning feature returns a per-address reason code, which is exactly the "why" a record needs.

Key takeaways

  • An email address is personal data and verification is processing, so GDPR applies.
  • The lawful basis is usually legitimate interest, supported by the accuracy principle in Article 5(1)(d).
  • Choose a processor that signs a DPA, takes only the address, keeps it briefly, never reuses it and names its sub-processors.
  • Verification does not create consent or make a purchased list lawful.
  • Keep a one-page assessment, the DPA, a retention schedule and a line in your processing record.

Frequently asked questions

Usually not. Legitimate interest covers accuracy, security and sender reputation, provided you have documented the balancing test and the vendor acts only as your processor.

Does the person find out their address was verified?

No. Verification stops before any message is sent, so there is nothing in their inbox. They still have the right to ask what processing you carry out, and verification should appear in your privacy notice.

Can I verify a list I bought?

You can check whether its addresses work, but that does not give you a basis to email them. Treat sourcing and lawful basis as a separate question answered before any send.

Is UK GDPR different?

The principles and the processor requirements are the same. The main practical difference is transfer rules: data moving between the UK and the EU is covered by adequacy decisions in both directions, while transfers elsewhere need safeguards.

Put it into practice.

100 free verifications on signup. Clean a list, add the widget, or call the API.

Start free See pricing