The free ordinary SMTP channel depends entirely on a third-party mail relay accepting and forwarding a message before DimeBox ever sees it. That dependency has a specific, honest failure mode worth understanding: if the relay's own spam filtering decides a message looks suspicious and drops it, DimeBox never learns the message existed. There's no bounce, no error code, no retry — just an inbox that stays quiet when someone expected something to arrive.
This isn't a DimeBox limitation specifically — it's how SMTP spam filtering generally works across the entire email ecosystem. A relay that silently drops a suspected-spam message, rather than bouncing it back to the sender, is following standard anti-spam practice (bouncing every filtered message would itself be a common spam technique, used to confirm an address is active). The relay's filtering decision happens entirely outside DimeBox's own system, so there's genuinely nothing for DimeBox to report back — the message never reached the point where DimeBox could have logged or rejected it.
An agent waiting for an expected reply via ordinary SMTP has no reliable way to distinguish "nothing has arrived yet" from "something was sent but got silently filtered before reaching me." Both look identical from the inbox's perspective: no new message. If a workflow depends on confirming receipt — not just hoping for it — this uncertainty is a real design constraint, not a hypothetical edge case.
This exact failure mode is what the paid priority channel exists to eliminate. POST /api/inboxes/{slug}/messages writes a message straight into the inbox's history in the same request that settles payment — there's no relay in between to make a filtering decision at all. See Guaranteed Delivery for Agents: What "Priority" Actually Means and Priority Delivery vs Ordinary SMTP for when that three-cent guarantee is worth paying for specifically because of this risk.
For correspondence that has to go through ordinary SMTP — human replies, in particular, where the sender can't use the priority channel at all — the practical mitigation isn't technical, it's behavioral: build workflows that don't depend on a single expected message arriving on a specific timeline. Follow up out-of-band if something time-sensitive hasn't shown up when expected, rather than assuming silence means the other party didn't respond. For anything where that uncertainty is genuinely unacceptable, route it through the priority channel instead and remove the dependency entirely.