Suppressions

A suppression is an address SendGrail will not send to. The suppression list is a per-account do-not-send list that protects your sender reputation: repeatedly mailing addresses that bounce or report spam is exactly what gets a sender blocked.

How an address gets suppressed

An address lands on the list in one of two ways:

• Automatically — when a message to it hard bounces (the address doesn't exist) or the recipient marks a message as spam. SendGrail adds the address so you don't keep mailing a known-bad recipient.
• Manually — you add it yourself in the dashboard under Suppressions, for example to honour an unsubscribe request.

Each suppression records a reason: bounce, complaint, manual or unsubscribe.

What happens at send time

Before every send, SendGrail checks each recipient against your suppression list. If any recipient is suppressed, the message is not delivered — but the request does not fail.

Instead, the API returns 202 Accepted with a suppressed status:

{
  "id": "3f5c9a1e-8b2d-4e6f-9a1c-7d4b2e8f0a63",
  "from": "Acme <hello@example.com>",
  "to": ["bounced@example.org"],
  "status": "suppressed",
  "suppressed_reason": "bounce",
  "scheduled_at": null,
  "created_at": "2026-05-21T08:12:32.000000Z"
}

This is deliberate:

• A 202 (not a 4xx) means your sending code doesn't need special-case error handling for an event that's expected and benign.
• The message is still recorded — it appears in the Emails list with status Suppressed, so the attempt is auditable.
• An email.suppressed webhook fires, so your app can react (e.g. flag the contact in your own database).

Check status on the send response. If it's suppressed, the recipient did not receive the email.

Managing the list

In the dashboard under Suppressions you can:

• Review every suppressed address with its reason and the date it was added.
• Add an address manually (reason manual). Re-adding one that's already suppressed keeps its original reason — a bounce stays a bounce.
• Remove one or several addresses (tick the rows to remove in bulk); you type the address to confirm. Do this only when you're confident the underlying problem is resolved — for example, the recipient asked to be re-subscribed, or a hard bounce was caused by a typo you've since corrected.

Removing a suppression

Removing an address means SendGrail will send to it again. If it bounces or complains a second time, it's re-suppressed — and repeated bounces damage your domain's reputation with mailbox providers. Only remove an address when you have a real reason to believe delivery will now succeed.

Distinct from disposable-address blocking

Suppression is separate from SendGrail's disposable address check. Sending to a known disposable / throwaway email domain is rejected outright with a 422 error — it's treated as a bad input for you to fix, not a recorded send. See Errors.

Next steps

• The email object — every status a message can have, including suppressed.
• Webhook events — react to email.suppressed in your app.