Team Mailbox on Your Own Domain: support@ and hello@ Addresses

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 Settings → Domains page you used to verify sending, and it requires that domain to already be verified:

Under Settings → Domains, find Receive email on this domain and hit Enable.
Add the MX record shown at your DNS provider — it points your domain at MailInApp's mail servers.
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.
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. You get 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. 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.

Drafts, undo send and scheduled send

Every message you write is saved as a draft while you type, so closing the composer or the tab loses nothing. Find unsent messages under Drafts in the Mailbox; a reply you started reopens under its own conversation. Drafts are yours alone: teammates don't see them. Drafts for a connected Gmail or Outlook account are kept in MailInApp, not in that account's own Drafts folder.

Undo send: after you press Send, the message waits a few seconds with an Undo button. Choose 5, 10, 20 or 30 seconds, or turn it off, under Mailbox settings → Sending.
Schedule send: the arrow next to Send offers tomorrow morning, Monday morning or a date and time you pick, in your own time zone. Scheduled messages wait under Scheduled, where you can edit one, send it now or cancel it. If one can't be sent, it stays there with the reason and a Retry button.
Reply all answers everyone on the message's To and Cc lines, leaving out your own addresses.
Templates are canned replies your whole team shares. Create them under Mailbox settings → Templates, then insert one from the template button in the composer. A template with a subject fills in an empty subject line.

Snooze, labels and assignment

Snooze a conversation from its row, the toolbar or a selection: later today, tomorrow, this weekend, next week, or a date and time you pick. It leaves the Inbox and waits under Snoozed, then comes back to the top of the Inbox, unread, at that time. A new reply brings it back early.
Labels are shared by your whole team. Create them from the Mailbox sidebar or under Mailbox settings → Labels, give each a color, and add or remove them with the Label menu (or press l on an open conversation). Each label has its own view in the sidebar, and a filter can apply one to new mail as it arrives.
Assign a conversation to a teammate who can see its address. They get an email and a push notification, conversations assigned to you gather under Assigned to me, and the list shows who each one is assigned to.

These work on mail to your own domain's addresses; messages from a connected Gmail or Outlook account don't have them. Viewers can see labels and assignees but can't change them.

Mia AI in the Mailbox

Mia AI helps you read and answer mail to your domain's addresses. It runs only when you ask, and nothing it writes is sent until you press Send.

Summary: a conversation with four or more messages has a Summary card at the top. Press Summarise and Mia sums it up in a few points, in your app language: what the correspondent wants, what has happened so far and what's still open. The summary stays, for your whole team, until a new message arrives.
Suggest replies: when the correspondent wrote last, Suggest replies offers three short answers in their language. Pick one to open it in a reply, change what you like, then send.
Write with Mia: in the composer, press Write with Mia and say in one line what to write, such as "decline politely, offer next week". Mia writes the text above your signature and the quoted message, in place of what you'd typed, and Undo puts yours back. A reply is written from the whole conversation, in the correspondent's language. This also works for new messages, forwards and replies from a connected Gmail or Outlook account.

Each of these uses one Mia AI turn from your plan's monthly allowance, the same one Mia uses in the studio. Owners and editors can use them; viewers see a summary someone else made. Mia reads incoming email as content, never as instructions, so a message can't make it do something else.

Reply or compose with an interactive email

Sometimes a reply needs more than formatted text — a poll, a product block, a countdown. Click ✨ Reply with interactive email on a thread instead of writing in the rich-text box (or ✨ Compose with interactive email from a new compose). This opens the full studio editor with the thread's context attached. 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 too. Both backends share one Mailbox UI, so the same shortcuts apply to connected IMAP accounts.

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.