Detecting AI agent mailboxes

An AI agent’s mailbox is perfectly deliverable. Every verifier on the market will tell you it is valid, and every one of them is right. None of them will tell you a human is never going to read it.

The question SMTP cannot answer

Email verification answers one thing: will a message to this address be accepted. That was sufficient when every accepted address belonged to a person. It is not sufficient now that a growing share of deliverable mailboxes belong to scheduling agents, support bots, inbox assistants and automation platforms.

The failure is quiet, which is what makes it expensive. Nothing bounces. Your deliverability metrics look fine. Sends go out, get accepted, and produce no reply, and the only symptom is a conversion rate that drifts down for reasons nobody can attribute.

actor_class

Every Sortance response carries an actor_class alongside the bounce probability, because who is behind a mailbox and whether mail lands there are different questions and collapsing them into one score loses the one you needed.

Value	Means
`human_mailbox`	A person reads this.
`agent_mailbox`	Software reads this. It delivers, and no human sees it unless the software escalates.
`relay_alias`	Forwards to a real address you do not have. Apple Private Relay, Firefox Relay, and every catch-all forwarder.
`role_account`	info@, sales@, support@. Deliverable, shared, and rarely the right cold target.
`shared`	A mailbox several people work out of.
`unknown`	Not enough signal. Said plainly rather than guessed.

Classify, never block

There is deliberately no bot and no blocked member in that list. Sortance reports what an address looks like; what to do about it is your policy, made with your context. A signup product and an outbound team want opposite things from the same classification.

What it looks like

{
  "email": "assistant@nova-agents.ai",
  "verdict": "likely_valid",
  "bounce_probability": 0.04,
  "confidence_interval": [0.02, 0.09],
  "calibration": "prior",
  "recommendation": "send",
  "actor_class": "agent_mailbox",
  "mailbox_type": "corporate",
  "esp": "google_workspace",
  "email_type": "business",
  "providers": {},
  "disagreement": 0.0,
  "cache": { "hit": true, "ttl_s": 604800 },
  "cost_usd": 0.0,
  "latency_ms": 9
}

Note providers: {} and cost_usd: 0.0 — this one resolved from cache without reaching a paid provider at all. The classification is not something you pay extra for.

What teams do with it

Outbound. Suppress agent_mailbox and role_account from cold sequences. Both deliver, and neither is a person deciding whether to reply.
Signup and trial abuse. An agent_mailbox or relay_alias at signup is not fraud, but it is a different risk profile — a good reason to require a second factor rather than to reject.
Attribution. Segment reply rates by actor_class and the drift stops being mysterious.
Deduplication. For relay aliases, identity_hash gives you a stable key across several aliases pointing at the same person — salted per account, so it can never become a cross-customer identifier.

What this does not do

It does not identify which agent, or who operates it, and it will return unknown rather than guess when the signal is not there. It is a classification with the same uncertainty discipline as the rest of the response — see limitations.