Marketing Cloud Engagement - Email Deliverability Issues (Bounces & Spam) FAQ

Salesforce Marketing Cloud Engagement Email Deliverability FAQ

Q: Can I send emails from a domain that is not authenticated with SAP or PD?
A: While technically possible, it is not recommended. Sending emails from a domain not registered and authenticated as an SAP or PD significantly increases the likelihood of failing sender domain authentication (SPF and DKIM). Emails that fail authentication are at a much higher risk of being treated as spam or blocked by receiving servers. Therefore, it is strongly recommended to use a domain registered with an authenticated SAP/PD in Marketing Cloud Engagement as your sending domain.

Q: Why is "via [bounce.SAPdomain]" displayed after the sender address in some email clients?
A: This "via" display is shown by some email clients, including Gmail. It may appear when the domain in the email's From: header differs from the domain of the server that actually sent the email. This is intended to increase transparency for the recipient regarding the email's sending path.
Specifically, if you use a domain in the From: address that is not authenticated with your SAP, the email client may detect a mismatch between the "display sender domain" and the "actual sending path domain," and consequently display part of the actual sending path (e.g., bounce.SAPdomain) as "via."

Q: If I want to change my DMARC policy, what should I set it to?

A: The choice of DMARC policy is up to you to decide. A DMARC record is a DNS TXT record that instructs receiving servers on how to handle emails that fail authentication (based on SPF and DKIM verification results) sent from your domain.

• Delegated Domains: If your domain is delegated to Salesforce, you can request DMARC record updates via a support case. Please provide the target domain and the full text of the new DMARC record (TXT record) in your request.

• Self-Hosted Domains: If you are using a Self-Hosted setup, the DNS is managed on your side. Please update the record directly on your DNS server.

Reference : https://help.salesforce.com/s/articleView?id=000384283&type=1

Q: Despite sending with SAP/PD, an external report indicates that SPF/DKIM authentication failed. What are the main causes?
A: In Marketing Cloud Engagement, if your SAP or PD is correctly configured and authenticated, SPF/DKIM authentication should normally pass as long as these domains are used in the From: address. (However, receiving mail server judgment criteria can vary, and this may not always be the case. See the next Q for details.)

If authentication fails, the following are the main potential technical causes:

• Email Forwarding: If an email is forwarded to another address due to the recipient's settings or email system. Authentication information can be compromised during the forwarding process.
• Sending from Mail Servers Other Than Marketing Cloud Engagement: If the domain is used to send emails from other mail servers (e.g., different internal company systems, other email delivery services) where SPF/DKIM is not properly configured, or if a third party fraudulently uses the domain to send spoofed emails.
• Incorrect DKIM/SPF-related DNS Settings: If there were errors in DNS record settings during the initial SAP/PD setup or during configuration changes, or if DNS propagation is delayed. This also applies if DKIM signing settings on the sending server are incomplete.

If none of the above apply, or if identifying the cause is difficult, obtain the complete email header information (also known as "email source"; in Gmail, this is "Show original") from an email that actually failed SPF/DKIM authentication. Email headers contain detailed records of the email's delivery path and authentication results at each relay server, providing crucial clues for pinpointing the cause.

If it's difficult to determine the cause, send a test email from Marketing Cloud Engagement to a test subscriber, and if authentication failure is confirmed on the receiving end, obtain the header information from the failed email and contact Salesforce Support.

Q: What factors can cause DMARC to fail when delivering with SAP or PD?
A: While it depends on the criteria of the receiving mail server, if passing alignment for both DKIM and SPF is required, Private Domains (PDs) may fail SPF alignment, leading to DMARC failure.

In Marketing Cloud Engagement, this can happen because even when using a PD, the Envelope-From domain (also known as the P1 From or SMTP From) is typically fixed as bounce.[SAP Domain]. Consequently, for a PD, the domain in the email's From: header (P2 From or Header From) will be completely different from the Envelope-From domain.

Enabling the “multi-bounce domain” feature can resolve this issue. This feature changes the Envelope-From domain to bounce.[PD Domain], which is then expected to allow SPF alignment to pass. To enable this feature, please contact Salesforce Support with your Member ID (MID).

Reference:https://help.salesforce.com/s/articleView?id=004464661&type=1

