Skip to main content

#Email Deliverbility11 discutindo

Hi! I was wondering if anyone else was experiencing this. We have been getting a much lower than normal open rate the past two monthly sends. We used to average between 40-50% open rate but have now dropped to 29% for each send (august & september). I first thought it was our subject line but don't think that's the cause anymore. Our delivered emails remain the same so no drop in that. 

 

I did research on the Gmail update that happened in July that penalizes larger lists and prioritizes engagement. We do have a lot of unengaged subscribers which I am thinking could be the cause of this. Would it be worth cleaning out these subscribers to see if this fixes the issue? Any other recommendations or think this may be something else? 

 

#Marketing Cloud  #Email Deliverbility

6 respostas
  1. Ontem 15:17

    @Taylor Thomas

     

    Good that rules out the most common silent failure cause, so this now points toward reputation/engagement rather than authentication. With 65k/123k on Gmail, you're well past the bulk sender threshold, so their spam-rate and engagement bar applies fully to you. 

    1. Gmail Postmaster Tools - do this first, it's the actual source of truth Everything above is inference from opens; Postmaster gives you Gmail's own view: 

    • Spam rate - this is the one that matters most. Gmail wants this under 0.10%, and anything approaching 0.3% risks bulk filtering. Marketing Cloud's own complaint tracking undercounts this people who just hit "report spam" without unsubscribing don't always show up the same way in MC's complaint metrics.
    • Domain/IP reputation High/Medium/Low/Bad bucket, tracked daily
    • Delivery errors and feedback loop data
    • Needs domain verification (TXT record) if not already set up, this alone is worth doing regardless of the current issue, since you'll want the historical trend once you have it.

    2. Segment your engagement report by ISP before doing anything else

    If open rate dropped roughly evenly across Gmail/Yahoo/Outlook, that points more toward content/list fatigue than a Gmail specific inbox placement issue. If it's disproportionately Gmail, that confirms reputation/spam rate as the driver. This one check tells you which of the two paths below to prioritize. 

    3. On spam rate specifically check for a silent cause

    Since authentication passes, a spam rate creep is the next most likely explanation for exactly this symptom (delivered flat, opens down). Things that quietly push spam rate up: 

     

    • A list merge/import around July/Aug that added lower-quality or older contacts
    • No visible/working one-click unsubscribe (Gmail requires the List Unsubscribe header AND that it actually works within 2 days) if someone can't easily unsubscribe, they hit "report spam" instead
    • Content changes (new sender name, new link domains, more images) that shifted spam filter scoring independent of reputation

    4. Sunset flow before mass suppression

    Once you know the spam rate and whether it's Gmail specific, then move to hygiene but sequence it: 

     

    • Re-engagement send to 90+ day unengaged (low risk subject line ask if they still want these)
    • Suppress non responders after that, rather than a single large deletion a sudden big cut can itself cause a short-term reputation dip right when you're trying to recover
0/9000

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 respostas
  1. 18 de ago., 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 resposta
  1. 17 de ago., 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 respostas
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 comentários
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 comentário
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 respostas
  1. Tom Bassett (Vera Solutions) Forum Ambassador
    20 de ago. de 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 respostas
  1. Tom Bassett (Vera Solutions) Forum Ambassador
    9 de ago. de 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