Sending email
If your app needs to send email — sign-up confirmations, password resets, notifications — you can create an email service. The Deployer handles the fiddly, technical parts of becoming a trusted sender so your messages actually arrive instead of landing in spam.
What an email service sets up for you
Sending email reliably means proving to the internet that you're allowed to send from your domain. That normally involves configuring several DNS records (DNS is the internet's address book that connects a domain name to services). The Deployer creates them for you:
- DKIM — a digital signature that proves the mail really came from you.
- SPF — a record listing who's allowed to send on your behalf.
- DMARC — a policy that ties DKIM and SPF together and tells receivers what to do with anything that fails.
You don't need to understand these to use them — you just need to let The Deployer add them (or add them at your DNS host if it tells you to).
Choose a provider
Email services are available on two providers:
- AWS SES (Simple Email Service)
- Azure Communication Services (ACS) Email
Google Cloud and DigitalOcean don't offer a native email product, so the wizard will honestly mark email as unavailable there and suggest using AWS or Azure instead.
Creating an email service
Follow the usual create-a-service wizard and choose the Email category. On the Configure step you'll see one extra field — a sending domain — with a few options:
- Pick a domain whose DNS is already on this cloud connection. If The Deployer already manages the domain's DNS, it writes the DKIM/SPF/DMARC records automatically — nothing for you to do.
- Enter any domain and let The Deployer create its DNS zone. Tick the box to create a DNS zone on the provider; you'll get nameservers to set at your domain registrar, exactly like connecting a custom domain to a deployment.
- Enter a domain and add the records yourself. Leave the box unticked and The Deployer shows you the records to paste into your existing DNS host.
- Skip the domain. On Azure, you get a ready-to-use managed subdomain that can send immediately. On AWS, you can add individual verified sender addresses later from the service page.
Verification, then sending
After creation, the service page shows the DNS records and a verification status. Verification is fail-closed — the service only flips to verified once the provider itself confirms the records are live and correct. DNS changes can take anywhere from minutes to a few hours to propagate, so if it's still "verifying", give it time and check back.
You also manage sender identities here — the specific addresses your app is allowed to send from.
Getting out of the "sandbox" (AWS SES)
New AWS SES accounts start in a sandbox that can only email pre-verified addresses. Setting up DKIM/SPF/DMARC does not lift this — it's a separate, account-level approval. The Deployer automatically requests production access for you when it can; AWS typically reviews the request within about a day. If needed, you can re-request it from the service page.
On Azure ACS, there's no sandbox, but brand-new resources start with default sending-rate limits. Raising those is done through an Azure portal request; the service page explains this where it applies.
How your app then sends mail
Once the email service is ready, attach it to your project. The Attachment Doctor wires the sending settings into your project's environment variables — the SMTP details (SMTP is the standard way apps send email: a host, port, username, and password) plus a "from" address for SES, or a connection string for Azure ACS. Your app reads those and sends mail as usual. As with every service, these values are stored encrypted, and the Attachment Doctor sees only the setting names, not the values.