Keeping your email deliverability high by filtering invalid emails

Keeping data consistent, compliant and true is pretty hard nowadays. We are aware of legacy code and tech debt problems, but rarely concern ourselves with data debt. This problem doesn't show much if you have a 100% subscription business and you delete users whose subscriptions have expired . I know that some companies want to keep all the data forever, but this is both a huge privacy compliance hole, and can also be a performance hole. I’ll write about the performance problem deeper in another post.
For now, let’s talk about emails. Most web applications use a similar flow. When a user signs up to your application, they enter their email and continue with whatever authentication is popular at the moment. This might be entering the password, might be a one-time token sent to their email or creating a passkey. Now you have a user in your system, and if you allowed them to create an account using their email and password, you have to verify their email. A common way is not letting the user in unless they confirm their email. Yet there are still some big companies that don’t care about email confirmation upfront because they want to capture the users.
But what happens if you have a very old (more than a decade old) dataset on a freemium product with a lot of unverified emails? Well, then you have at least three possible problems:

1. Unverified but valid emails
2. Unverified but emails that were valid at signup ([e-mail] doesn’t work there anymore, their email was removed from the server)
3. Unverified and invalid emails (someone signed up using someone else’s email)

If you find yourself in this situation, don’t worry, we have many tricks up our sleeves to clean up the dataset and make sure it never gets too dirty.
First things first, if you don’t have email verification turned on (and re-verification on email change) make sure it’s enforced on all new accounts. You have to start capturing healthy data somehow. Then delete unverified email accounts after a short period (create a weekly task or something). And making sure that we don't send anything except the verification one to that address.

Now for the legacy data cleanup. Something I love is getting an email that my account is being marked for deletion in X days. And this arrives from a company I signed up for a couple of years ago, to test their product. This might even make me log back in to see whether something changed, if I even remember what it was.

Let’s see how we can apply this process to our situation. First you create a new policy where you delete the user data after 12 months of inactivity. Nowadays it’s hard to even make the users use your application and pay for it, so you don’t want to force anyone to click or anything. But we can use this policy update email to filter out bounced/invalid emails . It will drop your email provider reputation for a short while. But since you are sending a valid email to all your users and it’s easier to dispute this than a spam email. After the email went out to all users, your email service provider now has invaluable data you can now use to your advantage. And this is the bounces/invalid emails lists in their system. Let’s say you have 2000 users, send them the policy update email, and you get 250 bounced and/or invalid emails. This would mean that your email delivery rate is 87,5% which isn’t that good, but it’s also not the end of the world. Let’s turn this into our favour, export those lists and mark the users as having invalid emails. Now if a user has been inactive for a long period of time (longer than your stated policy) and also has an invalid email, go ahead and delete them. And actually delete them, don’t update the email to @deleteduser.com. If a user is active, you have to somehow tell them that their email is invalid, and this is where you need to get creative. Pop-up message in your app that they need to verify/change their email is one way to go, with different levels of discomfort to the user (small popup, big popup, whole screen modal). You can embed a verification parameter into all the links sent to that email, and capture those clicks in your application. All these will add a bit of programming and server overhead, of course, but better to be safe than sorry.
And then you step into a final pitfall that I’m still uncertain about. When verifying the new email, do you verify the new email or the old one, do you send a message to the old one that the user changed their email? This is a problem for another day and another post. Let’s go back to our problem, you want to keep all the users you can (especially the ones paying you) and convert the trials to paid if possible. But you also want to keep your data clean and true.
And there is only one sane way out of this situation, and this means making sure all your users’ emails are valid. If they are not, and the users are active, make sure they verify their valid emails and change invalid ones. This makes both your database and your email provider happy. Your email sending reputation stays as high as possible with much less chance of ending up in spam.