To add email verification to an app you first need somewhere to send the email.
To add email verification to an app, you send a one time code or link to the address the user typed, and you do not treat that address as real until it comes back. The flow itself is about a day of work. The honest limit belongs at the top rather than the bottom: your app cannot send that email by itself. You need an outside email provider, a domain you control and DNS records set on it. Verification also assumes accounts already exist, so start with adding user login and come back to this.
This page covers what the check actually proves, whether to use a code or a link on a phone, what the sending costs, why the message lands in spam, and when skipping verification is the better answer.
Work out what your emails will costThe short version
Verification proves one thing: someone could open that inbox.
It does not prove a name, an age or an intention. It proves that at the moment of signup, whoever was holding the phone could also read mail sent to the address they typed. That is a smaller claim than most teams think they are buying, and it is still worth having. It kills typos, it slows down throwaway signups, and it is what makes password reset possible at all.
What it costs you is a dependency. Every message leaves your app, passes through a provider you pay, and gets judged by the receiving mail server before the user sees anything. Budget one day for the flow and a second day for making the mail arrive.
A six digit code beats a link on a phone
There are two shapes this can take. Send a link, the user taps it, a page opens and tells your server the token is good. Or send a six digit code, the user reads it, switches back to your app and types it in. Web apps default to the link because a browser is already open. On a phone that default is wrong.
A tapped link opens in whatever browser the mail client feels like using, often a stripped down view inside the mail app itself. Getting from there back into your app needs universal links on iOS and app links on Android, configured correctly on both, and they have to survive that in app browser. Every step is somewhere the user can strand on a web page that says Verified while the app behind it still thinks they are not. A code has none of that. It is six characters and a keyboard.
So use a code first if you are mobile only, and add the link later if you also have a website to serve. Whichever you pick, give the token a short life and a single use. Ten to fifteen minutes is a sane window for a code and an hour is generous for a link, and both should stop working the moment they are used or a newer one is issued. This is one piece of app authentication, and it is the piece that leans hardest on something outside your own code.
Double opt in, the mailing list version of the same idea, is a slightly different animal. It asks permission to keep sending mail rather than proving the address works. In a mobile app the two usually collapse into one screen, which is fine, as long as the wording is honest about what else you intend to send. Do not verify an address and quietly read that as consent to a newsletter.
The email has to survive the receiving server
The most common failure in this feature is not in your code. It is the message going to spam, or being dropped before it gets that far. The receiving mail server decides that, and it decides mostly on how your sending domain is set up rather than on what the message says.
Google publishes the rules it applies to mail sent to Gmail. Every sender has to set up SPF or DKIM authentication for their sending domain. Senders of more than 5,000 messages a day to Gmail accounts need both of those plus DMARC, and have to keep the spam rate reported in Postmaster Tools below 0.3%. A verification message is transactional rather than marketing, so the one click unsubscribe rule for bulk senders does not apply to it, but authentication is not optional at any volume.
In practice that means three things before launch. Send from a domain you own rather than a free mailbox address. Add the DNS records your provider hands you, then do a test send to a real Gmail account and read the raw headers to confirm both checks pass. And expect some mail to be slow anyway, because greylisting and queueing are normal and a user watching an empty inbox has no idea that is happening.
Then build for the failure. Show the exact address you sent to, offer a resend that is not rate limited into uselessness, and let someone correct a mistyped address without deleting the account and starting again. A signup locked behind an inbox nobody can reach is a support ticket you cannot close.
What sending the mail actually costs
Almost no app builder or hosted backend sends production email on your behalf, and Newly is no exception: the backend it builds does not set up email sending, so verification and password reset messages do not go out until you add a provider and set its API key as a secret. Treat that as the norm rather than a gap. A platform that sent your mail for you would be spending its own domain reputation on your signups, and that arrangement fails at exactly the wrong moment.
The good news is that transactional email is cheap. Resend publishes its rates in full: the free plan covers 3,000 emails a month with a limit of 100 a day, and the first paid tier is $20 a month for 50,000. Postmark, Mailgun, SendGrid and Amazon SES publish their own transactional tiers. Compare them on the free allowance and the daily cap rather than on the headline monthly price, because that is the number a new app runs into.
The figure that catches people is not the monthly one. One signup is rarely one email. There is the first message, the resend when it does not arrive, the reset a week later, a second verification after an address change. Plan on well over one email per new user. Then remember signups are not evenly spread: a launch, a press mention or a campaign can put a month of them into an afternoon.
The panel below turns signups into sends and shows which limit you reach first.
Resend pricing, published plans and monthly send limits
Try it
Which sending limit you hit first
One signup is rarely one email, and signups never arrive evenly. The cap on a single day usually breaks before the monthly allowance does.
1120 a month, 134 on the busiest day
The month fits the free plan, but the busiest day breaks the cap of 100 a day.
Where the verified flag lives, and what it should gate
One rule decides whether any of this is real. The server sets the flag and nothing else can. The client sends a code, the server compares it against a token it issued, and only then does the user record change. If your API will accept a verified field sent by the app, you have built a decoration rather than a check. If you want the reasoning behind that rather than the rule, why the check matters is the longer version.
Most hosted backends already carry the field and a flow to go with it. Choose a supabase mobile backend and the confirmation step sits inside signup rather than being something you write. Whatever you choose, ask one question early: does it send the mail, or does it expect you to connect a provider? Built in senders that ship with a backend are normally rate limited hard and meant for development, and launch day is a bad time to find that out.
Then decide what the flag actually gates, which is the real product question. A hard gate blocks everything until the address is confirmed, and it costs you signups from people who meant to come back and did not. A soft gate lets people in and holds back only what depends on a reachable inbox: password reset, receipts, email notifications, anything shared with another person. For most consumer apps the soft gate is the better trade, with a reminder that does not nag.
Sometimes the answer is to skip it. If sign in is only through Google or Apple, the provider has already proved the address and asking again is friction for nothing. One caveat worth knowing: Apple can hand you a private relay address instead of the real one. It still reaches the user, and it is not an identifier you can match against anything else you hold.
What each approach actually buys you
| Approach | Proves the inbox works | Catches a typo | Needs an email provider | Where it falls down |
|---|---|---|---|---|
| No verification at all | No | No | No | Reset mail goes nowhere |
| Format check in the app | No | syntax only | No | [email protected] passes |
| Six digit code by email | Yes | Yes | Yes | Slow delivery at the worst moment |
| Verification link by email | Yes | Yes | Yes | Opens a browser, not your app |
| Google or Apple sign in only | Yes | nothing to type | No | Apple may return a relay address |
Building signup and verification into your own app
Written from scratch, the flow is small: issue a token, send it, compare it, set a flag. The work is everything around it. The provider account and its DNS records. The resend button and the cooldown on it. The path that lets someone fix an address they got wrong. The wording of the email itself, which has to read like your product and not like phishing.
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project you own, runs it on a cloud iPhone or Android simulator while it builds, and ships it to TestFlight and to Google Play internal testing. It is $25 a month with no free plan, iOS publishing needs your own Apple Developer account, and email sending is something you connect rather than something you are given. Ask for the verification screen in the same sentence as the login screen and both end up wired to the same user record.
Write the email copy yourself whatever builds the rest. A message that says click here to confirm, with no sender name and no reason, is the one people report as spam, and it takes your sending domain down with it.
Questions people ask about email verification
Generate a one time token when the account is created, send it to the typed address as a six digit code or a link, and have the user return it. The server compares what comes back against the token it issued, and only then marks the address verified. The app never sets that flag itself.
Describe the signup you actually want
Write down where the wall goes, what people can do before they confirm, and what the email says, then build the flow around that instead of around a default.
Start building