HTTP error 403: Forbidden SendGrid

A 403 Forbidden from SendGrid is an authorization failure, not an authentication failure. Per RFC 9110 §15.5.4, 403 means the server understood the request but refuses to fulfill it — and if credentials were supplied, it explicitly considers them insufficient to grant access, which in practice is what "authenticated but not authorized" means. In other words, SendGrid recognized your API key — it just won't let that key (or that sender) perform this request. This is distinct from a 401 Unauthorized, which means the key itself is missing or invalid.

For the SendGrid v3 Mail Send API there are two dominant causes. Identify yours from the response body before changing anything.

What causes HTTP error 403 from SendGrid?

1. The API key is missing the "Mail Send" scope. SendGrid keys are scoped. A key created with Read-only access, or a Restricted/Custom key that doesn't include Mail Send, authenticates fine but is forbidden from sending. SendGrid keys come in three types — Full Access, Restricted (Custom) Access, and Billing Access — and within Custom keys each scope can be set to No Access, Read Access, or Full Access (SendGrid API Keys docs).

2. The "From" address is not a Verified Sender. SendGrid requires every from address to belong to a verified Single Sender or an authenticated domain. If it doesn't, the send is rejected with HTTP 403 and the message "The from address does not match a verified Sender Identity" — Twilio catalogs this as error 60222, explicitly an HTTP 403.

A third, narrower case: a 403 on the Email Activity API (not Mail Send) usually means the paid Extended Email Activity History add-on isn't on the account, or the key lacks Email Activity permission (SendGrid support).

How do I fix HTTP error 403 from SendGrid?

Step 1 — Read the error body. The JSON errors[].message tells you which cause applies. A permissions problem reads like "access forbidden" / "does not have the required permissions"; a sender problem reads "does not match a verified Sender Identity."

Step 2 — Fix API key scope (cause 1). In the SendGrid dashboard go to Settings → API Keys, open your key, and confirm Mail Send is enabled. You can edit an existing key's permissions in place — you don't have to recreate it. If you create a new key, prefer Restricted Access with only the scopes you need (least privilege) rather than Full Access. Then update your app with the new key value (SendGrid only shows it once):

curl -X POST https://api.sendgrid.com/v3/mail/send \
  -H "Authorization: Bearer $SENDGRID_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"personalizations":[{"to":[{"email":"to@example.com"}]}],"from":{"email":"you@yourdomain.com"},"subject":"Test","content":[{"type":"text/plain","value":"hi"}]}'

After changing scopes, wait a minute and retry — permission changes can take a short time to propagate.

Step 3 — Verify your sender identity (cause 2). In Settings → Sender Authentication, either complete Domain Authentication (recommended) or Single Sender Verification, then make your from.email exactly match a verified identity. SendGrid advises against using free Gmail/Yahoo/Outlook addresses as Single Senders because DMARC enforcement at those providers will cause spam/rejection — authenticate your own sending domain instead.

Step 4 — If it's the Email Activity API, purchase the Extended Email Activity History add-on (primary admin or a Teammate with Administration permissions) and allow up to ~12 hours for billing to propagate, or switch to the Event Webhook.