Every check that fails or warns on the [Deliverability Score](/reports/deliverability-score) comes with **one task**: what is wrong, what to do, and where to do it. If one fix solves several checks, you get one task, not several.

Tasks are listed under the score, most severe first.

## Where you do it

Each task leads with a label that says where the fix happens. That tells you who needs to do it: whoever has the DNS login, the AWS login, or access to SendOps.

| Label | What it means | What the task gives you |
|---|---|---|
| **In SendOps** | A change in SendOps itself, such as a channel setting or DMARC reporting setup. | An **Open in SendOps** link to the right page. |
| **Your DNS** | A record to add or change at your DNS provider. | The exact records to copy, with copy buttons. |
| **Your AWS account** | A change in your SES console. | A link to the right page in the AWS console. |
| **Third party** | Something only an outside service can fix, such as a blocklist operator. | The provider's instructions. |

Some fixes take two steps in two places. These show both labels in order, for example **1. Your AWS account → then 2. Your DNS**: verify something in SES, then publish the records SES gives you.

## Severity

| Severity | What it means |
|---|---|
| **Blocking** | Mail is being lost now. Any blocking task makes the domain **Failing**, whatever its score. |
| **Important** | Mail is at risk, or SendOps can't see part of your sending. Fix it soon. |
| **Advisory** | A good practice that protects you later. |

Some tasks get more serious once your DMARC policy is enforcing. For example, mail that isn't signed as your domain is *more likely to land in junk* under `p=none`, but is *quarantined* or *refused* under `p=quarantine` or `p=reject`. The same task becomes blocking under enforcement.

## How tasks close

**Most tasks close themselves.** When you've made the fix, click **Re-check now** on the task, or wait for the nightly run at 05:40 UTC. If the check passes, the task closes.

DNS changes can take a while to spread. If a re-check still shows the task open straight after you publish a record, give it a little time and check again. You can re-check a domain up to 6 times an hour.


  If a check can't be measured on a run, for example because SendOps couldn't read your DNS that night, its task stays as it was. It isn't closed and it isn't reopened.


### Mark as handled

A few tasks are about how you work, not a setting SendOps can check, such as where bad addresses come from. These say **SendOps can't check this one for you** and offer **Mark as handled (90 days)**.

Marking a task as handled moves it to the bottom of the list for 90 days. It stays visible, so "handled" is never mistaken for "fixed". If the problem is still there after 90 days, the task opens again.

Re-checking and marking tasks as handled both need permission to manage domain authentication.

## Common tasks

| Task | Where | The fix |
|---|---|---|
| **Set a custom MAIL FROM** | Your AWS account, then your DNS | Your mail passes DMARC on its DKIM signature alone. That's fine under `p=none`, but once you enforce, one DKIM hiccup sends mail to junk. In SES → Verified identities → your domain → Custom MAIL FROM domain, set a subdomain such as `mail.yourdomain.com`, then publish the MX and SPF records SES shows you. |
| **Mail is signed as amazonses.com, not as your domain** | Your AWS account, then your DNS | The app sending this mail uses SES in a region or account where only the address is verified, not the domain. Verify the domain there (SES → Verified identities → Create identity → Domain), then publish its DKIM records. |
| **SendOps can't see who is sending as your domain** | In SendOps | Receivers send daily DMARC reports, and none reach SendOps. Set up [DMARC reporting](/domain-auth/setting-up-dmarc-reporting) for the domain to get the address to add to your record. |
| **Reports on mail sent as your domain don't reach SendOps** | Your DNS | Your DMARC record sends reports somewhere else only. Replace it with the record the task shows. It keeps your policy and existing addresses, and adds SendOps's. |
| **SendOps can't see what happens to mail from your domain** (no channel) | In SendOps | Your mail isn't sent through a SendOps channel, so bounces, complaints, opens and clicks never arrive. If you have one channel, open it and choose **Set as Default**. If you have several, pick a channel for the domain on the **Identities** page. If you have none, create one. Then have your app send with that channel's configuration set. See [Managing Channels](/channels/managing-channels). |
| **Choose a 2048-bit DKIM key** | Your AWS account | Your mail is signed with a 1024-bit key, which receivers increasingly treat as weak. In SES → Verified identities → your domain → Authentication → DKIM → Edit, choose RSA_2048_BIT and save. Nothing changes in DNS. SES switches keys at its next rotation, but the task closes as soon as SES reports the next key will be 2048-bit. |
| **Your app keeps sending to addresses SES will never deliver to** | In SendOps | Over 1% of your sends (and at least 10) in the last 30 days went to addresses on your SES suppression list. SES drops them without trying. They don't hurt your bounce rate, but none will arrive. Stop sending to the addresses on the [Undeliverable List](/reports/undeliverable-list), or have your app check it before sending. Then mark the task as handled. |
| **Run an authentication check** | In SendOps | SendOps only has SES's own word on your signing. Run an [authentication check](/reports/deliverability-score/authentication-check) to see what a real receiver sees. |

If you brought your own DKIM key (BYODKIM), the 2048-bit task asks you to generate a new key pair and publish it at a new selector instead, since SES can't rotate a key you supplied.

## What's next?

- [Deliverability Score](/reports/deliverability-score): how the score, bands and coverage work.
- [Authentication check](/reports/deliverability-score/authentication-check): the check behind the two biggest authentication tasks.
- [DNS Configuration](/domains/dns-configuration): adding records at your DNS provider.