App emails going to spam is one of the quietest bugs we deal with, and one of the most damaging. Nobody files a support ticket about it, because the person waiting for the email doesn’t know it exists. They just sit there, refresh their inbox, check junk eventually or not at all, and conclude your product doesn’t work. We’ve opened up more than one “vibe-coded” app where the founder swore the signup flow was fine, only to find password resets, receipts and welcome messages sitting in a spam folder they’d never checked.
This one is invisible by design, which is exactly why it slips past AI coding tools. Bolt, Lovable, Cursor and the rest are very good at writing the code that calls sendEmail(). They are not good at telling you that the email will actually arrive.
How users lose trust when emails vanish
Put yourself in the shoes of someone signing up for a new app. They enter their email, click “reset password” or “confirm account”, and wait. If nothing shows up within a minute or two, most people don’t wait around. They assume the app is broken, and either give up or fire off an angry message asking why nothing’s working.
The maths is brutal here. If your password reset email lands in spam even 20% of the time, you are losing a meaningful chunk of every cohort that ever needs a reset, and password resets happen constantly. Add in receipts that never arrive after a payment, and you’ve got customers who paid you money and have no confirmation that it went through. That’s the kind of thing that generates chargebacks and one-star reviews, not just quiet churn.
We wrote about how a vibe-coded app breaks in production in general terms before, but email deliverability deserves its own mention because it’s one of the few failure modes that looks completely fine in a demo. You test the signup flow yourself, the email arrives instantly because your own inbox trusts your own domain, and you ship it. Then a stranger with a Gmail or Outlook address signs up and gets nothing.
Why AI-built apps send from the wrong place
Here’s the part that catches people out. When an AI tool wires up email sending, it usually reaches for whatever is fastest to configure: the default sender address baked into your hosting platform, a free tier of Supabase auth emails, or a generic “no-reply@yourapp.com” address that was never actually set up to send anything.
The problem is that sending an email “from” a domain and being allowed to send email “as” that domain are two different things. Spam filters at Gmail, Outlook and Yahoo don’t just read the sender field and take your word for it. They check whether the mail server that actually sent the message has been authorised, in writing, by the domain owner, to send on that domain’s behalf. If it hasn’t, the message either gets marked as spam or dropped entirely, and you never even see a bounce.
Shared hosting platforms and default auth providers often send from a shared IP address or a shared subdomain used by thousands of other apps, some of which are spammers. Your legitimate password reset email gets tarred by the same brush. We see this constantly with Supabase’s default auth emails in particular, which is a pattern we cover in more depth in our piece on Supabase mistakes in AI-generated code. It’s rarely something the AI tool got “wrong” exactly. It just never had a reason to set up domain authentication, because nothing in the prompt asked for it, and nothing in the demo revealed it was missing.
SPF, DKIM and DMARC explained without the acronym soup
You don’t need to memorise these terms, but it helps to understand what they’re actually doing, because your developer or agency will ask you to add DNS records with these names on them.
Think of it like a hotel checking in a guest. SPF is the guest list: it’s a DNS record that says “these specific mail servers are allowed to send email claiming to be from our domain.” If a message arrives from a server not on that list, it’s suspicious.
DKIM is more like a wax seal on a letter. It attaches a cryptographic signature to every email you send, so the receiving server can verify the message wasn’t altered in transit and genuinely came from a server you control. Without it, a message can be technically allowed to send (SPF passes) but still look untrustworthy because it can’t prove it wasn’t tampered with.
DMARC is the policy that ties the other two together. It tells receiving mail servers what to do if a message fails SPF or DKIM checks: quarantine it, reject it outright, or let it through anyway. Without a DMARC record, mailbox providers have no instructions, and they default to being cautious, which usually means your edge-case emails get treated with suspicion even when nothing’s obviously wrong.
Set up properly, these three records tell Gmail and Outlook “yes, this really is us, and here’s proof.” Missing even one of them is often the entire difference between an inbox and a spam folder.
Choosing a transactional email service
The fix isn’t complicated, but it does mean stepping outside whatever your AI tool defaulted to. Transactional email providers exist specifically to solve this problem: Postmark, Resend, SendGrid and Amazon SES all let you send from your own domain with proper authentication, and they give you delivery logs so you can see exactly what happened to every message you send.
We generally point founders toward Postmark or Resend for early-stage apps because the setup is quick and the dashboards are readable by non-developers. Whichever one you pick, the important step is the same: add a custom sending domain (not a shared one), verify it with the provider, and add the SPF, DKIM and DMARC records they give you to your domain’s DNS settings. This is a fifteen-minute job for someone who knows what they’re doing, and it should happen before launch, not after your first angry customer email. It belongs squarely on your pre-launch checklist, right alongside checking that your authentication flow actually sends its confirmation and reset emails in the first place, since auth emails are usually the first casualty.
How to test where your emails land
You don’t have to guess. Free tools like mail-tester.com will give your setup a score out of 10 and tell you exactly which record is missing or misconfigured. Send a test email through your app to the address it gives you, and it’ll flag SPF, DKIM and DMARC issues in plain language.
Beyond that single test, sign up for your own app using a Gmail account, an Outlook account and, if you can, a Yahoo account, and watch where the emails land, not just whether they arrive. Do this after every change to your email sending setup, not just once at launch, because moving hosting providers or swapping auth libraries can quietly break authentication that used to work.
Users not getting your emails? We’ll find out why. Get a free assessment and we’ll check your deliverability setup before it costs you another signup.