Sending Email
Many apps eventually send confirmations, password resets, receipts, digests, or notifications. The agent scaffolds Resend when the feature needs email. Connect it from the connectors surface inside that project; other projects remain separate.
Why Resend
- Straightforward API and domain-verification workflow; check Resend's current plans and limits.
- A documented domain-verification and delivery-status workflow. Inbox placement is never guaranteed, so monitor bounces and complaints.
- A straightforward way to prove control of the domain you send from.
- React-based email templates the agent can edit like any other screen.
If you're already on SendGrid, Postmark, or Mailgun, the agent can generate a best-effort backend integration from official documentation. Never give it a key in chat. Put a dedicated minimum-permission credential directly in the deployed mail backend's secret manager.
The setup prompt
"Send a welcome email when a new user verifies their email. Keep it short and friendly. Use Resend, and send it from hello@myapp.com."
The agent can generate:
- A React email template (
emails/welcome.tsx) and preview-safe app states. - A narrow backend route contract that renders and sends the template.
- Review-first trigger or webhook setup for the appropriate event.
- A
SETUP REQUIREDchecklist to deploy the backend, verify the domain, and add a separate sending key directly to its secret manager.
Domain setup (do this before users arrive)
Before your first real email goes out, verify your sending domain. This establishes the DNS authentication Resend requires for that identity; unverified or misconfigured mail can be rejected or filtered.
- In the Resend dashboard, add your domain (e.g.,
myapp.com). - Resend gives you the DNS records required for that domain. Publish every record exactly at the DNS provider that hosts the domain.
- Wait for DNS propagation; timing varies by provider and record TTL.
- Click "Verify" in the Resend dashboard.
With a dedicated Full access connector key and Account access turned on, the agent can register the domain and return the DNS records for you to add manually. A Sending access connector key is authentication-only and cannot expose that action. The agent cannot mint or reveal any API key. Create a separate scoped runtime Sending access key yourself and add it directly to the deployed mail backend's secret manager. An eligible domain action appears in the connector's AI activity feed.
Don't skip this. An unverified or misconfigured sending identity can be rejected or fail authentication and harms deliverability.
Tip: use a subdomain like mail.myapp.com instead of the bare myapp.com. If something ever goes wrong with email deliverability, it won't affect your main domain.
Email templates
The agent can generate React Email templates that compile to HTML. Email clients render HTML differently, so test the resulting message in every client that matters to your users.
// emails/welcome.tsx
export function WelcomeEmail({ name }: { name: string }) {
return (
<Html>
<Body style={{ fontFamily: "system-ui", padding: 24 }}>
<Heading>Welcome, {name}</Heading>
<Text>Thanks for creating an account. Here's how to get started...</Text>
<Button href="https://myapp.com/start">Get started</Button>
</Body>
</Html>
);
}You can preview every template locally with npx react-email dev.
Common email flows
Welcome email
Triggered on email verification. Short, warm, one clear CTA.
Password reset
Supabase can send its own authentication emails. If you want custom Resend delivery or templates, configure the Supabase email provider and templates explicitly; connecting Resend does not change auth email settings automatically. See Authentication.
Magic link log-in
For passwordless auth. Configure the provider, redirect URLs, and template explicitly; the connector alone does not enable it.
Receipt / confirmation
For any transaction. Include order number, itemized amount, and support contact.
Weekly digest
A batched email summarizing activity. Usually a scheduled function that runs once a week, queries the database for the user's recent activity, and sends a digest to each active user.
"Send each user a weekly digest every Monday morning summarizing their habit streak, any new comments on their posts, and their progress toward goals."
Transactional but sensitive
For account changes: password change confirmations, new device alerts, data deletion confirmations. Short, factual, no marketing content.
From-address best practices
- Use a from address allowed by your verified sending domain and current provider policy.
- Use different addresses for different types of mail:
hello@myapp.com. Welcome, onboarding.notifications@myapp.com. Activity, digests.security@myapp.com. Security alerts, password resets.billing@myapp.com. Receipts, subscription events.- Set a Reply-To if replies should go somewhere other than your From. For example,
Reply-To: support@myapp.com.
Unsubscribe handling
If you send anything that isn't strictly transactional, you need an unsubscribe flow. Ask the agent to generate and then verify:
- Adds a List-Unsubscribe header (Gmail and Apple Mail respect this; it creates a native "Unsubscribe" button).
- Stores unsubscribe state in the user profile.
- Suppresses future non-essential email to anyone who unsubscribed.
Transactional email (password reset, billing receipt) can legally go without unsubscribe in most jurisdictions, but digests, promotions, and product marketing require it.
Inbound email (receiving email)
Resend can receive mail too, so the agent can turn an incoming email into an action in your app.
"When a user emails support@myapp.com, create a support ticket in our Supabase database and send an auto-reply acknowledging receipt."
Ask for it and the agent can generate the inbound route, verification logic, and deployment checklist. You deploy the route, configure the exact Resend inbound settings and DNS records, and place any runtime credential directly in the backend's secret manager.
Rate limits
Check Resend's current plan, sending, and rate limits before launch. Add your own throttle on top: for example, cap a digest at once per 24 hours per user.
Testing
Before sending to real users:
- Follow Resend's current testing-domain and permitted-recipient guidance for your account.
- Send to addresses you control first. Check in multiple clients (Gmail web, Apple Mail on iPhone, Outlook on Windows). What looks good in one can break in another.
What to watch
- Spam complaints. Configure and monitor the provider's current logs or event/webhook path. Investigate complaints promptly and stop sending to recipients who did not expect the message.
- Bounces. Confirm the provider's current bounce and suppression behaviour, then ensure your application does not repeatedly send to known invalid recipients.
- Domain reputation. Follow the provider's current ramp-up, consent, and reputation guidance instead of sending a sudden large campaign from a new domain.
Next
Read Maps & Location for location-aware features.