Send Email From Your Deployed App

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

Send email from a deployed app through a server-side email provider, using a verified sender and runtime credentials. Record messages that the app owes its users, retry uncertain requests within the provider's rules and track delivery outcomes. An API response accepting a message is one checkpoint; receiving the message in a test mailbox is another.

Your lead form saves a submission and tells the visitor it succeeded. The notification then fails because production cannot reach the mail server. Keep the saved lead accessible to its owner and record the notification as pending. A lost email should leave a recoverable task attached to the submission.

Check the network

Choose an email transport that your production runtime allows and test it from the deployed application. Some hosts block outbound SMTP ports or require an HTTP proxy. An HTTPS sending API gives you another transport option, but the SDK still needs to honor the network configuration. Store the API key on the server and set a request timeout.

The runtime contract helps you check outbound access before editing templates. A client that works on your laptop may ignore production's proxy. Inspect connection failures and provider responses separately. For a public lead form, set the notification recipient on the server and rate-limit submissions so visitors cannot send arbitrary mail through your account.

Verify your domain

Verify a domain you control with the email provider before sending production messages from it. Add the DNS records the provider specifies and wait for its verification result. Use a sender within that domain. Website HTTPS and email sender verification are separate checks; making the app's public URL work does not authenticate its outgoing mail.

Resend's domain setup describes its SPF and DKIM checks. Follow its exact record names and values. For a lead form, keep From on your verified domain and put the validated visitor address in Reply-To. Test reply behavior and links using a mailbox you control; links should use the public address rather than localhost.

Track delivery

Track a message's local job ID, provider message ID and processing state. Record the pending notification with the saved business record so a restart cannot discard the obligation. Distinguish provider acceptance from delivery or a bounce. Give the owner a way to inspect failures without exposing message bodies or recipient addresses in public logs.

The background-job recovery pattern covers a worker stopping around an external effect. Reuse a stable key when the provider supports deduplication. Resend's idempotency contract retains keys for 24 hours; reconcile an uncertain request before retrying beyond that window. Keep the payload unchanged for matching retries.

Use provider delivery events or its dashboard to investigate a missing message. Resend's event definitions distinguish sending, delivery and failure. Delivery to a recipient's mail server does not prove the person read the message or that the server placed it in the inbox.

The FastAPI lead-form guide keeps the submission in PostgreSQL. Add notifications around that durable record. Display a status the application has verified; provider acceptance alone cannot establish that the email arrived.

Email check

Use a test form and a mailbox you control to check the deployed path before enabling customer notifications. Record both the saved submission and provider message ID. Include a timeout and a deployment while a notification waits to send. The result should let you find the lead, resume the notification and explain its delivery state.

EMAIL ACCEPTANCE CHECK
Sending provider and allowed transport:
Verified sender domain and runtime-secret name:
Server-controlled recipient and public link base:
Pending-message record and provider message ID:
Stable retry key, retention window and failure owner:

[ ] Deployed app reaches the provider through its network
[ ] Form saves the record before reporting success
[ ] Test mailbox receives the expected sender and links
[ ] Reply reaches the intended person
[ ] Timeout retry keeps the same message key and payload
[ ] Deployment preserves a pending notification
[ ] Bounce or failure remains visible to the owner

FAQ

Do I need to run a mail server? You can use an email provider's API from your backend. The provider handles mail transport; you configure the sender and implement access controls, notification records and failure handling in the application.

Does an email API's success response mean delivery? It usually means the provider accepted the request. Check its response and delivery-event definitions. Retain the message ID so you can investigate a bounce, delayed delivery or a missing message without sending a fresh copy by guesswork.

How should I send email on aidrop.it? aidrop.it allows outbound HTTP on port 80 and HTTPS on port 443 through its runtime proxy; standard SMTP ports are unavailable. Use an HTTPS email API with a proxy-aware client. Store its key as a Project secret and include its name in the Service's required_secret_names.