How does your app send a reset link or receipt?
A customer asks to reset their password. Your app or sign-in service creates the reset link and hands a message to the email service. The email service tries to deliver it to the address your app supplied. A receipt follows the same pattern when a payment goes through.
Which email should you set up first?
Choose one action a customer can take today. Send a reset link when they ask to get back in, or a receipt after their payment goes through.
Check which tool already handles the action. Your sign-in service may include a sender for testing. Find out who can receive those messages before you connect a separate sender for customers.
Use a mailbox someone reads for replies. If your sender lets you set a Reply-To address, point it there. Set up incoming mail for your app only if the app needs to read replies itself. Keep a separate signup list for people who want your newsletter.
What do you need before the first send?
Pick the From address customers will see and check how your sending service confirms it.
For a sending domain, the part after the @ in the address, ask whoever manages it to add the exact records from your sending service. Wait for verification. Check account approval separately from the address or domain check.
Use the connection your app or sign-in service supports. An API is a way for your app to hand a message to the sending service. SMTP is the standard connection for outgoing mail. Keep the sending key in the app’s private server settings or the sign-in service, where visitors cannot see it.
Compare tools
Scroll the table sideways to read every column.
| Tool | Before customer sendingWhich address or domain you confirm, and whether the service must approve your account. | What the test provesWhether the test shows a delivery result or checks only how the request was put together. | What can stop sendingWhich activity counts and whether a day, month or trial period sets the limit. | Where to check a failureWhere to look up a message and which list explains why the service skipped an address. This is called a suppression list. | What you can keepWhich records you can retrieve before moving. A CSV is a file you can open in a spreadsheet. |
|---|---|---|---|---|---|
| Resend | Verify a sending domain you control before you use your own From address. | Designated recipients simulate delivery, a bounce or a complaint. | Transactional Free includes 100 emails per UTC day and 3,000 a month. Each recipient or received message counts. Simulated tests use the allowance too. On paid plans, sending pauses at the monthly quota or, with overages on, the overage limit. | Check email history and the team’s suppression list. Active Free, Pro and Scale accounts have a standard 30-day email and log history. | Download CSV files of email and log records. Team admins have seven days to download an export. Retrieve suppression entries separately. |
| Postmark | Confirm an individual From address or verify a domain. Account approval opens sending beyond the domains you verified. | A separate test setup called a Sandbox Server shows simulated delivery without sending to an inbox. | Free Developer includes 100 emails a month without overages. Outgoing messages, sandbox tests and copied recipients count. Incoming messages count when Postmark processes them. | Check Activity and Suppressions in the Message Stream, a group for one type of mail. Its default message and activity history is 45 days. | An Activity CSV holds up to 500 records. Export stream suppressions separately and recreate the sending setup in the new account. |
| Twilio SendGrid | Verify one From address to test. Authenticate a domain you control before sending customer mail. | Mail Send Sandbox checks the request format. It sends no message and uses no email credits. | The Email API trial includes up to 100 emails a day for 60 days. Sending stops at the end without an upgrade. Attempts to send to an address on the suppression list still use a credit. | Search Email Logs by recipient and send time. Its API covers up to 30 days. Older Activity Feed history depends on the plan. | The older Activity Feed exports up to one million events as CSV. Its add-on can extend the date range. Save templates and suppressions separately. |
How do you test a reset email without involving customers?
Request a reset from an isolated copy of your app. Start with the provider’s documented test, then send one real email to an inbox you control and finish the reset there.
For a real test with Resend’s default sender, use the email address on your Resend account. While Postmark reviews your account, choose a test inbox on a domain you’ve verified in Postmark. SendGrid’s single-sender verification lets you test from one confirmed address.
Before triggering a test purchase or replaying its notification, confirm that your test copy uses test payments and a test sender restricted to an inbox you control. Then trigger one test purchase and check whether replaying its notification sends a duplicate receipt.
- Isolate the app and the senderUse a test copy with its own sign-in setup and a disposable account. Confirm that customer data and the live app’s email settings are disconnected. Ask your builder to restrict test sends to the provider’s documented test addresses and the inbox you control. If you can’t confirm the separation, leave sending turned off.
- Check what the provider’s test provesTrigger the reset with the test connection and the sender and recipient the service allows. Compare the result with the table. A simulated delivery or a valid request shows the send reached a test checkpoint. You still need to check a real inbox.
- Follow one real messageUse a connection that can deliver mail from your test copy and confirm the recipient is the inbox you control. Request the reset again. Check the subject, open the link and confirm it goes to the test app before you change the disposable account’s password.
- Check that the link stops workingOpen the used link again and confirm it can’t reset the password a second time. Test a separate link after its expiry. Look for a clear way to request a fresh link from the test app.
- Test used and expired reset linksUse the recovery cases to check what happens after a reset email reaches your inbox.
What should you check if a message never arrives?
Trace one message using its recipient and approximate send time. Check whether your app tried to send it, what the sending service recorded, and whether the receiving mail server accepted it.
If your app shows no attempt, check what was supposed to trigger the send. If the service refused it, check the sender setup and the sending limit. If the receiving mail server accepted it, check junk or ask whether the mail service held it back before sending another copy.
A bounce reports that the message could not be delivered. The reason can be a bad address, a full mailbox, a refusal by the receiving mail service or trouble reaching it. Read the reason before retrying. Check the suppression list, which holds addresses the service skips for reasons such as a past bounce or complaint. Confirm the recipient’s address after a bounce. Keep complaint-related suppressions in place while you investigate.
How do you estimate a busy day?
Count who will receive the messages and which test or incoming messages use the same allowance. Check your busiest day and your billing month.
Suppose you send one message each to 90 customers and run 15 provider tests that day. If your plan counts each customer send and each test, you use 105 units. Check which tests count, when a trial ends and what happens at the limit before you depend on the service for password resets.
What should you save before moving to another service?
Keep the reusable message text and the values your app puts into it. Export the delivery records and skipped addresses you still need while the old history is available.
Keep customer addresses, old logs and exports where only the people who need them can see them. Leave reset links and passwords out of your app’s support notes. Check your saved purchase-to-receipt record before retrying an uncertain send.
Verify the new sending address and set up a new sending key. If your app accepts automatic delivery updates, check that each update really came from the new service before it changes a customer record. Try one controlled send and one failed-delivery case before moving customer mail.