Guides / Prompting and shipping

How to Send Emails from Your App (and Land in the Inbox)

Send emails from your app that arrive: transactional vs marketing email, choosing a provider, setting up SPF, DKIM and DMARC, and deliverability basics.

Mythex Team · 2026-09-29 · 7 min read

To send emails from your app reliably, use an email sending provider rather than your own mailbox, send from an address on your own domain, and add the DNS records the provider gives you so that SPF, DKIM and DMARC all pass. Keep transactional email — password resets, receipts, confirmations — separate from marketing email, send each only to people who expect it, and handle bounces and unsubscribes. Get the authentication right first; it is the most common reason app email lands in spam.

Transactional vs marketing email

These two kinds of email look similar in code but are treated very differently by inbox providers and by law.

Keep them apart. If a marketing campaign gets spam complaints, you do not want password resets from the same stream to suffer for it. A common approach is separate subdomains — for example mail.example.com for account email and news.example.com for newsletters — and some providers separate the two internally. Postmark, for instance, describes its transactional and broadcast "message streams" as running on separate sending infrastructure, as of September 2026.

Choosing a provider

Your app should not send email itself from its own server. Sending providers handle the infrastructure, IP reputation, retries and bounce processing. Well-known options include Postmark, Resend, SendGrid, Amazon SES and Mailgun; each has an HTTP API and SMTP access, and prices and plans change, so compare them on their own sites.

What to compare:

• Focus. Some providers concentrate on transactional email; others combine transactional and marketing.
• Developer experience. Clear API, official libraries for your language, useful logs showing whether each message was delivered, bounced or marked as spam.
• Webhooks for bounces, complaints and deliveries, so your app can react.
• Templates — stored with the provider, or in your own code. Keeping them in code makes them versioned and testable.
• Region and data handling, if you have requirements about where data is processed.
• Cost at your volume, including what happens when you exceed a free tier.

For newsletters to a list, a dedicated newsletter or email marketing tool is often a better fit than building campaign features into your app.

Set up your sending domain

Send from your own domain — hello@example.com, not a Gmail or Outlook address. Mail from a free mailbox address sent through a third-party service fails authentication checks and is likely to be filtered.

Consider a subdomain just for sending. Resend, for example, recommends sending from subdomains such as updates.example.com to isolate sending reputation (as of September 2026). It also keeps email DNS records separate from your main site's.

The provider then gives you DNS records to add at wherever your domain's DNS is managed. If DNS is new to you, how domains and DNS work explains records first.

SPF

SPF (Sender Policy Framework) is a TXT record listing which servers may send email for your domain. Receivers check whether the sending server is on the list.

• A domain should have only one SPF record. If you add a provider, merge it into the existing record rather than adding a second.
• SPF allows at most 10 DNS lookups when it is evaluated; long chains of include: entries can exceed it and cause failures.
• Many providers set SPF on a return-path subdomain they ask you to create, so you may not touch your main SPF record at all.

DKIM

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message. The provider signs with a private key; you publish the matching public key as a DNS record (TXT or CNAME, depending on the provider). Receivers check the signature to confirm the message came from an authorised sender and was not changed on the way.

DKIM is what your provider's "verify domain" step is mostly about. Do not skip it.

DMARC

DMARC ties the other two together. It is a TXT record at _dmarc.yourdomain.com that tells receivers:

• Alignment: the domain in the visible From address must match the domain that passed SPF or DKIM.
• Policy: what to do with mail that fails — p=none (just report), p=quarantine (treat as suspicious, often spam) or p=reject.
• Reports: where to send aggregate reports (rua=), so you can see who is sending as your domain.

A sensible path is to start with p=none and a reporting address, confirm your legitimate mail passes, then move to quarantine and eventually reject. A strict policy also makes it much harder for others to spoof your domain.

What Gmail requires

As of September 2026, Google's sender guidelines say:

