> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stackshift.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Configure email providers

> Use your own SMTP server or provider account for outbound email on projects and stacks, including BYOS connected-node workloads.

<Tip>
  **Live.** This area is documented as current, user-reliable behavior.
</Tip>

## Goal

Set up outbound email correctly without confusing user-owned provider credentials with StackShift platform email.

## Prerequisites

* An existing project or stack
* A real provider account or SMTP server you control

## Workflow

<Steps>
  <Step>
    Open the email-provider panel on the project settings page or stack detail page.
  </Step>

  <Step>
    Choose SMTP, Resend, Mailgun, Postmark, Amazon SES, or MailerSend.
  </Step>

  <Step>
    Enter your own provider credentials and sender details.
  </Step>

  <Step>
    Save the config, then run connection test and test email.
  </Step>

  <Step>
    Deploy or redeploy the workload so the injected env vars are applied to runtime.
  </Step>
</Steps>

## What this feature is and is not

* This is for the user’s own email provider credentials, not a shared StackShift sending account.
* It supports outbound email for workloads, not inbound mailbox hosting.
* It does not switch StackShift platform emails such as auth or notifications onto the user’s provider.

## Where it works today

* Projects, including GitHub-backed, Docker-image, hosted, and connected-node / BYOS project deploys
* Stacks, including raw Compose stacks and template-backed stacks
* Hosted and BYOS runtime placement both use the same provider model

## Supported providers

* SMTP
* Resend
* Mailgun
* Postmark
* Amazon SES
* MailerSend

## How runtime injection behaves

* StackShift injects provider env vars at deploy time.
* User-defined env vars still override collisions.
* Each project or stack currently has one managed provider config at a time.
* If the app needs a second mail path, add the extra credentials manually as normal env vars.

## Good SMTP test choices

* Use a real provider account such as Resend SMTP, Mailgun SMTP, Postmark SMTP, or Amazon SES SMTP.
* Avoid assuming Gmail SMTP is the best platform test path because it is often more restrictive and less predictable.

## Expected result

<Check>
  The workload can send outbound email through the user’s own provider account on hosted or connected-node infrastructure.
</Check>

## Common failures

<Warning>
  * SMTP host, port, or auth details are incorrect
  * Provider-side sender identity or domain is not verified
  * The workload was not redeployed after config changes
  * The app expects provider-specific env vars but is only coded for SMTP, or vice versa
</Warning>

## Related guides

<CardGroup cols={2}>
  <Card title="Project environment, domains, and previews" href="/projects/environment-domains-and-previews">
    Configure the project surfaces that most often decide whether a deployment works after it builds, including runtime shape, domains, previews, and storage.
  </Card>

  <Card title="Deploy a Docker image" href="/projects/deploy-a-docker-image">
    Run a raw container image through the project flow when you already have an image and need runtime configuration, resource sizing, storage, domains, and placement.
  </Card>

  <Card title="Deploy a Compose stack" href="/stacks/deploy-a-compose-stack">
    Bring a Compose-defined workload to StackShift with domains, placement, and persistent volumes.
  </Card>
</CardGroup>