Jeff Escalante

Another email mistake that I see often is running e2e test suites against your production instance, and using made up generated email addresses to sign up test users. When you do this, you generate huge numbers of bounces (emails sent to non-existent email addresses), which is not good for your sender reputation, and can result in emails sent to your real users landing in spam. It also clogs up your logs and users tables with a bunch of junk data. If you are running e2e tests that involve signing up users, use a real email address (normally via a mail tester service), or if your auth code/provider supports it, use a "test email" address which allows account creation without email delivery. If you're using @clerk, you can use a test email and/or phone (clerk.com/docs/guides/develo…) for this and it won't send anything, and you can use "424242" as the OTP every time, which makes your tests run a lot faster too.

Here's a pattern that can absolutely murder your startup launch that many are not aware of at all. - You built your product, you're ready to go live with it. You have prepared a producthunt launch, social posts, paid ads, etc. - Conversion, for you, looks like users signing up for your product. - In order for users to sign up, they need to verify their email address. This is a standard, and highly recommended practice to prevent attackers from squatting peoples' emails and/or impersonating them. - 🚀 Your launch is live, it's going great. People are making accounts like crazy. You start sending out a bunch of emails to people who sign up, from your brand new domain that hasn't sent substantial email traffic in the past. - Email providers see this pattern, it exactly matches the way that spammers operate, and they start marking most/all your messages as spam. - Most users don't check their spam folder, and so they never get their OTP to verify their email address, never create their account, and you start bleeding out all the users you worked so hard to get. This situation SUCKS. Don't let it happen to you, or anyone you know. Plan ahead to make sure that you have established a "sender reputation" for your domain. This takes time and conscious effort. Using domain warmup services often backfires. Do it the hard way and it will pay off. Wrote a piece about how you can do this here: clerk.com/docs/guides/develo… I'm also thinking about adding a feature to Clerk where we send ~95% your emails from our own, established domain initially, and gradually reduce that over time to "auto warm up" your custom domain. It would be a paid feature but not too pricey. If anyone's interested let me know, I'd love to get some more feedback on this.

I hate saying no to things so much, and I think that will be my downfall. Especially when they are like, things that are genuinely helpful to others and/or fun and interesting! So many things like this in the world 😞

Fun fact - @clerk now has a backup email provider under the hood, so that if our primary email provider has an outage, your auth is still not impacted. Both providers use entirely different infrastructures, so an AWS or GCP outage can't take them both down. It takes a ton of work to get features like this in place, the many subtle differences between two different providers add up across your customer-facing logs and codebase surfaces. I'm not aware of any other providers that do this. Most people don't know about it at all. It's not a big flashy exciting feature, but often times invisible reliability work is the most important work 🤝

I will be there running very not fast at all if any fellow slow people want to join 😂