Prepare a Resend domain and sending key

Resend’s starting prerequisites are a verified domain and an API key. Choose an application domain/subdomain before connecting code so the integration does not accidentally replace employee mailbox routing.

Complete setup

1. Add your domain in Resend and select the offered sending configuration.
2. Publish the exact domain-authentication records from its dashboard. Keep existing mailbox MX records unless receiving is part of an approved routing change.
3. Wait for verification, then create a key with the narrow permissions/domain scope required by the application.
4. Store the key in your backend secret manager and distinguish production and development connections.

The default onboarding/test-sender path has restrictions. Do not treat a successful test address as permission to send arbitrary production traffic from an unverified domain.

Validate the deployment

Run one controlled SDK send and confirm its log entry and recipient. A successful outbound test does not establish inbound delivery; receiving requires its own domain and webhook configuration.

Keep transactional messages separate from Broadcast/contact-list workflows. API access does not remove recipient-consent or suppression obligations. If a DNS check fails, compare record names at your authoritative DNS provider before regenerating credentials.

MailKite domain verification is independent. Switching between the two services means verifying the application domain and changing the explicit delivery path, not sharing API keys.

Source: Resend introduction and prerequisites.