Email verification - best practice - registration flow vs bounces

Calling out for opinions of others on the following challenge.

We all know that Meteor offers email verification as part of the accounts package. However, asking for the email verification breaks up a smooth registration process, as highlighted as well in this excellent article: How to improve registration & sign in process

So for now I have turned the automatic email verification at account creation off however, as I’ve just switched to AWS SES (Simple Email Service) I’m very worried that I will get bouncing emails when I send out my first daily notification email as part of my trial users using my SaaS app. If you’re not aware of it, AWS has some pretty tough measures as to how much bounces and complaints they allow before your account is at risk or blocked!

So I was wondering to rather push the verification email out “silently” (meaning without interrupting the new user to via “Check your email”, forcefully logging them out of my Electron app, check his emails, click on the link before being allowed to log in again) with no other consequences other than that no daily notification is send out to them until they verify their email.

But that’s a challenge too because the daily notification email is crucial to the Gamification of time trial to get the new user to try out all features.

So a couple of questions, hopefully others can let me know how they have tackled this challenge:

Q1: Is there a way to still use meteor-accounts package and its build-in email verification in the silent way I describe above? I think it’s not possible but if I’m wrong please let me know how

Q2: How have you tackled the verification of user emails in your app, when do you verify, at which step of the registration/onboarding process? Please answer only if you run an app in production.

Thanks in advance!

Regarding email verification, we do not require the email to be verified (we do not use the default meteor email registration), but we keep on displaying a notice on the account and other relevant pages (in context) to verify/resend the email.

Regarding AWS SES, we implement a number of ways to ensure that we are not “blocked”

  • we unsubscribe every “complaint” received which is equivalent to users clicking spam
  • we regularly validate our emails through 3rd party validators

Thanks for answering and outlining your approach!

That sounds like an interesting, alternative strategy. May I ask which 3rd party validator you’re using, as I’m not familiar with the topic (other than reading that Sendgrid seems to other a feature like that but as written I’ve just switched to AWS SES).

Neverbounce and Debounce. When an email address is marked as unknown from Neverbounce, we also run it through Debounce. These validators have “expertise” on different things. As an example, Neverbounce is good with Gmail and yahoo, while Debounce is good with outlook.

1 Like