Skip to main content

#Email Deliverbility7 personnes en discutent

Hi, 

When emails are sent from cases, don't receive any out-of-office messages or failed email messages.  In one case there was a typo error in the email address, but didn’t receive an error message like the one you get when you send an email incorrectly in Outlook. Can Salesforce capture and display Out-of-Office responses or email bounce-back messages for emails sent from Cases? Are there any email settings, Email-to-Case configurations, or deliverability options that need to be enabled to receive these notifications? 

 

Thanks. 

 

#Salesforce Admin  #Salesforce Developer  #Service Cloud  #Case Management  #Email Deliverbility  #Email

2 réponses
  1. 18 août, 18:39

    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 :)

0/9000

Hi all, hoping to get some real-world input on an Email Relay / deliverability issue we've been chasing.

The problem:

 

Our org has Salesforce configured with an Email Domain Filter (catch-all, */*) routing all outbound mail through an Email Relay pointed at our Google Workspace SMTP relay service. We've started getting persistent 550-5.7.1 "Invalid credentials for relay" bounces — root cause is that Salesforce sends from a large, rotating pool of outbound IPs, and our relay's IP allowlist can't keep up. This affects everything from Opportunity Update Reminders to account-transfer notifications, not just bulk sends.

Our Current setup:

  • IP allowlist maintenance — works but requires constant upkeep as Salesforce's IPs rotate.

Questions for the community:

  1. For anyone who's actually deactivated their Email Domain Filter and let Salesforce send directly. How has deliverability held up long-term, especially to Gmail/Outlook/Yahoo?
  2. Is there a real, common business reason to keep Email Relay active, can I run processes without it? (DLP scanning, compliance archiving, etc.) Anything that I should weigh before dropping it, beyond Bounce Management/Email Security Compliance features?
  3. For those using a third-party SMTP relay (SMTP2GO, SendGrid, Mailgun, Postmark, etc.) with Salesforce, any real experience with shared-IP-pool deliverability issues specifically for transactional CRM mail?
  4. Anyone running the TLS-certificate-domain method (vs. IP allowlist) on an Exchange Online connector for Salesforce specifically — has Salesforce's certificate stayed consistent for you over time?

Appreciate any first-hand experience — trying to land on something maintainable rather than another band-aid. 

 

#Email Deliverbility

1 réponse
  1. 17 août, 14:24

    Hi Jaylen - really well-framed question, and the core of it is one architectural constraint: Salesforce Email Relay can't do SMTP AUTH (there's no username/password in the relay config), so the receiving relay has to trust Salesforce either by IP or by TLS certificate. Google Workspace's SMTP relay only offers IP allowlist or SMTP auth - no cert-domain matching - and since Salesforce can't authenticate, you're left maintaining the IP allowlist forever. That's why it feels like a treadmill: with Google as the relay target, it genuinely is a dead-end. 

     

    Two maintainable exits: 

     

    1) Drop the relay and send direct with full auth (my default recommendation). Configure DKIM keys in Salesforce (Setup > DKIM Keys), SPF with include:_spf.

    salesforce.com

    , and a DMARC record. Direct sending with SPF + DKIM + DMARC alignment holds up well to Gmail/Outlook/Yahoo - it satisfies the 2024 bulk-sender requirements natively - and it removes the IP-allowlist maintenance entirely. On your Q1: deliverability direct is generally as good or better, because you drop a hop and stop inheriting a relay's reputation. 

     

    2) If you must keep a relay for compliance, move the target from Google to Exchange Online and use the TLS-certificate connector method instead of IP allowlisting (your Q4). EXO inbound connectors can authenticate Salesforce by the domain on its TLS cert, which survives IP rotation - Google's relay can't do that. Salesforce's cert renews over time, but the domain EXO matches on has stayed stable, so it's held up as a maintainable approach. 

     

    On Q2 (reasons to keep the relay): the legitimate ones are outbound archiving/journaling, DLP scanning, org-wide disclaimers, and 'all egress through one gateway' security policies. If none of those are mandated, you can safely drop it - Bounce Management, DKIM, and Email Security Compliance all work fine without the relay. The relay's real value is compliance/DLP, not deliverability. 

     

    On Q3 (SendGrid/Mailgun/Postmark/SMTP2GO): heads-up - those authenticate via API-key SMTP AUTH, which (per the constraint above) Salesforce's relay can't supply. So they don't slot in cleanly as a Salesforce relay target unless they also offer IP-based acceptance, and you'd be back to the same problem plus shared-pool reputation risk on transactional mail. 

     

    Net: for 'maintainable, not another band-aid' - go direct-with-DKIM if you don't have a hard archiving/DLP mandate, and EXO-with-TLS-cert if you do. Google-relay-plus-IP-allowlist is the one path that can't be made low-maintenance, because of the no-SMTP-AUTH limitation. 

     

    Hope that helps you land it!

0/9000

Hello everyone,

I'm looking for clarification on the current behavior of Salesforce Organization-Wide Email Address (OWEA) verification.

Historically, when an Organization-Wide Email Address was created, Salesforce sent a verification email to the specified address. The recipient could open the email, click the verification link, and the address would become verified.

We are now seeing a scenario where selecting the verification link redirects the recipient to a Salesforce login page instead of completing the verification process.

A Salesforce Support representative indicated that, following a recent Salesforce release, the person opening the verification link may need to authenticate with Salesforce to complete the verification process. However, I have not been able to find any official documentation or release notes that describe this change.

The Salesforce documentation I found states that each organization-wide address requires verification and that an admin verifies a new organization-wide address by clicking the link in the email sent after creating the address, but I don't see any mention of a Salesforce login requirement for the recipient. 

My questions are:

  1. Has anyone else observed Organization-Wide Email Address verification links redirecting users to a Salesforce login page?
  2. Is a Salesforce login now required to complete OWEA verification?
  3. If this behavior is expected, is there any official documentation or release note that explains the change?
  4. Is there a supported verification process for recipients who do not have Salesforce user accounts?

Any insight or links to official documentation would be greatly appreciated. 

 

#Organization-Wide Email Addresses  #Email Deliverbility  #Information Security Salesforce  #Setup & Configuration  #Email

5 réponses
0/9000

Deliverability Tips Series

The @* Marketing Cloud Engagement * Deliverability team brings you helpful tips and guidance to build and maintain a great sending reputation.

In this post, we wanted to share information about "branded mail" in Apple, it's not BIMI, it's unique to Apple's new Business Connect solution which is free for companies to sign up for. Senders must have DMARC configured to display their logo.

Deliverability Tips SeriesThe Deliverability team brings you helpful tips and guidance to build and maintain a great sending reputation.

 

#Marketing Cloud  #Email Deliverbility

0/9000

Deliverability Tips Series

The @* Marketing Cloud Engagement * Deliverability team brings you helpful tips and guidance to build and maintain a great sending reputation.

 

In today's post we share resources that may help with your Cyber Week campaign planning.

 

➡️ Holiday Readiness Article: https://help.salesforce.com/s/articleView?id=002376589&type=1

➡️ Preparing for Peak Volume Blog: https://www.salesforce.com/blog/email-deliverability-readiness-peak-volume/

➡️ Impact of Cyber Week Volumes on Sender Reputation Blog: https://www.salesforce.com/blog/cyber-week-impact/

➡️ Deliverability Resource Homepage: https://help.salesforce.com/s/articleView?id=sf.mc_es_email_deliverability.htm&type=5

 

#Marketing Cloud  #Email Deliverbility

0/9000

Deliverability Tips Series

 

The @* Marketing Cloud Engagement *  Deliverability team shares valuable insights to help you build and maintain a strong sending reputation. Today, we discuss the dangers of list purchasing and its impact on your sender reputation. While buying lists might seem like a quick way to grow your audience, it can lead to significant problems. Here's why:

The Hazards of List Purchasing in SFMC

  1. Compliance and Legal Risks

Purchasing email lists often violates privacy laws like:

GDPR in the EU

CAN-SPAM Act in the U.S.

CCPA in California

 

Non-compliance can result in hefty fines and penalties.

  1. Poor Data Quality: Purchased lists are often filled with outdated or inaccurate data, leading to high bounce rates and low engagement. This diminishes the effectiveness of campaigns and skews your analytics in SFMC.
  2. Negative Impact on Deliverability: Recipients who didn’t opt-in are likely to unsubscribe or report your emails as spam, harming your sender reputation and decreasing deliverability rates.
  3. Brand Reputation Risks: Sending unsolicited emails can damage your brand’s image. If your emails are seen as intrusive, it can foster negative perceptions that are hard to reverse.
  4. Ineffective Segmentation: Purchased lists lack proper segmentation, making it difficult to deliver personalized content. SFMC's powerful segmentation tools work best with quality, permission-based data.
  5. Resource Drain: The time spent fixing issues from poor-quality lists—such as handling compliance problems and cleaning data—can far exceed any short-term gains.
  6. Missed Engagement Opportunities: Relying on purchased lists distracts from nurturing your existing, engaged audience, which could lead to deeper customer relationships and better long-term results.

Conclusion

While list purchasing may offer a quick audience boost, the risks outweigh the benefits. Building an organic, permission-based audience ensures compliance, protects your brand reputation, and leads to more effective marketing. In the long run, focusing on quality will drive better engagement and sustainable success.

 

Alternatives to List Purchasing in SFMC

To avoid the risks of list purchasing, focus on organic list-building strategies. Here are some effective alternatives:

  1. Create Valuable Content: Offer free resources like eBooks or webinars to attract sign-ups from genuinely interested users.
  2. Optimize Your Website: Use pop-ups, subscription forms, and lead magnets to encourage visitors to subscribe, offering incentives like discounts.
  3. Leverage Social Media: Promote email sign-ups via contests or gated content on social platforms to grow an engaged list.

Deliverability Tips Series The Deliverability team shares valuable insights to help you build and maintain a strong sending reputation.

 

#Email Deliverability Issues  #Email Deliverbility  #Marketing Cloud

2 commentaires
0/9000

Deliverability Tips Series

 

The @Marketing Cloud Deliverability team brings you helpful tips and guidance to build and maintain a great sending reputation.

 

In this post we’ll talk about IP capacity.

 

Did you know that mailbox providers limit the amount of mail an IP address can send in a day? This is not a Marketing Cloud restriction but is tied closely to how mailbox providers view your reputation as a sender. Sending large amounts of mail through a single IP can appear as 'spammy' behavior to many mailbox providers. 

 

Where we start seeing deferrals from major mailbox providers occur is typically once a customer starts sending 2M+ emails per day through a single IP.

 

3 key points to keep in mind:

 

* 1 Dedicated IP can send a maximum of 2.5M million sends per day (24 hour window), once you reach 2M sends per day it's time to start adding IP capacity for your campaigns.

* Project ahead for growth; if you’re going to need more IP(s) to accommodate volume in the next 1-3 months, add them now. New IPs will require a IP warm-up plan.

* Mailbox providers are on high alert Oct. - Dec. as mail volume spikes due to the retail season (Cyber Week). Learn more about how Cyber Week volume impacts a sender's reputation in our latest blog.

 

Remember that deliverability success is reflective of sending practices. If you are sending more than the recommended volume and seeing a decrease in deliverability or an increase in deferrals, it may be time to review your email program and IP configuration.

 

#Marketing Cloud #Email Deliverability Issues #Email Deliverbility

1 commentaire
0/9000

A client had a question around automated emails send via approval processes. They are sending automated approval emails and want it to show as coming directly from the user. Is this possible?

#Approval Process #Automated Emails #Email Deliverbility

2 réponses
  1. 20 août 2021, 18:13

    Hello,

     

    You can overrirde this with a Organisation Wide Email Address on the Process Automation Settings page.

     

    Hello, You can overrirde this with a Organisation Wide Email Address on the Process Automation Settings page.

     

    Thanks, Tom

0/9000

I would like to set the 'isBounced' value based upon the update of a custom checkbox field. But 'isBounced' (label:  Bounced) doesn't show up as an available field in workflows or Process Builder.  In fact, it doesn't even show up in the list of fields when you go to the Object in setup (Lead and Contact).

 

How can I set the value of 'isBounced'?  

 

Reason:  Enhanced Email and Bounce Management are both active.  But an email relay through Gmail is set up.  This means that Salesforce isn't actually doing any bounce management, and doesn't set the 'isBounced' field on a bounce.  However, a third party marketing app we're using does track bounces, and they can set a custom "Bounced" field in Salesforce based upon their information.  I would like to update the real field based on the custom field.  Then the Users will get the little yellow triangle in their Activity timeline.

 

#Email  #Email Deliverbility  #Bounced Email  #Sales Cloud

3 réponses
  1. 9 août 2021, 19:44

    Hello,

     

    If you use a Process Builder to set the Email Bounced Date and Email Bounced Reason this checks the field in the background which then displays the Warning Triangle.

     

    Thanks, Tom

0/9000

I've been reviewing the considerations material for this up-coming Pardot change and I read that "Opted Out is owned by the prospect" and it's independent of the Do Not Email field - owned by the Marketer. Fine.

 

Q: is there still a way to individually override a Prospect Opt Out? I can see that if the import process is used, then this is one method. But from an actual Prospect record will this still be possible?

 

In case anyone reads this and thinks "but that's exactly what we're not supposed to do so why would you want to do that?". A: my client sends out training material to cohorts, not marketing material, and critical log-in details do not get through to some organisations due to their front-ends auto-opting them out. We've enabled 2-click unsubscribe to try and prevent this occurring however I am still keen to ask the question above to understand what functionality will or will no longer be available, if anyone knows.

 

Thanks,

Steve

#Email Marketing #Unsubscribe #Email Deliverbility

1 réponse
0/9000