Some questions can only be answered by the actual email. A receipt from a
supplier, a one-time code, a bounce notification, a message someone insists you
sent them. Pasting it into a chat window loses the headers, mangles the
encoding, drops the attachments, and cannot answer a question about
authentication at all.

A **temporary inbox** solves that. Your agent mints an address on a SendOps
receiving domain, tells you where to forward the message, and collects it when
it lands. Ten minutes later the address stops resolving and everything it
received is deleted.


  Temporary inboxes are being enabled organization by organization. If you do
  not see the **Verified senders** card on your profile yet, the feature has not
  reached your organization.


## What it is not

This is a narrow tool and most of its value comes from what it refuses to be.

- **It is not a mailbox.** It lives for minutes, there is no folder to browse,
  and nothing is kept.
- **It is not an address for signing up to third-party services.** A restricted
  inbox only accepts mail from addresses you have proved you read, so it cannot
  receive a stranger's signup confirmation. That is deliberate.
- **It is not in your AWS account.** Unlike everything else SendOps does, this
  address receives through SendOps' own infrastructure, on a SendOps domain. It
  costs you nothing in AWS and appears nowhere in your SES console.
- **It never sends.** Nothing can be sent from a temporary address, ever. No
  replies, no bounces, no auto-replies, no delivery notices, for any reason.
- **It is not [Inbound Receiving](/inbound/inbound-receiving).** Inbound is your
  own receiving setup: a subdomain you own, an MX record you publish, a webhook
  that keeps delivering, all in your account. A temporary inbox borrows an
  address of ours for a few minutes. The parsed payload is the same shape, which
  is why a temporary inbox is a good way to prototype against inbound, but the
  lifetime and the ownership are nothing alike.

## How your agent uses it

