Receive email on your domain

Note: Inbound mailbox is available on every plan, on top of an already-verified native sending domain — metered by monthly volume and number of named addresses, both scaling by tier. See pricing for each tier's allowance.

Once you've verified a domain for native sending, MailInApp can also receive real email at named addresses on it — [email protected], [email protected], whatever you choose — viewable and repliable from Mailbox in the dashboard. No forwarding rules, no separate mail server to run.

This works alongside native inbox rendering & IMAP sync inside the same Mailbox at /dashboard/mailbox: you can manage custom domain inbound mail and connected external IMAP accounts in one place.

Enable it

Inbound receiving is a toggle on the same Sending domain card in Settings you used to verify sending, and it requires that domain to already be verified:

1. Under Sending domain, find Receive email on this domain and hit Enable.
2. Add the MX record shown at your DNS provider — it points your domain at MailInApp's mail servers.
3. The toggle confirms itself once your first real message arrives; there's no separate verification check the way DKIM/MAIL FROM have one, since MX has no equivalent API.
4. Add one or more named addresses (e.g. support, sales) below the toggle — these are the local-parts MailInApp will accept mail for and show a label on in the dashboard. Mail to an address you haven't claimed still arrives and is stored, just flagged unassigned rather than dropped. The number you can claim scales by plan — see pricing.

Reading, replying & organizing

/dashboard/mailbox lists every thread, filterable by address, with unread state and attachment downloads. Replying from a thread sends through your own native-sending setup, correctly threaded (In-Reply-To/References) so it lands as a reply in the sender's own mail client — not a new, disconnected message.

• Compose a brand-new thread to any address, not just replies to inbound mail — pick which of your claimed addresses to send as from the same "Send as" picker connected IMAP accounts use.
• Archive or trash a thread (and move it back to Inbox anytime) instead of only marking it read/unread.
• Star a thread to flag it for follow-up.
• Attach files on a reply or new compose, and download any attachment on a message you received — both directions now show as downloadable chips in the thread.
• Cc and Bcc are available on every reply and new compose.
• Search is a real server-side query, not just a filter over what's already loaded — it matches a thread's subject/participant/preview first, falling back to a full message-history scan when needed.
• Signature: set one account-wide default (Mailbox sidebar → Signature) inserted above quoted text on every reply and compose, across every address you've claimed.
• Filters: under Mailbox sidebar → Filters, set rules like "from/subject contains X → mark read / flag / move to Archive / move to Trash," evaluated automatically as inbound mail arrives.

Rich text replies

The reply and compose boxes are a full rich-text editor, not a plain textarea: bold, italic, underline, strikethrough, H2/H3 headings, bullet and ordered lists, blockquotes, links, a small fixed set of text-color swatches, and basic tables (insert, add/remove row or column). Formatting round-trips both ways — your own sent messages render with full formatting in the thread view, and formatted mail from the other side renders safely too, sanitized and (for anything outside the known-safe allowlist) shown in a sandboxed frame the same way connected IMAP messages already are.

Sending still falls back cleanly: every reply carries a plain-text part alongside the HTML, so recipients on a text-only client see a readable equivalent.

This is the domain mailbox's version of it — replying to a message from a connected Gmail/Outlook account gets the same rich-text editor and attachment support, just without the new-compose case (that stays plain text for a connected account).

Reply or compose with an interactive email

For a reply that needs more than formatted text — a poll, a product block, a countdown — click ✨ Reply with interactive email on a thread (or ✨ Compose with interactive email from a new compose) instead of writing in the rich-text box. This opens the full studio editor with the thread's context attached, so you can pick an existing project or start a new one, make last edits, and send it as this specific reply.

A few things behave differently for a studio-sent reply:

• It's sent as a transactional email: no unsubscribe footer, no "open interactive version" line, and no open-tracking pixel — appropriate for a one-to-one reply rather than a bulk campaign.
• Interactions on it (poll votes, form submits, clicks) are recorded anonymously/rate-limited rather than attributed to a contacts-list row, the same way an HTML export or unbound live-view link is.
• The thread view marks the message Sent using: <project name> and shows the mailed HTML in a sandboxed frame, with a link back into the studio editor to reopen or resend it.

A connected IMAP account has this too, on replies — same ✨ button, same transactional behavior. The one difference: there's no "Sent using" badge or thread history there, since connected-account messages are never stored server-side to begin with.

Bulk actions (select multiple threads, then Archive/Delete/Mark read/unread together) and keyboard shortcuts (j/k to navigate, e to archive, # to delete) work here the same way they do for connected IMAP accounts — both backends share one Mailbox UI.

Subdomain vs. root domain

By default, a verified domain gets a dedicated subdomain identity — mail.yourdomain.com — so sending and receiving through MailInApp coexist safely with whatever else you already run on yourdomain.com (Google Workspace, Outlook, your own mail server). Addresses look like [email protected].

When you first connect a domain, you can instead check Use the root domain instead of a subdomain to get plain addresses like [email protected]. This only makes sense for a domain that isn't used for any other email:

• Sending from the root domain carries no extra risk — DKIM records just live at a different name.
• Receiving on the root domain is different: the MX record inbound mail needs points the entire domain's mail delivery at MailInApp. If yourdomain.com currently has mail flowing anywhere else — a real inbox provider, another tool's MX — enabling inbound receiving on a root-domain identity replaces that entirely. MailInApp requires an explicit confirmation before enabling inbound receiving on a root-domain identity for exactly this reason; a subdomain identity has no such risk and needs none.

If you're unsure, use the default subdomain — you can always claim more addresses on it later, and it never touches mail you're already receiving elsewhere on the domain.