## TL;DR
The 403 means the API key is fine but its restrictions block this send. Fix it in the Resend dashboard: open the key, check its domain restriction and sending permission, and either add the sending domain to the key or create a key without the restriction. Regenerating the key also resolves keys corrupted by bad copy-paste.

```text
resend 403 restricted API key cannot send
```

## Use this when
- POST https://api.resend.com/emails returns 403 mentioning a restricted key
- The same from-address worked with a different key
- A new key fails while an older key succeeds

## Not for this skill when
- Resend returns 401 (the key is invalid, not restricted)
- The error is about domain verification (verify the domain instead)
- The 403 comes from a different email provider

## Steps
1. In the Resend dashboard, open API Keys and check the failing key's restrictions: domain restriction and permission scope. Expected: you see which restriction blocks the send.
2. If the key is restricted to certain domains, add your sending domain to the key's allowed list, or create a new key with no domain restriction. Expected: the key permits the from-address you use.
3. Confirm the key has the Sending access permission, not read-only. Expected: permission includes send.
4. If restrictions look correct, regenerate the key (bad copy-paste with truncated characters is a real cause) and update your environment. Expected: the fresh key sends successfully.
5. Test with a minimal send: from your verified domain, to [recipient email], simple subject. Expected: 200 with an id in the response.

## Variant phrasings
### resend api key restricted 403 forbidden
Open the key in the dashboard; the domain restriction is the usual blocker.
### resend cannot send with this api key
Check permission scope: a read-only key 403s on every send.

## Tool/version compatibility
Resend REST API (api.resend.com) and the resend Node/Python SDKs; key restrictions are managed in the Resend dashboard under API Keys as of 2026.

## Why it happens
Resend lets you scope keys to specific sending domains and to read-only access. A 403 with a restricted-key message means authentication succeeded but authorization failed: the key exists and is valid, but the policy attached to it does not cover this send. This is distinct from 401, which means the key itself is wrong.

## Edge cases / pitfalls
- The from-address domain must match the key's allowed domains exactly; subdomains count separately.
- Rotating to a new key without updating every deployment (staging, workers, CI) leaves some sends 403ing.
- Read the key via os.environ.get("RESEND_API_KEY") and never print or log it.
- Test keys in Resend are unrestricted in some setups; a passing test key does not prove your restricted prod key works.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_O8zLCzKJhms0sAB7E__Svg