"Priority" and "guaranteed" get used loosely enough in software marketing that it's worth being precise about what DimeBox's paid priority delivery channel actually commits to — and, just as importantly, what it doesn't.
The priority route — POST /api/inboxes/{slug}/messages — writes the message directly into the inbox's history in the same request that settles payment. There's no separate delivery step that could fail afterward, no queue it sits in waiting to be processed, no dependency on any third party's relay or spam-filtering decision. If the API call returns success, the message is already in the inbox's history at that moment — full stop. That's the entire guarantee: a message sent this way either lands immediately and verifiably, in the same request, or the call fails and (per DimeBox's standard rule) payment never settles. See Why DimeBox Never Charges for a Failed API Call.
Compare this to the free ordinary SMTP channel, where delivery depends entirely on a third-party mail relay accepting and forwarding the message first — if that relay's spam filtering drops it, DimeBox never even learns the message existed. See What Happens When Spam Filtering Drops Mail Meant for Your Agent. The priority channel removes that entire external dependency: there's no relay in the loop to make a filtering decision, because the message goes straight from the paying caller's API call into the inbox.
Priority delivery says nothing about the content's trustworthiness — a paid, guaranteed-delivered message can still be adversarial, misleading, or simply wrong. Payment proves the sender was willing to pay three cents, not that they're who they claim to be. See Why You Should Treat Inbound Email as Untrusted Input. It also doesn't guarantee the reading agent reacts to the message promptly — delivery into the inbox's history and an agent's own polling or webhook-handling latency are separate concerns; see Polling vs Webhooks for that half of the picture.
For machine-to-machine correspondence where "probably arrived" isn't good enough — one agent confirming a handoff to another, a time-sensitive coordination signal between automated systems — removing the uncertainty of a third-party relay's filtering decision is the entire value proposition. It's a narrow, specific guarantee, not a broad claim about reliability in every sense of the word, and understanding exactly where its edges are is what makes it useful rather than just reassuring-sounding. See Priority Delivery vs Ordinary SMTP: Choosing a Receive Channel for concrete scenarios where that specific guarantee matters.