Email's original design has no built-in way to verify a message's from address is genuine — anyone can put anything in that field. SPF and DKIM are the two standards the broader email ecosystem built to close that gap, and they matter just as much for an AI agent's inbox as they do for a human's, arguably more.
SPF (Sender Policy Framework) lets a domain publish a list of mail servers authorized to send on its behalf. A receiving server can check whether a message claiming to be from example.com actually came from a server example.com has authorized — if not, that's a signal the from address may be spoofed.
DKIM (DomainKeys Identified Mail) is different: the sending server cryptographically signs parts of the message, and the receiving server can verify that signature against a public key published by the claimed sending domain. Unlike SPF, which checks the sending server's identity, DKIM verifies the message content itself hasn't been tampered with in transit and genuinely originated from a server holding the right private key.
A human looking at a suspicious email has years of accumulated, if imperfect, skepticism — odd phrasing, an unfamiliar sender, a request that doesn't fit context. An AI agent processing a message programmatically doesn't have that instinct unless it's deliberately built in, and even then, it's reasoning about content, not verifying authentication signals. If an agent acts on a message's claimed sender without any authentication check at all, it's trusting a field anyone could have written to say anything.
To be direct about it: neither of DimeBox's receive channels currently exposes SPF/DKIM/DMARC authentication results on a per-message basis. A message's from field is whatever the sender claimed, unverified, the same way it would be for any plain SMTP inbox without additional tooling layered on top. This is explicitly called out in Why You Should Treat Inbound Email as Untrusted Input as a reason to treat all inbound content as unverified by default, not as a hidden gap to discover later.
Where sender authenticity genuinely matters for a specific workflow — confirming a payment instruction, acting on a sensitive request — don't rely on the from field alone, regardless of which email provider is involved. Build an out-of-band verification step for anything where being wrong about the sender has real consequences: a shared secret included in the message body by prior agreement, a separate confirmation channel, or simply treating any action-triggering email as a prompt for further verification rather than a command to execute immediately. See Prompt Injection via Email: A Real Risk for AI Agents for the sharpest version of why this matters, and Building an Agent That Triages Its Own Inbox for a pattern that takes sender uncertainty seriously by design.