It's tempting to treat an email that successfully lands in an agent's inbox as, by definition, legitimate — it arrived, so it must be fine. That assumption doesn't hold up. Neither of DimeBox's receive channels currently exposes SPF/DKIM/DMARC authentication results per message, and nothing marks a message's content as unverified before it reaches whatever an agent does with it next. The right default is to treat inbound email the same way you'd treat any other untrusted input to a program: assume it could be adversarial, and design accordingly.
For the free ordinary SMTP channel, it proves a third-party mail relay accepted the message and forwarded it — not that the from address is real, not that the sender is who they claim, and not that the content is safe to act on. Email's underlying protocol was never built with strong sender verification baked in by default; that's precisely why SPF, DKIM, and DMARC exist as bolt-on standards, and DimeBox doesn't currently surface their results per message. See SPF, DKIM, and Why Agent Email Needs Them Too.
For the paid priority channel, payment proves the caller paid three cents — it says nothing about whether the from field or body content is trustworthy either. Paying for delivery and being honest about who you are are two unrelated things.
This matters more for an agent than it would for a traditional inbox-processing script, because an agent often feeds message content directly into an LLM prompt to decide what to do next — summarize it, draft a reply, trigger an action. A message body is, in that context, not just data to display; it's text that's about to influence an AI's next decision. See Prompt Injection via Email: A Real Risk for AI Agents for exactly how that becomes a concrete attack surface, not just a theoretical one.
A few habits that cost little and close real gaps: never let inbound message content directly issue instructions an agent will blindly follow — treat it as data to reason about, not commands to execute. If a workflow takes action based on an email's content (sending money, modifying records, triggering another API call), add a layer of validation or confirmation between "email arrived" and "action taken," rather than wiring them directly together. And where sender authenticity actually matters for a given workflow, don't rely on the from field alone — build in an out-of-band way to confirm identity if the stakes justify it.
Every email system has this property to some degree — it's a property of SMTP and the open mail ecosystem generally, not a DimeBox-specific shortcoming. What's specific to agent email is that the thing reading the message is software making autonomous decisions, often fast, often without a human reviewing each one — which makes the cost of an unexamined assumption higher than it would be for a human skimming their inbox. See Designing APIs That Assume the Caller Is a Machine, Not a Human for the broader design philosophy this fits into, and Building an Agent That Triages Its Own Inbox for a concrete pattern that takes this seriously.