"The agent sent an email" sounds like one step. Underneath it, several separate pieces of infrastructure each have to do their job correctly: a drafting step that turns a brief into actual words, a queue that accepts the send request and does the SMTP work later, DNS records that let a receiving mail server trust the message isn't forged, and a payment gate that decides whether the call is even allowed to proceed. None of that is specific to AI — it's the infrastructure any email product needs — but it's easy to lose sight of when the headline is "an agent sent an email" rather than "a queue, a relay, and a few DNS records worked correctly together." Most of it is invisible by design, which is exactly why it's worth naming once, even briefly, before trusting any of it blindly.
Sending mail over SMTP is slow and occasionally fails for reasons that have nothing to do with the sender — a receiving server is briefly unavailable, a message needs a retry. Queuing the send instead of blocking on it is why a send call returns 202 Accepted immediately rather than making the caller wait on that round trip: the paid API response and the actual mail delivery are two different events, checked separately by polling the message list afterward, watching a status field move from queued to sent or failed — the same list that answers any other question about a mailbox's history, paginated and scoped to one inbox.
For mail to land anywhere other than a spam folder, the sending domain needs SPF and DKIM configured correctly — records that tell a receiving server "yes, this message claiming to be from this domain really was sent by infrastructure that domain authorized." None of this is optional, and none of it is visible to the agent making the API call; it's infrastructure the platform has to get right once, on behalf of every inbox it ever provisions, rather than something each agent configures for itself.
Receiving works the other direction through a third-party mail relay that accepts mail addressed to the inbox domain and forwards it in — the same role a mail server plays for any ordinary mailbox. That relay runs its own spam filtering before a message ever reaches DimeBox, which is mostly invisible and mostly helpful, except when it isn't: a legitimate message an agent was waiting for can be dropped upstream, with nothing on DimeBox's side ever seeing it to prove delivery was attempted. That's part of why a separate priority channel exists, to let a sender bypass that dependency entirely for messages that can't afford to be silently filtered.
Polling a message list is the simplest way to notice new mail, but it isn't the only one. A webhook URL set at provisioning time turns "new mail arrived" into a pushed, signed POST instead — another piece of infrastructure that has to get a few details right on its own: delivering the request, signing it with a secret shown once at setup, and giving the receiving agent something it can verify before trusting the payload rather than acting on an unsigned request from the open internet. It's one more example of the same pattern — a capability that looks like a single flag in a request body (webhook_url) but is actually its own small piece of infrastructure behind that flag.
Every piece above sits behind the same mechanism on paid routes: a 402 challenge, a signed payment, a facilitator verifying and settling it, and only then the actual work — drafting, queuing a send, or writing a priority message into history. Using the same gate everywhere, rather than a bespoke check per route, is what keeps the payment logic itself from becoming one more hidden piece that behaves differently depending on which endpoint you call. Skipping that gate on any single route would mean a quieter, harder-to-notice class of bug: a free action that was supposed to be paid, discovered only when someone notices the paid total doesn't match what actually happened.
None of this infrastructure is something a caller needs to configure — that's the point of a managed inbox instead of self-hosting the equivalent. But knowing it's there changes how you debug a message that didn't arrive, or decide whether a delay is a bug or just mail being mail. "The agent emailed someone" is a one-line summary of a process with several independent points where something can be slow, dropped, or rejected, long before an AI model is involved at all. See how the two receive channels actually work for the rest of that picture.