The Send Decision Framework

Q: What's the difference between review and send_with_caution?

review means the evidence cannot confirm a specific mailbox at all — a catch-all domain, a protective gateway, or an unresolved unknown — and the address needs a human or an enrichment step before it's trusted. send_with_caution means the mailbox is plausibly deliverable but at moderate confidence (roughly 50-70), or it's a catch-all result evaluated under an aggressive policy that accepts more risk. The dividing line is whether the evidence points toward a real mailbox at all, versus how confident that evidence is.

Q: How do policies change the actions?

InboxPolicy's strictness setting (aggressive, default, or strict) shifts boundary cases without changing confirmed outcomes. Under the default policy, catch-all evidence maps to review. Under an aggressive policy, that same catch-all evidence maps to send_with_caution instead. Confirmed-undeliverable evidence still maps to avoid regardless of policy — only the ambiguous middle moves.

By Aria Pramesi, founder of InboxPolicy · Updated July 10, 2026

Most email verification returns a status you have to interpret: valid, invalid, catch-all, unknown. The Send Decision Framework skips the interpretation step. It's a model for turning verification evidence into one of five explicit actions, so a caller — human or agent — never has to decide what a status means for this particular send.

The Send Decision Framework is a model for email verification that returns an explicit action — send, send_with_caution, review, retry_later, or avoid — instead of a status label, so the caller never has to interpret evidence themselves.

Syntax validation, an MX lookup, and a live SMTP conversation produce the evidence. A deliverability policy then maps that evidence to exactly one of the five actions below, attaching a confidence score and the underlying evidence rather than leaving the caller to guess.

The five actions

send

Definition: the mailbox is verified with acceptable risk.
Evidence: SMTP confirmed the address, at confidence 70 or above.
What to do: send now. Nothing further to check.

send_with_caution

Definition: the mailbox is deliverable but at moderate confidence.
Evidence: confidence in the 50–70 range, or a catch-all result evaluated under an aggressive policy.
What to do: send if the campaign can tolerate some bounces. Not a hard block, but not a clean confirmation either.

review

Definition: the mailbox cannot be confirmed at all.
Evidence: a catch-all domain (default policy), a protective mail gateway, or an unresolved unknown.
What to do: queue for human review or an enrichment step. The evidence doesn't point toward a specific mailbox existing or not — it's genuinely ambiguous, not just uncertain.

retry_later

Definition: a temporary SMTP condition, not a verdict on the mailbox.
Evidence: greylisting or a transient server issue.
What to do: re-check later — the re-check is usually free. Treating this as a permanent failure would throw away an address that's probably fine.

avoid

Definition: do not send.
Evidence: confirmed-undeliverable or high-risk — an invalid mailbox, bad syntax, or a disposable domain.
What to do: drop the address. No policy setting moves evidence out of this action.

Why actions instead of statuses

A status field describes what a verifier saw. It doesn't say what to do next, and two people reading the same status can reach different conclusions about whether an address is safe to send to. The Send Decision Framework moves that judgment call into the verification step itself, so the same evidence always resolves to the same action. The full argument for why that matters — and where status fields still make sense — is in Send-Decision API vs Email Verification API.

Policies

A policy setting shifts the boundary cases without ever changing a confirmed outcome. InboxPolicy exposes this as a strictness parameter (aggressive, default, or strict). Under the default policy, catch-all evidence maps to review — the mailbox genuinely can't be confirmed, so it goes to a human or an enrichment step. Under an aggressive policy, that same catch-all evidence maps to send_with_caution instead — the caller has decided that accepting more bounce risk is worth skipping the review queue.

What a policy never does is move confirmed-undeliverable evidence into send. An invalid mailbox is avoid under every policy setting; only the ambiguous middle — catch-all, mostly — moves between review and send_with_caution. This is the caveat that keeps every claim about "review" or "send_with_caution" honest across the rest of this site: which action a catch-all result gets depends on the policy in effect, not on the framework itself.

The framework in practice

Three places show the framework operating on real evidence rather than described in the abstract:

The send-decision benchmark runs 40 scenarios across nine categories through the framework, pairing a ground-truth expected verdict with the action InboxPolicy actually returns — including where they disagree. The raw scenarios are also available as a downloadable dataset.
The API returns the framework directly: every POST /v1/decide call responds with an action field set to one of the five values, plus confidence and evidence.
Email list cleaning applies the framework to list hygiene — segmenting a list by action (send, caution, review, retry-later, suppress) instead of deleting everything that isn't a clean valid.

For the mechanics of catch-all specifically, see the catch-all email verifier guide.

Frequently asked questions

What is the Send Decision Framework?

The Send Decision Framework is a model for email verification that returns an explicit action — send, send_with_caution, review, retry_later, or avoid — instead of a status label, so the caller never has to interpret evidence themselves. Syntax, MX, and live SMTP evidence feed a deliverability policy, and that policy resolves to one of the five actions plus a confidence score and the evidence behind it.

What's the difference between review and send_with_caution?

review means the evidence cannot confirm a specific mailbox at all — a catch-all domain, a protective gateway, or an unresolved unknown — and the address needs a human or an enrichment step before it's trusted. send_with_caution means the mailbox is plausibly deliverable but at moderate confidence (roughly 50–70), or it's a catch-all result evaluated under an aggressive policy that accepts more risk. The dividing line is whether the evidence points toward a real mailbox at all, versus how confident that evidence is.

Why does retry_later exist?

Because greylisting and similar transient server conditions are not permanent facts about a mailbox — they're a request to try again after a delay. Folding a greylisted result into avoid would permanently give up on an address that's probably fine; folding it into review would route something time-based into a queue meant for evidence that's genuinely ambiguous. retry_later exists because the correct response, waiting and re-checking, is different from both.

How do policies change the actions?

InboxPolicy's strictness setting (aggressive, default, or strict) shifts boundary cases without changing confirmed outcomes. Under the default policy, catch-all evidence maps to review. Under an aggressive policy, that same catch-all evidence maps to send_with_caution instead. Confirmed-undeliverable evidence still maps to avoid regardless of policy — only the ambiguous middle moves.

Can other tools use the Send Decision Framework?

Yes. The framework is a describable model — five actions mapped from evidence — not a proprietary format, and the benchmark dataset that operationalizes it is released under CC BY 4.0. Any verifier can adopt the vocabulary and return the same five actions. InboxPolicy is its reference implementation, not its only possible one.

See the framework in the API — get started →