If anyone could claim any slug for $1.00, nothing would stop someone from claiming security@... or paypal@... and using it to send mail that looks exactly as official as the real thing. DimeBox blocks that at the name level, before a single message is ever sent, by permanently reserving two overlapping categories of slug.
System-looking names — slugs that look like infrastructure rather than a person or agent, such as admin, api, or www. These read as "part of the platform" to anyone who sees the address, which is exactly the impression a malicious claim would want.
Phishing-prone names — slugs that impersonate the words phishing campaigns already lean on hardest: support, hello, security, billing, verify, paypal, noreply, and others in the same family. An email from billing@... or security@... carries borrowed authority it didn't earn, regardless of who's actually sending it.
Both categories are rejected outright. It isn't a soft warning or a manual review queue — a reserved slug simply isn't claimable, full stop, by anyone, for any amount of money.
The check happens on POST /api/inboxes/claim, the paid route where you choose your own slug. If the name you request is on the reserved list, the call fails with a 422 and — importantly — nothing is charged. Reserved-name rejection happens before payment settles, in the same validation pass that checks whether the name is already taken or malformed. See claiming a custom inbox name for the full request flow this check is part of.
The free provisioning route, POST /api/inboxes, generates its own adjective-noun-number slugs automatically and doesn't take a requested name as input, so the reserved-name check isn't something you'd normally run into there — it exists specifically to stop someone from choosing one of these names on purpose.
DimeBox could, in principle, rely entirely on scrutinizing message content for phishing patterns after the fact. Reserving the names instead closes off a cheaper and more fundamental version of the same attack: the from-address itself is often the entire trick. A message from [email protected] still works on a lot of people even when the content is sloppy, because the address looks official at a glance. Blocking the name means that specific lie can't be told through a DimeBox address at all, independent of whatever's in the message body.
Reserved names stop a known bad word from being claimed in the first place. They're deliberately narrow — a separate mechanism stops something related but different: enumerating which already-claimed inbox slugs or messages exist by guessing or incrementing. Neither inboxes nor messages ever expose an internal row number for that reason; the only identifiers that come back are the slug itself and a message_id UUID, scoped to its own inbox. How DimeBox prevents inbox name enumeration covers that side of things.
Taken together, reserved names and enumeration resistance are both about the same underlying goal — making an agent inbox a poor tool for impersonation — approached from two different angles: one blocks the name before it's ever claimed, the other makes existing names and messages hard to discover by guessing. For the base mechanics of provisioning any inbox, free or named, see how to provision an inbox in one API call.
It would be simpler to let any claim through and deal with abusive ones after the fact. DimeBox doesn't do it that way for reserved names, because the harm from a phishing-shaped address isn't really about money changing hands — it's about the address existing at all, even briefly, with a borrowed-looking name attached. Checking before payment settles means a reserved name never becomes a real, sendable address for even a moment, rather than becoming one and then needing to be shut down after someone notices.
Blocking the obvious names doesn't block every phishing attempt — someone could still claim a near-miss variant that isn't on the reserved list but still reads as official in context. Reserved names close off the cheapest, most direct version of the attack, not every possible variation of it. Content-level scrutiny, and the general advice to treat inbound email as untrusted input, still matter on top of this, not instead of it.
The categories are narrow by design: system-looking infrastructure words and the specific terms phishing campaigns already lean on hardest, not a broad ban on any word that could conceivably be misused. That's a tradeoff — a narrower list is easier to reason about and less likely to block a legitimate agent name by accident, at the cost of not catching every address that might read as suspicious to a particular recipient.