How do CRMs manage suppression at contact level?

Picture this: a contact unsubscribes from your marketing emails, but three days later your sales rep sends them a cold outreach from the CRM. Not great. This is exactly the problem contact-level suppression is supposed to prevent.

Most CRMs handle suppression by storing a flag directly on the contact record. In HubSpot, that's the "Email Opt Out" property. In Salesforce, it's the "Email Opt Out" checkbox on the lead or contact object. When that flag is set to true, the platform blocks the contact from receiving any emails triggered through that system.

What actually sets the flag? A few common triggers:

• Manual unsubscribes from an email campaign (ESP passes the signal back to the CRM)
• Hard bounces, which tell the system this address can't receive mail
• Spam complaints, where the contact marked your email as junk
• Manual suppression by a rep or admin who knows something the system doesn't (a customer called to opt out, for example)

The contact stays in your CRM. It doesn't get deleted. It just gets a do-not-email flag attached to the record. That's intentional. You still want the contact history, the deal records, the notes. You just don't want to accidentally email them again.

Here's where things get messy in practice. Your CRM and your ESP are often two separate systems. If your ESP suppresses a contact after a hard bounce but that signal never makes it back to your CRM, a sales rep can still trigger an email from inside the CRM and it'll go out. The fix is a bi-directional sync between your ESP and CRM, so a suppression on either side updates both systems automatically.

Some platforms handle this natively. HubSpot's connected inbox and native ESP integration keeps opt-out status in sync without extra configuration. Salesforce Marketing Cloud has its own suppression list layer that, when properly integrated with the Sales Cloud contact record, flows both ways. But if you're using a third-party ESP like Mailchimp or Brevo alongside a standalone CRM, you'll typically need a Zapier workflow, a native integration, or a custom API sync to keep suppression flags consistent across both tools.

Still one more layer worth knowing: some CRMs let you define suppression reasons, not just a binary on/off flag. That matters because a hard bounce and a GDPR deletion request are very different situations, even if both result in no email being sent. Tracking the reason helps you stay on the right side of compliance without overcomplicating your workflow. (More on the automation triggers that feed into this process if you want to go deeper.)

If you're not sure whether your CRM and ESP are actually in sync on suppression, now is the right time to check. A stale suppression gap is the kind of thing that quietly damages your sender reputation for months before you notice.

Need a second set of eyes on your setup? Our SOS hotline is free and we actually pick up.