How should email-service credentials be configured during deployment?

How should email-service credentials be configured during deployment?

Email-service credentials should be configured through the production deployment's secret mechanism and read only by the server component that sends mail. They should not appear in browser code, source control, screenshots, or diagnostic output.

For a wedding application, email may support invitations, verification, or account recovery. Inventory which messages the current release actually sends before configuring the integration.

Provision credentials for the sending task

Use a production credential with the permissions needed by the application. Where supported, restrict it to sending from the relevant domain instead of granting broad account administration.

For example, Resend supports API-key permissions and optional domain restrictions. Its API-key documentation explains those controls. Other providers have their own permission models and setup requirements.

Store the value under the exact variable name the server code reads. Use separate development and preview credentials or controlled test behavior.

Configure the sender and message links

A working API key does not automatically establish permission to send from any address. Verify the intended sender domain according to the provider's instructions. Resend's domain documentation describes its verification requirement.

Set the approved sender address, reply behavior, and the application origin used in invitation links. A correctly delivered invitation is still broken if its acceptance link points to localhost or an unrelated preview.

Deploy and verify delivery behavior

Apply the configuration to the production environment and create a deployment that includes it. On Vercel, updated variables affect new deployments. The environment-variable guide documents this behavior.

Send a controlled test message to a designated recipient. Check provider acceptance, message delivery evidence, sender identity, and the complete link journey. Provider acceptance alone does not guarantee inbox placement.

Handle failures without exposing credentials and avoid duplicate invitations during retries. Record safe operational information such as message identifiers so failures can be investigated without logging private tokens.