#Email토론 중인 항목 14개

It is important to disctinguish between bounce rates (hard/soft)  - which is specific to a send, and held status, which is specific to a subscriber. Are you referring to bounce rates on your latest sends? And if so - are these soft bounces? 

If you query Bounce data view, you will be able to see additional details about the bounces, and why they have occurred. If the bounce rates have spiked recently, it might be a deliverability issue - but without additional information, than what is in your original post, it is hard to tell.

Glad you tracked that down, Tom, and yes, that's confirmed correct. 

Per official Salesforce documentation (List Email Limitations page): "Required Editions: Available in: Essentials, Professional, Enterprise, Performance, Unlimited, and Developer Editions." 

Starter isn't in that list, so List Email genuinely isn't available on Starter, this wasn't a config or permission issue at any point, it was an edition gap. Essentials is the correct minimum tier for what you're trying to do. 

Reference:

Good call moving up, sounds like you're already past the point where Starter fits your workflow.

One important nuance to add to Kundan's answer, because this trips people up on Cases specifically: 

Bounce Management (Setup > Deliverability) flags the Contact/Lead/Person Account record, not the Case. Even with it enabled you will not get a bounce badge on the Case's email message itself, and 'Return bounced emails to sender' delivers the bounce notice to the sending user's own inbox, not onto the Case timeline. It also only kicks in reliably when the recipient resolves to a Contact/Lead/Person Account email, a free-typed typo address that matches no record can bounce with nothing flagged in Salesforce at all. That is most likely why your typo case showed nothing. 

How OOO replies and bounce (NDR) messages actually behave: they are just inbound emails sent back to whatever From/Reply-To you used. If you send from the Case using your Email-to-Case routing address, those replies DO come back into Salesforce, but by default they usually create a brand-new Case rather than attaching to the original, unless threading matches them up (Lightning header-based Email-to-Case threading, or the legacy Ref ID token in the subject/body). So the first thing I would check: search for Cases created from the mailer-daemon or the recipient's mail server around that time. Your OOO and bounce messages are probably sitting there as separate cases. 

If what you actually need is a reliable per-message 'did this bounce?' status shown on the Case, native Case email sending does not expose that. For that, route sending through an external email service/relay that reports bounces via webhook (e.g. SendGrid, or Email Relay with a mail server that returns delivery status), or use Marketing Cloud / Account Engagement for tracked sends. Those give true delivered/bounced status per message. 

Quick checklist: 

1. Setup > Deliverability: Bounce Management ON (flags Contact/Lead recipients). 

2. Confirm you are sending with the Email-to-Case routing address as From/Reply-To so replies return to Salesforce. 

3. Verify Email-to-Case threading (Lightning threading or Ref ID) so OOO/bounce replies attach to the original Case instead of spawning new ones. 

4. For guaranteed per-message bounce status, use an external relay with bounce webhooks or MC/Account Engagement. 

If this helps, please mark it as the Best Answer so it is easy for the next person to find. Thanks :)

Yep, you're not the first to notice this! Check out @Michael Kolodner's post here: https://trailhead.salesforce.com/trailblazer-community/feed/0D5KX00000pOw590AC https://www.freelikeapuppy.tech/post/unverifiable

There's also this Knowledge article:

The approaches mentioned above (API + Automation Studio, webhooks, or middleware) are all valid. 👍 I'd just add a few considerations based on webinar setups I've seen over time.

If Zoom is already a fixed requirement, I'd like @EDGAR Joes suggests, lean towards webhooks or scheduled API syncs over relying heavily on middleware logic/third party apps like Zapier. Keeping Marketing Cloud responsible for segmentation and journeys, while treating the webinar software as the source of engagement data, tends to be easier to maintain.

If you're still evaluating the webinar platform itself, it's also worth looking at solutions with native Salesforce integrations (for example Univid) that can pass registrations, attendance, watch time and other engagement signals directly into the Salesforce ecosystem, instead of building/maintaining the integration yourself. That can reduce the amount of custom integration work over time, as things update and change.

Curious what approach you ended up taking.