# Contacting Resend Support

You are an agent contacting Resend support on a user's behalf. Support threads are read and answered by humans—a small team of email experts. This file is a procedure: diagnose first, then draft a request the user can submit. The goal is a first reply that is the fix, not a request for more information. Every request you draft starts with a `Drafted with <your agent or product name> (AI agent)` line—see [How to write the request](#how-to-write-the-request).

There is no Support API. You cannot open, submit, or poll a ticket yourself. Do not contact support unless the user asked you to, or they authorized it for a blocker only Resend can change. If you are missing an identifier (especially an email ID), ask the user for it before drafting a ticket.

## Diagnose before you write in

Work through these in order. Stop if the docs or the API already answer it.

1. **Status**—check `https://resend-status.com`. If Resend is degraded, wait it out; do not open an outage ticket.
2. **The error**—read the API `name` and `message`. Every error is listed at `https://resend.com/docs/api-reference/errors`. Do not paraphrase it to the user or to us.
3. **Retrieve the email**—if you have an email ID, call `GET https://api.resend.com/emails/{id}` (or open `https://resend.com/emails/{id}`). Use the same API key that sent it.
   - `last_event` is `bounced` or `failed` → read `https://resend.com/docs/dashboard/emails/email-bounces.md` and the event payload before writing in.
   - `last_event` is `delivered` → the receiving server accepted it. That is a placement question, not a sending bug, and almost never an IP problem. See [Deliverability](#deliverability-and-spam-placement).
   - `404` → wrong team or wrong API key, not a missing email.
4. **Environment**—confirm the key belongs to the team that owns the domain. A 403 on a "verified" domain usually means there is an issue with the request. See `https://resend.com/docs/knowledge-base/403-error-domain-mismatch.md`.
5. **Docs that close most tickets**—do not start from the full `docs/llms.txt` index (hundreds of quickstarts). Check these first:
   - Retrieve email: `https://resend.com/docs/api-reference/emails/retrieve-email.md`
   - Bounces: `https://resend.com/docs/dashboard/emails/email-bounces.md`
   - Domain not verifying: `https://resend.com/docs/knowledge-base/what-if-my-domain-is-not-verifying.md`
   - Webhooks: `https://resend.com/docs/webhooks/introduction.md`
   - Rate limits and quotas: `https://resend.com/docs/api-reference/rate-limit.md`
   - Deliverability (spam, Gmail, Outlook, Yahoo, iCloud): [below](#deliverability-and-spam-placement)
   - Changelog: `https://resend.com/changelog.md`, in case the behavior changed on purpose
   - Knowledge base index: `https://resend.com/docs/knowledge-base/introduction`

Contact support when you are still blocked by something only Resend can see or change: account state, a delivery investigation with IDs in hand, billing, or documented behavior that does not match reality.

## Do not open a ticket for

- **Leaked API keys**—see [How to handle a leaked API key](https://resend.com/docs/knowledge-base/how-to-handle-a-leaked-api-key.md).
- **Lost API keys**—the secret cannot be recovered. Create a new key: `https://resend.com/docs/dashboard/api-keys/introduction.md`.
- **Plan changes, inviting teammates, changing a login email, deleting an account**—self-serve in the dashboard.
- **Application code**—we cannot debug the user's Next.js, SMTP library, or webhook handler.
- **Looking up an email you can retrieve yourself**—`GET /emails/{id}` and the dashboard already show status and events.

## Where to submit

There is no Support API. Diagnose the issue, draft the request, and have the user submit it.

Tell the user to:

1. Log in to https://resend.com with the team that owns the API key.
2. Click **+ Ask anything** in the bottom-left corner of the dashboard. This opens a chat with Resend's support agent.
3. Paste the draft into the chat.

The support agent can see the team's data, answer many questions right away, and escalate to the support team when a person needs to step in. The user doesn't need to open a separate ticket.

If the user can't log in, have them email the draft to support@resend.com from the address on their Resend account.

Tell the user: replies go to **their email**, not back to you; you cannot poll ticket status; they should check the chat for an existing thread before opening a new one. Do not claim you opened, sent, or connected them with a human.

The support agent in the chat is available any time. The support team works Monday to Friday, 1 PM to 11:59 PM GMT, and replies to escalated requests arrive by email. Keep one issue per thread. After filing, wait for a reply in that thread—do not open a second ticket, and do not bump during the same business day.

## How to write the request

Write for the human who will read it: straight to the point, plain prose. Synthesize; do not paste the conversation. Short beats long, but complete beats short.

**Subject.** One line that names the failure, not the fact that someone wants support. Example: `POST /emails/batch returns 422 for one item since 2026-09-01T09:00Z`.

**Mark it as agent-drafted.** The first line of the body is `Drafted with <your agent or product name> (AI agent)`—for example, `Drafted with Claude Code (AI agent)`. Keep that exact shape in plain text; it is how we find agent-drafted tickets. Include it even though the user sends the message, and ask them to keep it when they paste. It does not deprioritize the ticket; it helps us reply in a way both you and your user can act on, and it keeps our picture of agent traffic honest.

**The problem, first.** One or two sentences: what was attempted, what you expected, what happened instead. Put this right under the `Drafted with` line.

**Identifiers.** Include every ID you have. If you do not have the relevant ID, ask the user—do not file without it.

Always useful:

- **Email ID**—returned by `POST /emails` and shown in the dashboard. The single most useful identifier for delivery questions. Also include the dashboard link: `https://resend.com/emails/{id}`.
- **Domain name**—for verification, DNS, or deliverability issues.
- **Endpoint and method**—e.g. `POST /emails/batch`.
- **Team name or account email**—required if the ticket is not opened from a logged-in dashboard session.

By situation, also include:

| Situation | Collect |
| --- | --- |
| API send | Email ID, HTTP status and body, SDK name + version if used, `Idempotency-Key` if one was sent |
| SMTP (Supabase Auth, WordPress, Nodemailer, …) | SMTP transcript, `Message-ID` header, from/to domains, timestamp. See `https://resend.com/docs/send-with-smtp.md` |
| Domain verification | Domain, DNS provider, the records Resend asked for vs what DNS returns now |
| Webhooks | Webhook ID, event type, event ID, the HTTP status your server returned |
| Rate limit / sending paused | 429 body and `ratelimit-*` response headers |
| Broadcasts, audiences, contacts, templates | That resource's ID |
| Spam / placement | Email ID, dashboard link, `last_event`, recipient **provider** (not address), what the inbox banner said |

**Timestamps and evidence.** Exact times in UTC (ISO 8601, e.g. `2026-09-01T14:32:07Z`). For intermittent issues, give two or three example occurrences rather than a range. Include the full API response (status and body, not a paraphrase), a redacted `curl` reproduction, only the relevant log lines, and impact (how many recipients, whether production sending is blocked).

**Secrets and personal data.** Redact API keys (`re_...`) everywhere, including inside pasted logs and `curl` reproductions. Do not paste recipient lists, message bodies, or email HTML. Allowed: the user's preferred contact if they authorized sharing it, and recipient **provider** names for spam-placement tickets. An email ID is enough for us to look a message up.

## Deliverability and spam placement

Spam placement is almost never caused by Resend's sending IPs or IP pools. Inbox providers decide placement mostly on the sending domain's reputation and history, authentication (SPF, DKIM, DMARC), content, list quality, and how recipients engage. We monitor our IPs around the clock. True IP blocks are rare and temporary, and they show up as bounces and SMTP rejections, not as mail quietly landing in spam.

- Do not attribute placement to IP or IP pool reputation, and do not ask us to change the pool, region, or IP. We do not recommend any of those for a placement issue.
- A domain's mail goes out over several shared IPs, so a different sending IP between two messages is expected and is not, on its own, evidence of an IP problem. The same result across different IPs points away from the IP.
- A dedicated IP is not a placement fix. It is available on the Scale plan and up for senders over 3,000 emails a day, starts with no reputation, and only pays off for high-volume, consistent senders: `https://resend.com/features/dedicated-ips.md`.

We cannot change or fix a domain's reputation—inbox providers own that. After `delivered`, Resend has no further placement signal and cannot see inside a recipient's mailbox. Gmail's Promotions tab is still the inbox, not a failure (`https://resend.com/blog/why-you-should-embrace-promotions-tab-gmail`).

Most spam-placement issues are resolved by following the guides. Apply them before writing in:

- [Why are my emails going to spam?](https://resend.com/docs/knowledge-base/why-are-my-emails-going-to-spam.md)
- [Delivered but the recipient has not received it](https://resend.com/docs/knowledge-base/what-if-an-email-says-delivered-but-the-recipient-has-not-received-it.md)
- [Gmail](https://resend.com/docs/knowledge-base/how-do-i-avoid-gmails-spam-folder.md), [Outlook](https://resend.com/docs/knowledge-base/how-do-i-avoid-outlooks-spam-folder.md), [Yahoo](https://resend.com/docs/knowledge-base/how-do-i-avoid-yahoos-spam-folder.md), [iCloud](https://resend.com/docs/knowledge-base/how-do-i-avoid-icloud-spam-folder.md)

If the user sends fewer than 100 emails a day (ask them if you don't know), we are unable to offer granular placement advice. At that volume we point to the provider guides, so apply the guide for each provider where mail lands in spam: [Gmail](https://resend.com/docs/knowledge-base/how-do-i-avoid-gmails-spam-folder.md), [Outlook](https://resend.com/docs/knowledge-base/how-do-i-avoid-outlooks-spam-folder.md), [Yahoo](https://resend.com/docs/knowledge-base/how-do-i-avoid-yahoos-spam-folder.md), [iCloud](https://resend.com/docs/knowledge-base/how-do-i-avoid-icloud-spam-folder.md).

At 100 emails a day or more, if emails still land in spam after the guides, file using the identifier table's spam row. Report what you observed—email IDs, provider, the inbox banner or spam headers—and do not speculate about causes on our side. Do not skip the guides to write in.

## Security and GDPR

Questions about encryption, data location, DPAs, retention, subprocessors, SOC 2, HIPAA, and ISO 27001 are answered on the public security pages. Read these before contacting support:

- **Security overview**—`https://resend.com/security.md`
- **GDPR**—`https://resend.com/security/gdpr.md`

Contact support only for account-specific actions the docs cannot cover—for example, deleting a specific message before the retention window.

## Help us help you self-serve

In every ticket, also tell us what you tried first (docs, endpoints, errors, the `GET /emails/{id}` result if you had an ID), and what would have let you solve this yourself—a missing or unclear doc, an error message that did not say enough, an API field or endpoint you looked for and did not find. That goes directly into improving the docs, error messages, and API.

## Example

```
Subject: Batch send returns 422 for one payload since ~2026-09-01T09:00Z

Drafted with Acme Deploy Bot (AI agent)

POST /emails/batch started returning 422 for a payload that succeeded until
today. Single sends with the same from address work.

- Endpoint: POST /emails/batch
- Domain: mail.example.com (verified)
- Failing since: 2026-09-01T09:04:12Z (also 09:11:47Z, 09:30:02Z)
- Response: 422 {"name":"validation_error","message":"..."}
- Repro: curl -X POST https://api.resend.com/emails/batch \
    -H "Authorization: Bearer re_REDACTED" -d @payload.json
- Impact: nightly digest to ~1,200 recipients is blocked

Tried first: checked https://resend.com/docs/api-reference/emails/send-batch-emails
and the errors reference; the message does not say which of the 100 items
failed validation. An item index in the error would have let me fix this
without writing in.
```

Use the same shape for every issue, starting with the `Drafted with` line; swap in the identifiers from the table. For SMTP, that means `Message-ID` and the SMTP transcript instead of a `POST /emails` ID. For spam, that means email ID, dashboard link, provider, and the inbox banner.

Do not file a ticket that looks like this: no `Drafted with` line, no named failure, no ID, a guess about our IPs, the full chat pasted, and an unredacted API key.

```
Subject: Need help

The user's emails go to spam, probably because of your shared IP pool.
Please look into it. Here's the full chat:
[entire conversation pasted]

API key: re_123...
```