send_recommendation and deliverability.risk_score. This guide explains what each field means and how to use them.
Two Fields, One Decision
Thedeliverability section of the webhook payload contains:
send_recommendationis the primary decisioning field. It combines deliverability with other risk factors (such as disposable or impersonation domains) into a single, actionable recommendation.deliverability.risk_scoreis a narrower signal based on SMTP verification. Use it when you need more granular control over your send logic.
send_recommendation is all you need.
send_recommendation
| Value | Meaning | When it triggers |
|---|---|---|
send | Safe to send | The email is confirmed deliverable or has no adverse deliverability signal |
send_with_caution | Some bounce risk | The email has uncertain deliverability (unknown SMTP status, mailbox full, or risky status), or the overall risk_score is very high |
do_not_send | Do not send | The email is confirmed invalid, is a no-reply address, or the domain is disposable, invalid, or an impersonation |
send_recommendation accounts for more than just SMTP results. An email on a disposable domain will return do_not_send even if the mailbox technically exists, because disposable addresses are short-lived and poor targets for outreach.deliverability.risk_score
Thedeliverability.risk_score ranges from -1 (deliverable) to 1 (not deliverable). The table below shows roughly where scores land and what they indicate:
| Score range | Interpretation |
|---|---|
| Around -1 | Confirmed deliverable — SMTP verification succeeded |
| Around 0 | Unable to verify — the mail server did not provide a definitive answer (e.g., catch-all domains, rate-limited servers) |
| Around 0.5 | Uncertain — SMTP status is unknown or the mailbox is full |
| Around 0.75 | Likely undeliverable — SMTP verification returned a risky status |
| Around 1 | Not deliverable — the email is confirmed invalid or is a no-reply address |
Which Should I Use?
I want a simple rule to protect my deliverability
I want a simple rule to protect my deliverability
Use
send_recommendation as your only filter:send— safe to emailsend_with_caution— you can still send, but expect some bounce riskdo_not_send— skip this address
I want stricter deliverability filtering
I want stricter deliverability filtering
Start with
send_recommendation, then layer on deliverability.risk_score for tighter control:- Exclude anything with
send_recommendation = "do_not_send" - Additionally exclude emails where
deliverability.risk_score > 0to limit sending to addresses that are either confirmed deliverable or simply unverifiable
risk_score > 0 will exclude emails where SMTP verification was inconclusive. Many of those addresses are perfectly deliverable — this approach trades some reach for lower bounce rates.I only care about overall fraud risk, not deliverability specifically
I only care about overall fraud risk, not deliverability specifically
Use the top-level
decision and risk_score fields instead. Deliverability is already factored into the overall risk assessment, so you do not need to check deliverability separately.How Deliverability Affects the Overall Score
Thedeliverability.risk_score is one of several sub-scores that feed into the overall risk_score returned in the webhook. An undeliverable email will push the overall score toward risk, while a confirmed-deliverable email contributes a trust signal.
The overall risk_score also incorporates breach history, email age, domain reputation, username patterns, and (when enabled) identity intelligence. See the Webhook Payload Reference for the full list of fields.