Skip to main content
Suppression handling protects recipients and your domain reputation. Your application should decide when a recipient is eligible for transactional mail, non-transactional mail, or no mail at all.

​
Suppression types

MailChannels supports two suppression types:
TypeUse it for
transactionalBlock all mail to a recipient when you should not send any message, including operational mail.
non-transactionalBlock marketing, lifecycle, newsletter, or promotional mail while still allowing necessary transactional messages.
If you create a suppression entry without suppression_types, the default is non-transactional.

​
Suppression sources

Suppression entries can come from:
  • api
  • unsubscribe_link
  • list_unsubscribe
  • hard_bounce
  • spam_complaint
Use the source to separate recipient preference, automated bounce handling, and manual administrative actions.

​
Non-transactional messages

Set transactional to false for non-transactional sends. Non-transactional messages must be DKIM signed and must have exactly one recipient per personalization. MailChannels adds unsubscribe headers for non-transactional messages.
Do not mark marketing or promotional email as transactional to bypass suppression handling. That can create compliance risk and damage sender reputation.

​
Operational workflow

  1. Import existing unsubscribes and hard bounces into the suppression list before cutover.
  2. Store hard-bounced, complained, unsubscribed, and unsubscribe-related webhook events.
  3. Update your application preference store from those events.
  4. Check your own preference store before calling MailChannels.
  5. Review suppression list entries by recipient or source when debugging.