Sending mail from someone else's domain reputation
Your app's password reset email is the one message a user will definitely open, and on most no-code platforms it leaves the building on infrastructure you have never seen. Bubble's own reference says that until you add a domain and a SendGrid key, the mail goes out as [your-appname]-no-reply@bubbleapps.io. That address is fine. The part worth thinking about is that the sending reputation behind it was earned by thousands of other apps, and it can be spent by them too.
The default sender is not your domain
Bubble documents this openly, which I respect. SendGrid is the built-in provider. Without your own key, mail leaves from a bubbleapps.io subdomain. Add a domain and you can send from admin@yourdomain.com, but Bubble notes that address still has to be verified inside a SendGrid dashboard before the validation works. There is also a hard cap of 50 recipients per send on the shared address, which Bubble attributes directly to SendGrid rate limiting on that shared sender.
The 50-recipient cap is the visible part and it is the least interesting one. What matters more is that the signal Gmail and Outlook use to decide whether to trust you is being computed on traffic you did not send. Somebody else's badly targeted onboarding blast moves a number that affects whether your customer gets their login link. You cannot see that number and you cannot do anything about it.
Google started grading, and the grade follows the domain
Since February 2024, Google requires anyone sending more than 5,000 messages a day to Gmail accounts to authenticate with DKIM, support one-click unsubscribe on marketing and subscribed mail, and keep the spam rate reported in Postmaster Tools below 0.30%. Those are not suggestions. Google's sender guidelines say mail that misses them might not be delivered as expected.
Postmaster Tools reports against the authenticating domain. If the DKIM signature on your mail belongs to the platform rather than to you, the dashboard that tells you how Gmail feels about your mail is not yours to read. You find out something is wrong the way everyone finds out: a customer emails support asking why they never got the code.
What it costs to own the send
Less than most people assume. Resend's free tier covers 3,000 emails a month at 100 a day, and Pro is $20 a month for 50,000. Postmark starts at $15 a month for 10,000 messages with overage at $1.80 per thousand, or $16.50 on the Pro plan where overage drops to $1.30. For a product sending receipts and password resets, that is a rounding error against the platform bill it sits next to.
The work is DNS and an afternoon. You publish SPF, you publish a DKIM key you generated, you set a custom Return-Path so bounces come back to a hostname you own, and you point a webhook at your own database so every bounce, complaint and open lands in a table you can query. On the Stay World Class migration we moved Webflow and Xano to Next.js, NestJS and Supabase, and having delivery events in Postgres next to the user rows meant a bounced address could be traced to the signup that created it. That join does not exist when the bounce log lives in someone else's product.
Dedicated IPs are mostly not the fix
This is where the argument gets misused, so here is the counterweight. Postmark will only sell you a dedicated IP if you send at least 300,000 messages a month, and it says plainly that for most senders a clean shared pool performs better. Resend sells dedicated IPs at $30 a month, on the Scale plan, to accounts already sending more than 3,000 a day. Postmark's managed warmup takes three to six weeks, and if volume on that IP drops under 20,000 messages a week for four weeks you warm it up again.
So the case is not that you need your own IP. Almost nobody does. The case is that SPF, DKIM, the Return-Path and the bounce stream should carry your name, because those are the things receivers tie to you rather than to the platform.
When the platform sender is the right answer
If you send a few hundred transactional emails a month and nothing you send is time critical, the shared pool is almost certainly fine and wiring up your own ESP is work for its own sake. Same if your mail is internal, or goes to a list of twenty people who already know you. Shared pools at a good provider are well maintained, and the operators watching them do this full time.
The point at which it stops being fine is specific rather than philosophical. You cross 5,000 Gmail messages a day. Or delivery becomes something a customer can complain about, and you need the bounce data to answer them. Or you want to run a suppression list that survives a platform migration. If none of those describe you yet, write down which one will, and move when it does.
