Sending from an address with no inbox.

Think about what actually leaves your domain in a week. Receipts, password resets, alerts, digests, onboarding sequences, the nightly report, the thing the agent sends when a job finishes. Now think about how many of those need to receive a reply. Usually none.

Yet the default setup gives each one a real mailbox, because that is how email has always been bought. It's worth questioning, because it's where a surprising amount of cost and risk sits.

A sending identity is not an account

A mailbox is a place mail is stored, with a password, an IMAP endpoint, a seat licence and a person notionally responsible for it. A sending identity is a verified right to put an address in the From header. They've been bundled together so long that the distinction sounds pedantic. It isn't.

Once a domain is verified with us, every address on it can send. Not five of them, not the ones you bought seats for. All of them. billing@, alerts@, no-reply@, reports@, one per customer if that is what your product needs, and none of them costs anything or exists anywhere as an account that can be signed into.

That last part is the security argument. An address with no mailbox cannot have its password phished, cannot be added to a mailing list, cannot quietly accumulate four years of invoices, and cannot be read by anything you connect to it. There's nothing to read.

Why this matters more now

Connecting an agent to your mailbox is the obvious move, and the wrong one. Read access to a mailbox is read access to password resets, contracts, board material and every conversation anybody has had. You're handing that to a process that writes and runs its own code, just so it can send a message.

It's a bad trade, because sending was the only part you wanted. Give the agent a scoped key against a verified domain instead. It can send as reports@yourdomain.com all day. It cannot read a single thing, because the address has no store behind it. That isn't a policy you have to configure and audit. It's just the shape of the system.

If you do want replies to go somewhere, set reply_to to a real address that a human or a helpdesk owns. The sending identity and the receiving one don't have to match, and separating them is usually the better design anyway.

What it takes

Verify the domain once. We give you the DNS records, or run the setup for you if your provider supports it, and you are done in a few minutes plus however long your DNS takes to propagate.

POST /emails
{
  "from": "Northwind Billing <billing@northwind.example>",
  "reply_to": "support@northwind.example",
  "to": "ada@customer.example",
  "subject": "Invoice 2026-0914",
  "html": "..."
}

No mailbox was created. No seat was bought. The address exists because the domain does.

Subdomains work the same way and are worth using. Send bulk from news.yourdomain.com and transactional from yourdomain.com, and a bad campaign cannot damage the reputation that your password resets depend on. It's the single most effective deliverability decision most teams never make, and it costs nothing.

Where the record lives

The objection to unattended addresses is usually accountability. If nobody owns the mailbox, who knows what went out?

The delivery log does, and it is better evidence than a sent folder. Every message carries which key sent it, which domain it left from, what the recipient's server said, and what happened afterwards. You can search it by recipient, which means the question "did this customer get their invoice" is a search rather than an archaeology project across several people's mailboxes.

For an EU workspace that record stays in Frankfurt, which tends to be the question that comes up about ten minutes after somebody asks the accountability one.

When you do need a mailbox

Anywhere a human is having a conversation. Sales, support, recruiting, anything with a thread. We don't receive mail, so that isn't a job we're competing for. Keep your normal provider for the people who read.

The point is only that those two things got bundled. Unbundling them removes cost, removes a class of credential, and gives your agents exactly what they need and nothing beyond it.