• All senders to personal Gmail accounts need SPF or DKIM, valid forward and reverse DNS for sending servers, TLS, and a spam rate in Postmaster Tools below 0.3%.
• Bulk senders (more than 5,000 messages a day to Gmail) need SPF and DKIM, a DMARC record (a p=none policy is allowed), From-domain alignment, and one-click unsubscribe plus a visible unsubscribe link on marketing and subscribed messages.

Your provider handles the server-side parts. The DNS records and the unsubscribe handling are yours. Even if you are nowhere near 5,000 a day, meeting the bulk rules is the simplest way to be safe.

Build the sending into your app

Once the domain is verified:

1. Store the API key as a server-side secret — never in front-end code. See what environment variables and secrets are.
2. Send from the server, after the action that triggers the email succeeds.
3. Do not make the user wait on email. For anything beyond the simplest app, queue the send and retry on temporary failures, so a slow provider response does not slow down sign-up.
4. Log the outcome — the provider's message ID and status — without logging the key or full message bodies containing personal data.
5. Handle webhooks for bounces and complaints: stop sending to addresses that hard-bounce or mark you as spam.

A prompt that covers the basics:

Send transactional email with [PROVIDER] using the server secret [ENV_NAME], from "Acme hello@mail.acme.com". Send a welcome email after sign-up and a booking confirmation after a booking is saved. Keep templates in code, with a plain-text version alongside HTML. Queue sends and retry temporary failures up to three times. Log failures with the provider's error but never the API key. Add a webhook endpoint that marks addresses as undeliverable on hard bounces and complaints, and skip those addresses in future.

Account emails — verification links, magic links and password resets — are part of login. How to add login to your app covers how those flows fit together; make these links single-use and short-lived.

Deliverability habits

Authentication gets you considered. Behaviour keeps you in the inbox.

• Send only what people expect. Confirmed sign-ups, clear opt-in for marketing, no purchased lists.
• Make unsubscribing easy on anything that is not strictly transactional, and honour it straight away.
• Warm up new domains. A brand-new domain sending thousands of messages on day one looks suspicious. Start with your transactional mail and grow volume gradually.
• Keep lists clean. Remove hard bounces immediately and consider removing people who have not opened anything in a long time.
• Write like a person. A clear subject, a recognisable From name, a plain-text part, few images and links to your own domain. Avoid link shorteners.
• Monitor. Register your domain in Google Postmaster Tools and read DMARC reports now and then.
• Use a real reply-to that someone reads. Replies are a good signal, and useful feedback.

Testing without spamming anyone

• Use your provider's test mode or sandbox where it has one, or send to addresses you own.
• In development, send to a catch-all test inbox instead of real users; a seeded database full of real-looking addresses is an easy way to email strangers by accident.
• Check each template in a few clients — Gmail on the web, a phone mail app, Outlook — and in dark mode.
• Look at the message headers of a test email: they show whether SPF, DKIM and DMARC passed.

Legal basics

Rules differ by country. Broadly, marketing email needs consent in many places, must identify the sender, and must offer a working unsubscribe; transactional email is treated differently but should not be used to slip in marketing. If you collect addresses from a waitlist page, say what you will send and store when and how each person signed up. When in doubt, check the rules where your users are.

Email checklist

• Sending provider chosen; API key stored as a server secret
• Sending from your own domain or subdomain, not a free mailbox
• SPF, DKIM and DMARC records added and passing
• Transactional and marketing mail separated
• Sends queued and retried; outcomes logged
• Bounce and complaint webhooks handled
• Unsubscribe on non-transactional mail, honoured immediately
• Templates tested in several clients; test mail never reaches real users

Sending email from a Mythex app

Mythex does not include a built-in email sending service for the apps you build, so you bring a provider such as Resend, SendGrid or Postmark. Store its API key as a project secret — the agent can ask for it with a secrets card in chat — and ask for the emails you need in plain words. The docs have a starter prompt in send email from your app. If you bought your domain through Mythex on Pro, you can add the provider's TXT and CNAME records in the domain's DNS settings; see custom domains.