What's actually happening
A contact unsubscribes, bounces, or reports a campaign as spam. Weeks later, someone on the team re-adds them to a list in the CRM or marketing tool, flips their status back to "subscribed," and sends a new campaign. SendGrid's API accepts the request and returns a 202 -- no error, no warning. The email never arrives, and nothing in your own system tells you why.
The reason is that SendGrid enforces suppression independently of whatever subscription flag your CRM or app is tracking. Bounces, spam reports, unsubscribes, and invalid addresses each get written to their own suppression list inside SendGrid's account, and that list is checked at send time, after your integration has already handed the message over. Re-activating a contact in your own database does nothing to that suppression record -- the two systems simply aren't the same source of truth, and most integrations never surface the mismatch.
Why suppression is layered the way it is
SendGrid separates a handful of suppression types, and each behaves a little differently:
Bounces (hard bounces specifically) get added automatically and permanently, since a hard bounce usually means the address doesn't exist. Spam reports are added automatically and are not meant to be removed except in genuine error. Global unsubscribes apply account-wide, blocking every future send regardless of campaign or list. Unsubscribe groups (SendGrid's Advanced Suppression Manager, or ASM) are narrower -- a contact can opt out of one category of mail, like a weekly digest, while remaining fully eligible for transactional email or a different group entirely, as long as sends are tagged with the right asm.group_id.
The trap usually shows up one of two ways: either a team treats a global unsubscribe as something a CRM-side toggle can override, or a team sends everything through a single unsubscribe group, so one opt-out from a newsletter silently suppresses receipts, password resets, and every other type of mail that account was ever meant to receive.
The fix: check suppression before you resend, don't just update your own flag
Before a contact who previously bounced, complained, or unsubscribed is added back into an active send, the suppression record itself needs to be checked and, if the reactivation is genuinely legitimate (a fresh, explicit opt-in -- not just someone deciding internally that enough time has passed), explicitly cleared through SendGrid's own suppression endpoints rather than assumed away by a CRM update:
GET /v3/suppression/bounces and DELETE /v3/suppression/bounces/{email} list and clear a specific bounced address. GET /v3/suppression/invalid_emails covers addresses that failed basic validation. GET /v3/asm/suppressions/{group_id} and the matching delete call manage opt-outs scoped to one unsubscribe group, while a true global unsubscribe has to be cleared at the account level, not the group level. Spam-report suppressions can be queried the same way, but clearing one without a genuine reason to believe the original report was a mistake is a good way to damage sender reputation rather than fix a delivery problem.
Actionable considerations
Before launching any reactivation or win-back campaign, batch-query the suppression endpoints for the list you're about to send to and filter out anything still flagged, rather than trusting a CRM-side "subscribed" field alone. Separate transactional mail (receipts, password resets, account notices) into its own unsubscribe group or send it without an asm group entirely, so a marketing opt-out can never block a password-reset email. And when an integration platform like Make or Zapier reports that a SendGrid send "succeeded," remember that success means the API accepted the request -- it says nothing about whether the address was actually suppressed on SendGrid's side, so a true delivery check still needs to look at the suppression and activity data directly, not just the response code.
For the related mechanics on other email providers -- how Mailgun and Postmark each handle their own bounce and suppression lists, and where their APIs diverge from SendGrid's -- see each provider's own application overview, including the specific Delete a Global Suppression and List Global Suppressions actions if you're automating the cleanup step. More implementation guides like this one are on the blog.
