Email that reaches the inbox

Email from a new domain lands in spam unless the receiving server can check it really came from you. Launchpad sets up the sending side, and prints the DNS records that prove it.

Turn it on

"services": { "email": { "domain": "mail.example.com" } }

A subdomain such as mail.example.com is a good choice: trouble with marketing mail then doesn't affect your main domain's reputation.

On the next deploy, Launchpad:

1. creates the domain in Resend;
2. creates a send-only API key scoped to it, so a leaked key can't read or manage your account;
3. injects RESEND_API_KEY and EMAIL_FROM into your app;
4. lists the DNS records to add, or adds them for you when your DNS is on Cloudflare.

The DNS records

Resend asks for three kinds, and all three matter:

• DKIM signs each message, proving it wasn't altered.
• SPF says which servers may send for your domain.
• DMARC tells receivers what to do when a message fails those checks.

Until they're in place and verified, Resend won't send from the domain. The deploy keeps the task on its Still to do list, so running it again tells you where you are.

Sign-in emails

With Supabase sign-in, turning on email makes Supabase send its sign-in links through your Resend domain instead of Supabase's shared, rate-limited sender. That's the difference between a magic link arriving in two seconds and arriving in spam, so turn email on before testing sign-in with real people.

Replies

A sending domain doesn't receive mail. If people may reply, either:

• add an MX record so the domain has an inbox (Google Workspace, Zoho, Cloudflare Email Routing), or
• set a reply-to address on a mailbox you already read.

The launch check flags a sending domain with no inbox.

Checking it worked

• The deploy's log lists the records and whether Resend has verified them.
• Resend's dashboard shows each message and what happened to it.
• Send yourself a test, then look at the message's headers: DKIM, SPF and DMARC should all pass.