# Check Email Deliverability in Resend

Yes. An agent reads 14 days of Resend sends and the domain's status, then writes deliverability.md with bounce causes and any DNS fix.

[Run this on Rush](https://cloud.getrush.ai/run/email-deliverability-report/resend/).

## What the agent does

No repo and no attachment. The account is the Resend connection, catalog URL https://mcp.resend.com/mcp, the same remote server Resend documents, signed in with OAuth through POST /me/connections. Name it in connections on the session so this key run can reach it and nothing else. Resend's MCP docs group the relevant tools as Emails (list and get, among others), Domains (list, get, verify, and domain settings such as tracking and TLS), and Logs (API request logs, including request and response bodies). The prompt tells the agent to list and get, and not to send, not to create a domain, and not to remove a webhook.

The window is the last 14 days of emails. The agent lists them and keeps each message's delivery status. Bounce and complaint rates are counts from those statuses divided by the number of messages listed, and the file shows both the numerator and the denominator. Bounces are grouped by the reason field the email payload contains and by the recipient's domain. A status or reason the payload does not include is reported as not returned, not as a zero. Logs are opened only for messages whose status is a failure, so the report can quote the response body Resend stored, which their docs say the log tools return.

The sending domain is a separate read. The agent lists domains and gets the one that sent the messages, including whatever verification and DNS detail that get returns. Resend's docs say domain tools cover verification and settings such as tracking and TLS. They do not, in that summary, name SPF, DKIM and DMARC as separate tool arguments. The report prints the records or the verification errors the payload actually includes, and if the payload only says verified or not verified, the file says that and does not invent a TXT record. A suggested fix is quoted from the error the tool returned, or marked as not provided by the API.

Nothing is sent. The agent does not call the email send or batch-send operations, does not update the domain, and does not start a verification that would change account state unless the payload is a read of current status. deliverability.md is the only output: rates, grouped bounces, the domain's verification block, and the log excerpts for failures.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "Use the Resend connection. List emails sent in the last 14 days and read each delivery status. List domains and get the sending domain's verification details. For failures, read the API logs Resend exposes and quote the response body. Write deliverability.md with bounce and complaint rates (show counts, not only percentages), bounces grouped by reason and recipient domain, and any SPF, DKIM or DMARC problem that the domain payload actually contains, with the record or error it returned. If the payload has no DNS record, say the record was not returned. Do not send email, do not update the domain, and do not create or remove anything.",
  "connections": [
    "resend"
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

deliverability.md is an artifact. Download it from the session's artifact url, which works without the key for an hour and is renewed on the next session read. The file states the 14-day window as timestamps, the message count, bounce count, complaint count, and the two rates. Then tables: reason by count, recipient domain by count. Then the domain section, copied from the domain get, plus log excerpts for failed sends. result on the session is a short recap of the rates so a webhook can show them; the tables stay in the file because result is capped at 16 KiB on the webhook.

A reviewer checks the arithmetic against the counts in the file, then checks one bounced id against the transcript's email get and, if present, the log body. They check that the DNS section does not contain a record the domain payload did not return. They check that no send tool was called. Resend's email tools include send, and the transcript is where that absence is visible.

Fixes are applied by a person in DNS and then, if you want, a later run reads the domain again. This run does not publish a record. A follow-up message can narrow the window to one recipient domain; POST /o/{org}/sessions/{id}/messages once the turn is no longer running.

## Run it on every complaint rate or a weekly read

Run it on a weekly schedule from your server, and also when your own monitoring sees a bounce spike. POST /o/{org}/sessions with this body. The Idempotency-Key for the weekly run is the ISO week; a spike run uses a different key so it is not collapsed into the weekly one. Same key and same body return the original session.

webhook_url on the key delivers run.completed within about 30 seconds. Your handler verifies the signature, pulls deliverability.md, and opens a ticket only when the bounce count in result is above the threshold you set. Do not parse a ticket out of a run that failed before writing the file. Undelivered webhooks retry at 2, 4 and 6 minutes and then drop; read session_url to catch up.

## Why run it on Rush?

Bounce diagnosis is a join between recent messages, a domain object, and request logs. Resend's dashboard shows each of those. This run reads them through one connection inside a sandbox and writes a single file with the counts visible. The prompt bars send, so a deliverability check cannot become an accidental email. The token stays on the connection and is not echoed in the session.

The transcript holds the list calls and the log bodies, which is what you want when a reason string is ambiguous. A weekly read of one domain is a small session; a bad week across several sending domains is several sessions, limited by max_concurrent (default 4) and then 429. They do not share a log buffer.

## Frequently asked questions

### Will it send a test message to check the domain?

No. The prompt forbids send, batch send, and domain updates. Rates come from messages already sent in the last 14 days. A domain with no messages in that window is reported as no traffic, not probed with a new email.

### Where do SPF, DKIM and DMARC come from?

Only from the domain payload the Resend tools return. Their docs describe domain get and verify, plus settings such as tracking and TLS, and the report prints those fields. If a record is not in the payload, the section says it was not returned. The agent is not supposed to guess a TXT value or to look up DNS on its own and present that as Resend's status.

### Are complaint rates the same as bounce rates?

No. The file counts them separately, from the delivery status on each email, and shows the numerator and the denominator. A message with a status the payload does not classify is listed under not returned, so it is not silently dropped from the denominator.

### Can it read a sandbox Resend account?

It reads whichever account the connection's OAuth sign-in approved. Resend's docs also allow a bearer API key for clients that cannot open a browser. On Rush that key is the token on the MCP connection, not a value in the prompt. Use a test account's connection until the report's grouping matches how you read the dashboard.