Why your sign-up emails go to spam (and how to fix it)

Here’s a launch problem you can’t see from your own dashboard. Someone finds your app, types their email, clicks “Sign up” and waits for the confirmation link. It goes to spam. After a minute they close the tab. In your numbers, that person just looks like a visitor who didn’t convert.

Test it before anyone else does

Sign up to your own app twice: once with a Gmail address and once with an Outlook or Hotmail one. If either email lands in spam, or takes more than a minute to arrive, keep reading.

Then open the email in Gmail, click the three dots and choose Show original. Near the top you’ll see three lines: SPF, DKIM and DMARC. You want all three to say PASS. A FAIL, or a line that’s missing, is your answer.

For a second opinion, send a test email to mail-tester.com. It gives you a score out of ten and lists what to fix.

Stop using the test email service

Many AI-built apps send sign-up emails through their database provider’s built-in service, most often Supabase’s. It’s there so you can test sign-ups while you build: it only allows a few emails per hour and isn’t meant for real users. On launch day that limit runs out fast, and emails start arriving late or not at all.

The fix is to connect a real email provider. Resend, Postmark, Amazon SES and Brevo are all fine, and their free tiers cover an early launch. Supabase calls this custom SMTP, and you’ll find it in your project’s Authentication settings.

Send from your own domain

An email from bloomly.app@gmail.com, or from the builder’s default no-reply address, looks wrong to spam filters and to people. Use an address on your own domain, like hello@yourapp.com, and a sender name people recognise: your app’s name, not “noreply”.

Add SPF, DKIM and DMARC

These sound technical, but in practice you copy three values from your email provider into your domain’s DNS settings, wherever you bought the domain or in Cloudflare.

• SPF says which services are allowed to send email for your domain.
• DKIM signs each email, so inboxes can tell nobody changed it on the way.
• DMARC tells inboxes what to do with emails that fail those checks, and emails you reports. Start relaxed, with v=DMARC1; p=none; rua=mailto:hello@yourapp.com, and make it stricter once everything passes.

Gmail and Yahoo have required senders to authenticate their email since February 2024. If you send more than 5,000 emails a day to Gmail, you need all three, plus a one-click unsubscribe in marketing emails. A new app sends nowhere near that, but meeting the same standard is the simplest way into the inbox.

DNS changes can take an hour to spread. Then send yourself another sign-up email and check Show original again.

Make the email look like a real one

Spam filters read the email too. Keep the subject plain, “Confirm your Bloomly account” rather than “ACTION REQUIRED”. Use one button, with the same link written out underneath. Link only to your own domain, because link shorteners are one of the oldest spam signals. And check that your provider sends a plain-text version alongside the designed one.

Grow slowly

A new domain has no reputation. Sign-up emails trickling out one by one are fine. Importing a list of 2,000 contacts and emailing them all on launch day isn’t, and it can drag your sign-up emails into spam with it. Only email people who asked to hear from you.

Still landing in spam?

Look your domain up on a blocklist checker such as MXToolbox. Once you send more volume, Google Postmaster Tools shows how Gmail rates your domain. And ask a few early users to move your email out of spam and reply to it. Real replies tell inboxes your emails are wanted.