Keep Preview Deployments Away From Live Email Recipients

Prepare and review creative in Migma, but make the application’s environment decide whether that email can reach a real recipient. A preview deployment should not inherit permission to contact a live audience merely because an AI app builder successfully installed an email integration.

Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 10, 2026.

Resend’s September 8, 2026 v0 integration announcement describes creating an account, adding an API key to project environment variables, configuring DNS, and managing billing through v0. It requires a Vercel-purchased domain. The documented default sender is restricted to testing; the guide instructs users to switch to their verified domain before sending to users.

The setup can therefore move from a constrained test identity to a usable production identity. Treat that transition as an explicit recipient-reach decision.

Sketch the environment map before changing the sender#

For a fictional language-learning app, the Migma welcome email is the same reviewed creative in three environments. The audience and delivery permissions are not the same:

These are proposed choices. “Preview” is a deployment label, not an email safety mechanism. The application must enforce the restriction before it calls the provider. A prompt telling an agent to use test contacts is not equivalent to a server-side recipient check.

Use distinct configuration records where practical. Store credential values only in the intended secret mechanism; the review document needs the credential’s logical name and environment scope, not its value.

Test the recipient path that would otherwise escape#

Make the preview app attempt its normal welcome-email action using an address outside the test allowlist. The expected result is a clear application rejection before any provider send request. Do not use an unconsenting third party as the negative test target. Use a controlled address that the policy deliberately excludes and verify the call boundary through application instrumentation.

Then submit an approved test address. Confirm one expected email arrives and that the receipt belongs to this preview deployment, not another developer’s earlier attempt. Include a non-sensitive deployment identifier in internal logs. Do not add debugging data that reveals credentials or personal contact history to the visible message.

Repeat after changing a branch-specific setting. Vercel documents separate environment scopes and branch-specific preview overrides. A passing test on one branch does not prove another branch uses the same configuration. New environment-variable values also need the appropriate new deployment; changing a settings screen is not evidence that the running build has changed.

Keep the creative transfer narrow#

Migma’s export workflow lets a team download reviewed HTML for another email tool. Use that artifact as the creative input to the application. Record which HTML version the app packages and which system resolves its variables.

The application still owns recipient admission, send triggering, error handling, and environment selection. A Migma preview cannot verify those controls. Conversely, a successful provider API request does not prove the exported email’s content, links, or language are correct.

For the language app, the first fixture might be a welcome email for a synthetic learner named Mina. A second fixture omits the name. Both should use the reviewed fallback copy. The environment experiment then asks a separate question: can either fixture cause the preview to send beyond the allowlist?

Promote configuration deliberately#

Before activating the production welcome flow, read the deployed configuration’s logical sender identity and environment. Confirm that the domain setup is complete in the provider’s documented surface, rather than relying on an agent’s narrative that DNS “should be ready.” Do not copy a working preview credential into production by reflex.

Run the controlled production activation through the actual signup path using an authorized test account. Keep its receipt and deployment version. If the production workflow fails, diagnose configuration, application triggering, and recipient eligibility separately. Disabling preview restrictions is not a repair for a broken production setup.

If credentials have already been exposed in client code or logs, handle that as a separate credential incident under the provider’s rotation procedure. This article does not prescribe a new provisioning service or install any integration.

The boundary to keep visible#

The useful question is not “did the builder connect email?” It is “which deployed code can send to which recipients with which identity?” Retain that answer with the release so a future preview change cannot silently broaden reach.

No v0 project, domain, API key, or email send was created during this research. The release behavior and environment controls are vendor-documented. For content-side validation, use personalization fallback tests; for identity preparation, use the sending-domain rollout guide.