DimeBox gives an agent inbox two distinct ways to receive mail, covered in full in How AI Agents Receive Email: Two Channels Explained. This post is about the practical question that follows: which one should a given message actually use?
Free, universal, and requires nothing special from the sender — any person or system that can send a normal email can reach a DimeBox inbox this way. For human replies, newsletter-style inbound, or any correspondence where the sender has no reason to know or care that DimeBox is involved, this is the only realistic option, and it's the right one by default.
Ordinary SMTP delivery depends entirely on a third-party mail relay actually accepting and forwarding the message first. If that relay's own spam filtering flags a message and drops it, DimeBox never sees it — there's no visibility into that decision and no way to override it after the fact. See What Happens When Spam Filtering Drops Mail Meant for Your Agent for what that failure mode actually looks like from the receiving agent's side (mostly: silence, with no error to catch).
The paid route — POST /api/inboxes/{slug}/messages, $0.03 — writes a message straight into the inbox's history in the same request that settles payment. There's no relay in the middle to drop it, no spam heuristics to second-guess the sender, no dependency on any decision outside DimeBox's own API. If the call succeeds, the message is in the inbox, full stop. See Guaranteed Delivery for Agents: What "Priority" Actually Means for the precise scope of that guarantee.
A few concrete scenarios where the three cents is clearly worth paying: one autonomous agent notifying another that a task is complete, where a dropped message means the receiving agent silently waits forever with no way to know something was sent. A time-sensitive handoff between services where "probably delivered" isn't good enough. Any machine-to-machine correspondence where the sender is already paying for other DimeBox actions and values certainty over saving three cents.
Human correspondence, by definition — a person replying from their own email client isn't going to construct an x402 payment. Low-stakes or non-time-sensitive inbound, where an occasional dropped message isn't costly. And anything where the sender simply isn't DimeBox-aware — most of the internet's email infrastructure doesn't know or care that x402 exists, and that's fine; ordinary SMTP is built for exactly that case.
Nothing stops a single inbox from receiving through both channels over its lifetime — a support inbox, for instance, might take ordinary human replies via SMTP while other automated systems in the same pipeline use priority delivery for guaranteed handoffs. Both land in the same message history, read the same way. See Reading a Mailbox's History for how to tell them apart once they're there.