mailinapp
Documentation menu

Native sending

Note: Native sending is available on every plan, including Free — it's metered by monthly volume, not gated behind an upgrade. See pricing for each tier's allowance.

Besides your own SMTP relay, MailInApp can send directly from a domain you verify with us — no ESP, no SMTP credentials to generate and rotate. Delivery runs on our infrastructure (Amazon SES) against your own sending domain, so recipients see mail from [email protected], not a shared MailInApp address.

Verify a domain

Under Settings, the Sending domain card walks you through it:

  1. Enter your domain and hit Verify domain. By default MailInApp creates a sending identity for mail.<yourdomain> and a bounce-handling subdomain (bounce.mail.<yourdomain>) — a dedicated subdomain that coexists safely with any other email you already run on the root domain. If you'd rather send from the root domain directly ([email protected], not [email protected]), check Use the root domain instead of a subdomain — only do this if the domain isn't used for any other email; see Receive email on your domain for why this matters more once inbound receiving is involved.
  2. Add the DNS records shown — a handful of DKIM CNAME records, an MX and a TXT record for the bounce subdomain, and a starter DMARC TXT record — at your DNS provider. These prove you control the domain and let mail sent through it pass DKIM/SPF checks.
  3. Hit Check now once you've added them, or just wait — MailInApp polls automatically every 15–30 minutes.
  4. Once both the domain and the MAIL FROM subdomain show Verified, a toggle appears to switch your account's sending method to native sending.

Switching back to SMTP is always available and instant — it doesn't disconnect the domain, so you can toggle between the two without re-verifying.

DMARC

DMARC tells inboxes what to do with mail claiming to be from your domain but failing SPF/DKIM — reject it, send it to spam, or (the default we generate) just monitor. It's the one record here MailInApp can't verify automatically the way it polls DKIM and MAIL FROM status — there's no API for it, so it's shown for you to add but never shows a Verified/Pending badge.

The record we generate ships as p=none (monitor-only) deliberately — it won't affect delivery on its own. Once you've confirmed nothing legitimate is failing (most DNS providers, including Cloudflare, will show you DMARC aggregate reports if you add your own rua=mailto: address to the record), tighten the policy to p=quarantine and eventually p=reject at your DNS provider.

What doesn't change

Manual sends, scheduled sends, lifecycle emails (order/ticket notices) and the transactional Send API all go through whichever sending method your account is set to — there's no separate configuration per feature. Suppression, send history, interaction tracking and responses all work identically regardless of which method delivered the mail.

Sandbox mode

While your account is in the SES sandbox, native sending only reaches addresses you've separately verified with us — it's meant for testing your own delivery before we request production access on your behalf. Your Settings card always shows a plain-language notice while sandbox mode applies.