> ## Documentation Index
> Fetch the complete documentation index at: https://docs.verisoul.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Deliverability Risk

> Understand deliverability signals and decide whether to send to an email address

Every email analysis returns deliverability signals that help you decide whether it is safe to send to an address. The webhook payload includes two fields for this purpose: `send_recommendation` and `deliverability.risk_score`. This guide explains what each field means and how to use them.

## Two Fields, One Decision

The `deliverability` section of the webhook payload contains:

```json theme={null}
{
  "deliverability": {
    "risk_score": -1,
    "send_recommendation": "send"
  }
}
```

* **`send_recommendation`** is the primary decisioning field. It combines deliverability with other risk factors (such as disposable or impersonation domains) into a single, actionable recommendation.
* **`deliverability.risk_score`** is a narrower signal based on SMTP verification. Use it when you need more granular control over your send logic.

For most use cases, `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                      |

<Info>
  `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.
</Info>

## deliverability.risk\_score

The `deliverability.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                                              |

<Warning>
  A score around 0 means Verisoul was **unable to verify** the address — it does not mean the email is unsafe. Many emails that cannot be SMTP-verified (for example, those on catch-all domains) deliver fine in practice.
</Warning>

## Which Should I Use?

<AccordionGroup>
  <Accordion title="I want a simple rule to protect my deliverability">
    Use `send_recommendation` as your only filter:

    * **`send`** — safe to email
    * **`send_with_caution`** — you can still send, but expect some bounce risk
    * **`do_not_send`** — skip this address

    This is the recommended approach for most customers.
  </Accordion>

  <Accordion title="I want stricter deliverability filtering">
    Start with `send_recommendation`, then layer on `deliverability.risk_score` for tighter control:

    1. Exclude anything with `send_recommendation = "do_not_send"`
    2. Additionally exclude emails where `deliverability.risk_score > 0` to limit sending to addresses that are either confirmed deliverable or simply unverifiable

    Keep in mind that filtering on `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.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

## How Deliverability Affects the Overall Score

The `deliverability.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](/email-intelligence/webhook-reference) for the full list of fields.