Your SES can report every message as [accepted](/reports/accepted-vs-arrived) while a provider files it in junk. The **Deliverability Score** brings together the things that decide where your mail lands, so you can see a problem before your recipients do.

You'll find it at the top of **Reports → Deliverability**. Pick a sending domain to see its score.

## What the score is

Each sending domain gets:

- **A score from 0 to 100.** Higher is better.
- **A band**: Healthy, At risk or Failing. See [Bands](#bands).
- **Five sections of named checks.** Every check shows what was measured, the threshold it was held to, and where the reading came from.
- **A list of tasks.** Every check that fails comes with one task that says what to fix and where. See [Tasks and where you do them](/reports/deliverability-score/tasks).

### When it updates

SendOps scores every sending domain **nightly at 05:40 UTC**.

You can also click **Re-check** to score a domain right away, for example after you fix something. You can re-check a domain up to **6 times an hour**. Re-checking and running an [authentication check](/reports/deliverability-score/authentication-check) both need permission to manage domain authentication.

## The five sections

| Section | What it looks at | Passing means |
|---|---|---|
| **Authentication** | Whether receivers can tell your mail really comes from you: domain verification in SES, DKIM signing, your DMARC record, and what a real receiver saw. | Every message is signed as your domain, and receivers can verify it. |
| **Reputation** | How mailbox providers and AWS judge your sending: bounce rate, spam-report rate and your SES account's standing. | Few bounces, few spam reports and an AWS account in good standing. |
| **Provider requirements** | The rules Gmail, Outlook and Yahoo set for high-volume senders. | You meet every rule of each provider you send enough mail to. See [Provider requirements](#provider-requirements). |
| **List hygiene** | Whether your lists stay clean: suppression list growth, sends to suppressed addresses, and whether people open your mail at every provider. | Few addresses turn unreachable, and people open your mail at every provider. |
| **Infrastructure** | Whether SendOps sees everything you send: channels and event reporting, tracking domains, DMARC reports and unseen sends. | Every send is reported back to SendOps, and tracked links use a verified domain. |

Click a section to filter the check table to it.

### Thresholds worth knowing

- **Bounce rate** (last 30 days): fails at 5% or more, warns at 2% or more. Mail to addresses already on your SES suppression list is left out, because SES never tried to deliver it.
- **Spam-report rate** (last 30 days): fails at 0.1% or more, warns at 0.08% or more.
- **Opens across providers**: if one provider has received at least 500 of your messages and opens there are under a quarter of the rate at your other providers, the check fails. That pattern usually means your mail is landing in junk at that provider.
- **Unseen sends**: if SES sent more than 20% more messages in the last day than SendOps saw, and at least 20 messages are missing, the check fails. Usually some of your mail is sent without a SendOps channel.

## How the score is calculated

Every check has a weight. Checks that matter most to whether mail lands weigh the most. For example, whether a real receiver verified your DKIM signature is the heaviest single check.

Each check ends up in one of five states:

| State | Counts toward the score? |
|---|---|
| **Pass** | Yes, as a pass. |
| **Warn** | Yes, as a pass. It still comes with an advisory task. |
| **Fail** | Yes, as a fail. |
| **Not measured** | No. SendOps didn't have the data to decide. |
| **Not applicable** | No. The question doesn't arise for this domain. |

The score is the weight of the checks you pass, as a share of the weight of every check that could be scored. So a check SendOps couldn't measure never counts against you, and never counts for you either.

The five sections have a nominal share of the score: Authentication 40, Reputation 25, Provider requirements 15, List hygiene 10 and Infrastructure 10. Because unmeasured and not-applicable checks drop out, the real share depends on what could be measured for your domain.

### Not measured yet

A check is **not measured** when SendOps doesn't yet have what it needs. Each one says what it's waiting for. Common reasons:

- **No recent authentication check.** The two biggest authentication checks need one. See [Authentication check](/reports/deliverability-score/authentication-check).
- **Not enough history.** Suppression list growth compares today with a reading from 30 days ago, so it's measured from about 30 days after your first score.
- **No mail sent.** Rate checks need mail from that domain in the last 30 days.
- **A reading failed.** If SendOps couldn't read something, such as your DNS or your SES account, only the checks that depend on it are left out. SendOps tries again on the next run.

### Checks you won't see yet

Some checks only appear once SendOps can actually measure them. Until then they are left out completely: not in the score, not in coverage, not in the list.

- **Not on a blocklist.**
- **One-click unsubscribe on bulk mail**, and the provider rules that depend on it.

They'll appear on their own when SendOps can measure them.

## Bands

| Band | Score |
|---|---|
| **Healthy** | 90 or more |
| **At risk** | 70 to 89 |
| **Failing** | Under 70 |

**Any blocking task makes the domain Failing, whatever the score says.** A blocking task means mail is being lost right now, so a high number would be misleading. See [Severity](/reports/deliverability-score/tasks#severity).

If no weighted check could be measured at all, the domain shows **Not enough measured yet** instead of a band or a number.

## Coverage

Next to the score, SendOps shows how many checks it could measure, for example "Scored on 9 of 13 checks · 4 not measured".

- **Scored** checks passed, warned or failed.
- **Not measured** checks are counted in the total but left out of the score.
- **Not applicable** checks aren't counted in the total, because a rule that doesn't apply isn't missing data.

A score built on fewer than 3 checks is low confidence: SendOps shows the number small and greyed out, with **Not enough measured yet** beside it. Treat it as a rough guide, not a verdict. Running an [authentication check](/reports/deliverability-score/authentication-check) is usually the quickest way to raise coverage.

## Provider requirements

Gmail, Outlook and Yahoo publish rules for bulk senders. These make up the **Provider requirements** section.

**They only apply above 5,000 messages a day to that provider.** SendOps works this out from the last 30 days of mail from your domain to each provider. Below that, every rule for that provider shows as not applicable, with your actual daily volume. AOL counts as Yahoo.

| Provider | Rules | Effective since | Source |
|---|---|---|---|
| **Outlook** (Microsoft) | SPF passes; DKIM passes as your domain; DMARC at least p=none and aligned; a working unsubscribe mechanism | 5 May 2025 | [Microsoft sender policies](https://substrate.office.com/ip-domain-management-snds/Postmaster/Policies) |
| **Gmail** (Google) | SPF passes; DKIM passes as your domain; DMARC published and aligned; one-click unsubscribe on marketing mail; spam rate under 0.30% | 1 February 2024 | [Google sender guidelines](https://support.google.com/a/answer/81126) |
| **Yahoo** | SPF passes; DKIM passes as your domain; DMARC published and aligned; one-click unsubscribe on marketing mail; spam rate under 0.30% | 1 February 2024 | [Yahoo sender best practices](https://senders.yahooinc.com/best-practices/) |

SendOps last checked each source on 12 October 2026. Each rule in the app links to its source and shows these dates.

What the providers say they do with mail that breaks the rules:

- **Outlook** sends it to Junk, then rejects it.
- **Gmail** rate-limits, junks or rejects it.
- **Yahoo** junks or rejects it.

Most rules re-use a check from another section, such as the receiver's DKIM verdict. If one fails, the fix is that check's task, so you won't see the same problem twice. The spam-rate rule is measured per provider, so it can fail for Gmail even when your overall spam-report rate looks fine.

The one-click unsubscribe rules are hidden for now. See [Checks you won't see yet](#checks-you-wont-see-yet).

## Notifications

The score can notify you about two things:

| Notification | When it fires | Sent to |
|---|---|---|
| **Deliverability Score Dropped** | A domain falls to a worse band between two runs, for example Healthy to At risk. Never on a domain's first score. | In-app and email |
| **Blocking Deliverability Task** | A domain gets a new blocking task, meaning its mail is being lost now. | In-app, email and Slack |

Neither has a threshold to set, because the bands and what counts as blocking are fixed. Each one is limited so it won't repeat every night, and it starts again once the problem clears.

To turn either off, or change where it goes, open **Notifications → Preferences** and find it under **Deliverability**. See [Configuring Notifications](/notifications/configuring-notifications).

## Shared AWS accounts

If more than one SendOps workspace uses the same AWS account, some checks look at the whole account, not just your workspace:

- **SES account in good standing.** A paused, under-review or sandboxed account affects every domain on it.
- **SendOps sees what SES sends.** SES counts sends for the whole account and region, so SendOps compares that with sends from **every** workspace on the account and region. Your siblings' mail isn't reported as missing.

See [Shared AWS Accounts](/aws-setup/shared-accounts) for how workspaces share an account.

## What's next?

- [Tasks and where you do them](/reports/deliverability-score/tasks): how to work through what the score finds.
- [Authentication check](/reports/deliverability-score/authentication-check): see how your mail arrives at a real receiver.
- [Accepted vs. Arrived](/reports/accepted-vs-arrived): why "accepted" doesn't mean "in the inbox".