← Blog/Email
Temporary mailboxes for inbound email testing
Get a temporary @mercur-mail.com inbox in Mercur. Inspect inbound messages, download attachments, and optionally forward parsed JSON to an HTTP endpoint.
Signup codes, magic links, and inbound hooks should not land in a personal inbox.
Mercur now ships workspace Mailboxes: a temporary mailbox on @mercur-mail.com
so you can test inbound email the same way you already inspect webhooks.
This post covers what shipped, who can create an address, typical uses, and the limits that stay out of v1.
What shipped
Mailboxes live in the console as their own workspace section. They are not a new tunnel protocol and they do not count toward endpoint quota.
Each mailbox gets a generated address in the shape
mb-{workspace}-{id}@mercur-mail.com. You cannot pick a custom local-part.
The address is the product: paste it into a provider, a staging app, or a
script that must deliver mail.
Open a mailbox to inspect inbound mail: headers, parsed body, raw MIME, and downloadable attachments. That is enough when you only need to confirm what arrived. Messages follow the same retention window as request logs.
Optionally bind the mailbox to an existing HTTP endpoint. Mercur then POSTs
email.received JSON to that endpoint’s public URL — parsed fields and
attachment metadata, not file bytes. Treat it as email to HTTP for an app that
already handles webhooks. A failed forward does not drop the copy stored in
the mailbox.
On Solo and Team, Remote MCP can list those mailboxes and open parsed messages the same way it already lists HTTP request history. The tools are read-only: summaries first, then one message (headers, text, html, attachment names). No raw MIME and no file bytes. There is still no public REST mail API.
Inbound only. Mercur does not send or reply. Delete a mailbox and that address is never reissued, including to the same workspace. The next mailbox gets a new id. Retired addresses keep returning SMTP 550, the same as unknown ones.
Who can use it
Temporary mailboxes are included on paid plans. Guest mode and the free plan cannot create them. The public webhook tester stays HTTP-only; a mailbox is a persistent workspace address, not a throwaway guest URL.
- Solo — 1 mailbox, 10,000 emails per month, 8 MiB per message
- Team — 3 mailboxes, 50,000 emails per month, 16 MiB per message
- Guest / Free — none
Team members share workspace mailboxes. Extra addresses after a downgrade stay visible but stop accepting mail until you upgrade or delete them.
See Pricing for the full catalog.
What you can use it for
Use a disposable inbox whenever a provider must deliver email and you need to see what arrived — without sharing your real address.
Signup, verification, and magic links. Point the app at the mailbox, trigger the flow, and read the message in the console. You can confirm the code or link without filtering a personal inbox.
Password reset and transactional templates. Confirm subject lines, links, and attachments before you wire the same mail into staging. Raw MIME is there when HTML and text parts disagree.
Inbound-email products. Support parsers, ticket ingest, and “email us a
receipt” flows can hit @mercur-mail.com instead of standing up MX records
during development. Keep the handler local; let Mercur accept the message.
Third-party “send us email” fields. Keep vendor sandboxes off a personal inbox. Unknown local-parts are rejected with SMTP 550, so only addresses you created accept mail.
Email to HTTP. If the app already handles webhooks, optional JSON forward turns the next inbound message into another event on the same public URL. Inspect first; attach an HTTP endpoint when the handler is ready. File bytes stay in the mailbox download, not in the JSON body.
Inspect from the IDE. With a workspace API key, ask an MCP client to call
list_mailboxes → list_messages → get_message instead of pasting the
console into chat. Same Solo/Team gate as Remote MCP for tunnels.
What it is not
Mailboxes are a receive-only test inbox, not a customer mail platform.
- No send, reply, or SMTP credential for outbound mail
- No guest tester and no mailbox without an account
- No custom local-part or catch-all
- No public REST mail API; MCP is read-only (no create/delete, no attachment bytes)
- Not a replacement for production inboxes your users already own
Deleted and unknown addresses stay rejected. Do not treat a mailbox as a long-lived identity for customers.
Start using Mailboxes
Sign in on Solo or Team, open Mailboxes, and create one. Copy the
@mercur-mail.com address into the provider or app you are testing. You can
name the mailbox and change JSON forward later in its settings.
Leave forward unset if you only need to inspect. Attach an HTTP endpoint when
you want email.received JSON on the same URL you already use for webhooks.
To inspect from Cursor or another MCP client, create a workspace API key and
use the existing remote MCP server — see Remote MCP.
Open Mailboxes
On Free, upgrade first — Pricing lists which plans include a temporary mailbox.
FAQ
Which plans include a temporary mailbox? Solo includes one. Team includes three. Guest and Free include none. Monthly email caps and MIME size follow the same plans.
If JSON forward fails, do I lose the message? No. Mercur stores the mailbox copy first. Forward runs afterward. A failed POST does not delete the inspected mail.
Can I reuse an address after I delete the mailbox?
No. Local-parts are never reissued. Delete frees a quota slot; the next
mailbox gets a new @mercur-mail.com address.
Can an agent read mailbox mail over MCP?
Yes, on Solo and Team, with the same workspace API key as HTTP history.
get_message returns parsed content and attachment metadata, not file bytes.
Related
Create a temporary mailbox
Compare plans