You do not create these yourself. The flow belongs to an agent connected over
[MCP](/ai-agents/mcp-server) or to code calling the
[Public API](https://developers.sendops.dev/api-reference/inboxes), and it has
three steps.

1. **The agent mints an address.** It gets back something like
   `k7q2m9xv4p@sndps.com` and an expiry time.
2. **It tells you where to forward.** A well-behaved agent says both halves:
   *"Forward it to `k7q2m9xv4p@sndps.com` — it expires at 14:32."* An address
   handed over without an expiry is one you will try to use tomorrow.
3. **It collects what arrives.** The agent waits, and gets the message as
   structured data: the sender, the subject, the text and HTML bodies, every
   attachment, and the SPF, DKIM and DMARC verdicts the receiving side recorded.

The lifetime is yours to choose within limits. Ten minutes is the default, one
minute is the floor, and one hour is the ceiling. The ceiling exists because the
promise is "then it is gone", and a promise measured in hours turns the feature
into a mailbox with a worse privacy story.


  What you forward is stored by SendOps for the lifetime of the inbox, then
  deleted. Attachments are handed to your agent as time-limited links that stop
  working when the inbox expires. Do not forward something you would not want
  stored at all, and do not treat this as a way to keep mail away from your own
  organization.


## Verify a sender, once

An inbox that only accepts mail from addresses you have verified is
**restricted**. Mail from anyone else is dropped silently. That single fact is
what makes the feature safe to hand to an agent, and it is also what makes it
practical:

**A restricted inbox is not rationed.** It does not count against the minting
quota or the per-person cap on active inboxes, because it cannot be used to
collect mail from strangers. An unrestricted inbox is metered; a restricted one
is the path the design wants you on.

### In the dashboard

Go to **Profile → Verified senders**.

- **Add address** opens a dialog. Type the address, and SendOps emails it a
  six-digit code.
- Enter the code to finish. You get five attempts against one code before it
  locks; **Send a new code** starts again.
- A row that says **Code sent** is waiting on you. **Enter code** reopens the
  dialog.
- The remove button on a row revokes an address. Revoking does **not** unrestrict
  inboxes that already exist — the allowed-sender list is frozen when the inbox
  is minted, and the guarantee it made then still stands.

You need the **Use inboxes** permission to see this card at all.

### Over the API

The same two steps exist as endpoints — request a code for an address, then
confirm it — documented at
[developers.sendops.dev/api-reference/verified-senders](https://developers.sendops.dev/api-reference/verified-senders).

## What a restricted inbox actually checks

**It matches the sender address, and nothing else.** The check compares the
`From:` header address and the envelope sender against the allowed list, and
either one matching is enough. An entry written as a whole domain matches that
domain exactly, never as a suffix.

**It does not require SPF or DKIM to pass.** That is a decision, not a gap: a
restricted inbox is a convenience filter over an address that lives for minutes,
not an authentication boundary.

So "it arrived" means "it came from that address", which is not proof of who
sent it. When it matters — a payment notice, anything you are about to act on —
read the SPF, DKIM and DMARC verdicts that ride along with every message. Your
agent has them.

## Quotas and caps

Two different things are limited: how often you can mint, and how many can be
live at once.

| Limit | Organization with AWS connected | Organization without |
|---|---|---|
| Mints per hour | 30 | no hourly limit |
| Mints per day | 200 | 3 |
| Active inboxes per person or API key | 5 | 5 |
| Active inboxes per organization | 25 | 25 |

The split is about who bears the cost of abuse. A connected organization is
receiving through infrastructure it pays for. An unconnected one is spending
ours, so three a day is enough to try the feature and far too few to run a
disposable-address service on.

An organization without AWS connected has no hourly window on purpose: three a
*day* is the whole limit, and an hourly window would tell someone to come back
in an hour when the truth is tomorrow.

Restricted inboxes skip the minting quota and the per-person cap entirely. The
25-per-organization cap still applies to them, because that one is not an abuse
control — it bounds one organization's footprint on a shared receiving pipe,
which does not care why a message arrived.

## Who can see an inbox

Every inbox is **private** by default: only the person or key that minted it can
read it, plus anyone holding the manage-all permission for inboxes. Everyone
else is told it does not exist rather than that they are not allowed — saying
"forbidden" would confirm the address is real, which is the one thing a private
inbox is trying not to do.

An inbox can be minted as **org**-visible instead, which lets any member with
the **Use inboxes** permission read it. That is how you hand one forwarded
message to a colleague without handing over your account.

## My forward never arrived

Work down this list. Each step is cheap and rules out a layer.

**Has it expired?** This is the commonest answer by a distance. The default
lifetime is ten minutes, and the conversation that produced the address often
takes longer than that. After expiry the address stops resolving and the content
is already deleted; your agent will be told the inbox has expired rather than
that nothing arrived. Ask for a new address and forward again.

**Did you forward from the address you verified?** On a restricted inbox, a
forward from a *different* account of yours is dropped with no bounce and no
notice — a rejection notice would be a message we deliver to whoever the sender
claimed to be. The tell is the inbox's **dropped count**: if it has gone up and
no message arrived, something reached the address and was refused. Forward from
the address you verified, or mint a new inbox that allows the one you are
actually using.

**Was it a virus scan or a spam scan?** These are treated differently on
purpose. Mail that fails the **virus** scan is dropped and never appears. Mail
that fails the **spam** scan is delivered anyway, with the verdict attached —
transactional mail forwarded through a consumer mailbox trips spam heuristics
easily, and the agent waiting for a one-time code is better placed to judge that
than we are.

**Nothing at all, and the inbox is live with a dropped count of zero?** Then
nothing has reached the address yet. Check the address for a typo, and check
that your mail client sent the forward rather than leaving it in drafts.

## Related pages

- [Connect an AI agent](/ai-agents/mcp-server) — the MCP connection an agent
  needs before it can mint anything
- [Inbound Receiving](/inbound/inbound-receiving) — the other, permanent kind of
  receiving, in your own AWS account
- [Settings & Profile](/team/account-settings) — where the Verified senders card
  lives