Q: Why was an email sent from Marketing Cloud Engagement marked as "spoofing" by services like Gmail, Outlook.com, or Microsoft Exchange Online? 
A: As long as a correctly configured and authenticated SAP/PD is used as the From: domain, it is unlikely that emails sent from Marketing Cloud Engagement will be identified as spoofing by major email providers.
If an email is identified as spoofing, first please check if any of the main causes explained in Q: "Despite sending with SAP/PD, an external report indicates that SPF/DKIM authentication failed. What are the main causes?" (such as email forwarding, sending from non-Marketing Cloud Engagement servers, or DNS misconfigurations) apply.

Q: Can I see emails that were filtered into spam folders or quarantined/deleted by receiving servers in Marketing Cloud Engagement reports?
A: No, you cannot. Information on how an email was processed by the receiving server (e.g., filtered to spam, quarantined, or deleted) is typically not fed back to the sender. Therefore, you cannot directly check these statuses from Marketing Cloud Engagement (MCE).

Q: When is bounce information recorded in the _bounce data view? A: Information is recorded in the _bounce data view when an email bounce is finally "confirmed."

• For Hard Bounces: When a hard bounce (permanent delivery error) occurs on the first sending attempt, MCE generally stops future sends to that address and records the bounce information.
• For Soft Bounces: When a soft bounce (temporary delivery error) occurs on the first sending attempt, Marketing Cloud Engagement retries sending the email at 15-minute intervals for a configured period (default is 72 hours). If delivery is still unsuccessful after this retry period ends and the final retry fails, it is recorded as a soft bounce.

Q: Can I check details during the soft bounce retry period (number of retries, time, SMTP messages, etc.)?
A: No, you cannot. As mentioned earlier, the _bounce data view only records information when the bounce is finally confirmed. You cannot check details such as the number of individual retry attempts during the retry period, the specific times, or the SMTP messages for each attempt.

Q: When does the soft bounce retry period start?
A: The soft bounce retry period (default 72 hours) begins based on the time when the Marketing Cloud Engagement mail(MTA) server first attempted to send the email. (Not a value of EventDate on _sent data view.)

Q: Can the EventDate in the _Sent data view be interpreted as the date and time the recipient received the email?
A: No, this records the time when the email creation was completed by an internal service (often referred to as OMM - Outbound Mail Manager) and was handed over to the mail server (MTA). Unfortunately, there is no way to confirm the time the email was sent from the MTA or the time it arrived in the recipient's mailbox using this data view.

Q: A recipient reported an email delivery delay. How can this be investigated?
A: The most accurate way to investigate is to have the recipient provide the email headers. Email headers contain "Received" lines, which show information and timestamps from the mail servers that relayed the email, allowing you to identify at which point the delay occurred.

If obtaining this from the recipient is difficult, you can check if the EventDate in the _Sent data view is later than expected. However, as mentioned above, this does not indicate the time it was sent from the MTA to an external mail server. Therefore, if you cannot determine the cause, please contact us with the JobID, Subscriber Key, and approximate sending time. We can then check for any issues on our MTA server side.

Q: Why are my emails going to Spam even though SPF/DKIM passed?

A: Passing authentication proves your identity, but it does not guarantee inbox placement. ISPs evaluate many complex factors. Since ISPs do not disclose specific reasons for spam placement, senders must use tools like Postmaster Tools or external reputation monitors to assess the situation.

Key factors influencing Spam filtering:

• User Complaints: High rates of recipients marking emails as spam.

• Reputation: Poor domain/IP reputation based on past history (e.g., high bounce rates, spam traps).

• Content Quality: Misleading subject lines, high image-to-text ratios, or use of URL shorteners.

• Engagement: Low open or click-through rates.

• List Quality: Sending to invalid or old addresses.

• Volume Spikes: Sudden, drastic increases in sending volume.

• Authentication Issues: DMARC alignment failures.

Q: Why does the same email go to the Inbox for some users but Spam/Promotions for others? (Can I control this?)

A: Advanced providers like Gmail and Outlook filter emails based on individual user behavior (engagement). Therefore, even if the email content is identical, the placement (Inbox vs. Spam vs. Promotions) can vary depending on the recipient's personal interaction history with your emails. Senders cannot technically force this placement. The best approach is to continuously improve content and strategy to boost engagement.