ZapBounce and SendGrid

SendGrid maintains suppression lists that persist across campaigns: bounces, blocks, spam reports and invalid addresses. Once an address is on one, SendGrid stops sending to it.

That is correct behavior and it creates a specific trap. A customer whose address was mistyped once, bounced once, and got suppressed will never receive a transactional email again until somebody removes them by hand.

Suppression is permanent until a human intervenes

SendGrid's bounce suppression list is not time-limited. An address added in 2024 stays there, and every send to it is silently dropped before it leaves SendGrid.

Because the drop is silent, your application believes the password reset was sent. The customer believes it was not. Support then spends twenty minutes establishing which.

A typo captured at signup produces exactly this. The address bounces, gets suppressed, and every subsequent transactional email to that account disappears without an error your code can see.

How the data moves

  1. Verify at signup, before the first transactional send

    The first send is what creates the suppression. Catching the typo before it is the only cheap fix.

  2. Cross-check your suppression list against verification

    Export SendGrid's bounce list and verify it. Addresses that come back valid were probably suppressed unfairly.

  3. Remove unfairly suppressed addresses

    SendGrid's API supports deleting suppression entries. A valid verdict is grounds for reviewing one.

  4. Keep marketing and transactional on separate subusers

    So a marketing list problem cannot suppress an address your transactional stream needs.

Setting it up

  1. Verify addresses at signup before any transactional send.
  2. Export SendGrid's bounce and invalid suppression lists.
  3. Verify those addresses as a batch.
  4. Review the ones that come back valid: they may have been suppressed after a temporary failure.
  5. Remove reviewed entries through the suppression API.
  6. Separate marketing and transactional streams onto different subusers.

SendGrid: common questions

Do SendGrid suppressions expire?

Bounce suppressions do not expire on their own. They stay until somebody removes them through the API or the interface.

Should I bulk-remove suppressions that verify as valid?

Review rather than bulk-remove. A valid verdict plus a soft-bounce suppression reason is a good case; a hard bounce is not.

Why does my app think the email sent?

SendGrid accepts the request and drops it at the suppression check. Your API call succeeded; the message did not leave.

Check a SendGrid export today

100 free checks a month, no card. Unknown results and duplicates are never billed.