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

# Validation Results

> How Relaybase classifies and scores an email address

Every validation request returns a classification, a deliverability score, and a set of signals that explain the result.

## Classifications

Relaybase classifies each email into one of three states:

<CardGroup cols={3}>
  <Card title="Valid" icon="circle-check">
    The email passes the relevant validation checks and is considered likely deliverable.
  </Card>

  <Card title="Invalid" icon="circle-xmark">
    The email fails a fundamental validation check, or is rejected by the receiving mail server.
  </Card>

  <Card title="Risky" icon="triangle-exclamation">
    The email isn't conclusively invalid, but Relaybase found something that means you should proceed with caution.
  </Card>
</CardGroup>

### Invalid

Common reasons an email is classified as `invalid`:

* Invalid syntax
* Domain without valid MX records
* Disposable email domain
* SMTP rejection from the receiving mail server

### Risky

Common reasons an email is classified as `risky`:

* Catch-all domains
* Greylisting from the receiving mail server
* Role-based addresses (e.g. `support@`, `admin@`)
* SMTP verification that couldn't conclusively confirm the mailbox

## Deliverability score

Alongside the classification, Relaybase returns a `score` from 0–100:

Relaybase calculates this deliverability confidence score using multiple signals, including email syntax, domain configuration, disposable-domain detection, role-based classification, provider characteristics, and SMTP verification when applicable.

<Note>
  The score is a confidence signal, not a guarantee of delivery. Even an email scoring 100 can't guarantee that a message will actually be delivered — mailbox state can change after validation, and receiving servers can still reject a message at send time.
</Note>

The score and the `status` classification are related but not derived from a fixed threshold — status is based on the underlying validation conditions, not simply "score above X equals valid." Don't build logic that assumes a specific score range maps to a specific status; always check the `status` field directly.

## Response fields

| Field           | Description                                                       |
| --------------- | ----------------------------------------------------------------- |
| `is_valid`      | Whether the email passed validation overall                       |
| `status`        | One of `valid`, `invalid`, `risky`                                |
| `score`         | Deliverability confidence score, 0–100                            |
| `syntax_valid`  | Whether the email address is syntactically valid                  |
| `mx_valid`      | Whether the domain has valid MX records                           |
| `is_disposable` | Whether the domain is a known disposable email provider           |
| `is_role_based` | Whether the address is role-based (e.g. `support@`, `info@`)      |
| `is_free`       | Whether the domain is a free email provider (e.g. Gmail, Outlook) |
| `catch_all`     | Whether the domain accepts mail for any address (catch-all)       |
| `smtp_code`     | SMTP response code from mailbox verification, when available      |
| `reason`        | Human-readable explanation of the result                          |
| `suggestion`    | A suggested next step or interpretation of the result             |

## Validation depth

You can control how thorough a single validation request is with the `mode` field: `fast`, `medium`, or `deep`. Lighter modes return faster; deeper modes run more thorough checks, including SMTP verification.

See [Validate an Email](/api-reference/email/single-validation) for how to set this on a request.