Salesforce email bounce management is the process of tracking, categorizing, and acting on failed email deliveries within your Salesforce org. When a recipient's mail server rejects an email, Salesforce logs the failure in two fields on the Lead or Contact record: EmailBouncedReason and EmailBouncedDate.

Salesforce email bounce management step by step guide

However, Salesforce does not automatically suppress bounced addresses from future sends. Without workflow automation or third-party tools, bounced contacts remain in your email lists and continue receiving campaigns. This gap is where most deliverability damage happens. The sections below cover bounce types, setup steps, diagnostics, automation, and prevention.

Bounce Types in Salesforce

Salesforce email bounces fall into two categories: hard bounces (permanent delivery failures) and soft bounces (temporary delivery failures). Salesforce logs each bounce in the EmailBouncedReason and EmailBouncedDate fields on the Lead or Contact record. The EmailBouncedReason field stores the receiving server's raw error text. Salesforce does not classify that text as hard or soft, and does not suppress bounced addresses from future sends. Admins must read the error message, determine the bounce type, and build automation to handle each one.

Hard Bounces

A hard bounce is a permanent delivery failure. The address will never accept email, and continuing to send to it damages sender reputation. Common EmailBouncedReason values include:

  • "User unknown" or "Mailbox not found" — the address does not exist
  • "Domain not found" or "No such domain" — the domain is invalid (often a typo like yaho.com)
  • "Address rejected" — the server has permanently refused delivery
  • "Bad address syntax" — the email is malformed (missing @ symbol, invalid characters)

Hard-bounced addresses should be removed or corrected immediately. Salesforce displays an alert icon next to the bounced field on the record. However, it does not suppress the address from future sends. Without a Flow or workflow rule, records where EmailBouncedDate is not blank stay in your email lists. They receive your next campaign as if nothing happened.

Soft Bounces

A soft bounce is a temporary delivery failure. The address is valid, but the message could not be delivered at that moment. Common EmailBouncedReason values include:

  • "Mailbox full" or "Over quota" — the recipient's storage is maxed out
  • "Service temporarily unavailable" — the server is down or overloaded
  • "Message too large" — the email exceeds the server's size limit
  • "Temporarily deferred" — the server is rate-limiting inbound messages

Salesforce retries soft-bounced emails over a 72-hour window. If delivery succeeds and the recipient opens or clicks, the bounce flag clears. The record returns to Active status.

A single soft bounce does not require action. Repeated soft bounces across three or more consecutive campaigns signal an inactive or abandoned mailbox. At that point, suppress the address to protect deliverability.

Not every rejection fits neatly into hard or soft. Authentication failures (SPF, DKIM, DMARC misconfigurations) and blocklist rejections also cause bounces. Salesforce Sales Cloud does not categorize these separately. Marketing Cloud Email Studio tracks them as block bounces and technical bounces, covered in the Marketing Cloud section below.

How to Enable Bounce Management in Salesforce

To enable bounce management, open Setup, type "Deliverability" in the Quick Find box, and check "Activate bounce management." This single setting tells Salesforce to monitor every outbound email for delivery failures. Without it, Salesforce does not record any bounce data on Lead or Contact records.

What This Setting Does

Once you activate bounce management, Salesforce tracks every failed delivery. It writes two fields on the bounced Lead or Contact record:

  • EmailBouncedReason stores the raw error text from the receiving server
  • EmailBouncedDate stores the timestamp of the bounce event

Salesforce also shows an alert icon on bounced records in the highlights panel. This icon tells users the address has a delivery problem.

Optional: Return Bounce Notifications to Senders

On the same Deliverability page, you will see a second checkbox: "Return bounced emails to sender." Check this if you want the sending user to receive an email notification when a message bounces. Leave it unchecked if you plan to handle bounces through reports and automation only.

What This Setting Does Not Do

Activating bounce management only starts recording data. Salesforce still does not:

  • Remove bounced addresses from send lists
  • Block future emails to bounced contacts
  • Classify bounces as hard or soft
  • Retry failed deliveries automatically

You need custom automation for those actions.

Why Salesforce Emails Bounce and How to Diagnose Failures

Salesforce emails bounce when the receiving mail server rejects the message. The most common causes are:

  • Invalid or misspelled email addresses
  • Nonexistent or deactivated domains
  • Full recipient mailboxes
  • SPF or DKIM authentication failures
  • Sender IP reputation blocks
  • Message size exceeding the server's limit

Salesforce logs every rejection in the EmailBouncedReason field on the Lead or Contact record. This field stores the receiving server's raw error text. Salesforce does not parse, categorize, or act on this text. Admins must read each error and determine the cause themselves.

Common EmailBouncedReason Values

These are the error strings you will see most often:

  • "User unknown" or "Mailbox not found": the address does not exist (hard bounce)
  • "Domain not found": the domain is invalid or shut down (hard bounce)
  • "Address rejected": the server permanently blocked the sender (hard bounce)
  • "Mailbox full" or "Over quota": the inbox has no space (soft bounce)
  • "Service temporarily unavailable": the server is down (soft bounce)
  • "Message too large": the email exceeds the size limit (soft bounce)

SMTP Error Codes in Bounce Messages

The EmailBouncedReason field sometimes includes SMTP status codes. These codes help you classify bounces faster:

  • 550: mailbox does not exist or is unavailable (hard bounce)
  • 553: mailbox name is not valid (hard bounce)
  • 421: service is temporarily unavailable (soft bounce)
  • 452: insufficient storage at the receiving server (soft bounce)

A 5xx code signals a permanent failure. A 4xx code signals a temporary one. You can use these codes to build classification logic in Salesforce Flow.

How to Create a Bounce Report in Salesforce

You create a bounce report by building a custom report type with EmailBouncedReason and EmailBouncedDate fields. Standard Salesforce report types do not include bounce fields. You must add them manually before bounce data appears in reports.

Build a Custom Report Type

Open Setup and type "Report Types" in Quick Find. Click New Custom Report Type. Select Contacts or Leads as the primary object. Name it something descriptive, like "Contacts with Bounce Data." Save the report type. Edit its layout and add EmailBouncedReason and EmailBouncedDate to the available fields.

Run the Report

Go to the Reports tab andcreate a new report using your custom report type. Add a filter where EmailBouncedDate does not equal blank. This returns only records that have bounced at least once. Add EmailBouncedReason as a column to see each record's raw server error text.

Read the Results

Group the report by EmailBouncedReason to spot patterns. Clusters of "User unknown" or "Mailbox not found" point to invalid addresses. These are hard bounces and need immediate removal from your lists. Clusters of "Service temporarily unavailable" suggest temporary server issues worth retrying. Schedule the report to run weekly so new bounces surface before they damage sender reputation.

Automating Bounce Suppression with Salesforce Flow

You suppress bounced addresses by building a Record-Triggered Flow that fires when EmailBouncedDate populates. Salesforce does not remove bounced contacts from future sends on its own. Without this automation, invalid addresses stay in your lists and keep collecting bounces.

Set the Trigger

OpenFlow Builder and create a new Record-Triggered Flow. Set the object to Contact or Lead. Configure the trigger to fire when EmailBouncedDate changes from null to any value. This catches the exact moment Salesforce registers a bounce.

Add the Suppression Action

Your Flow needs at least one of these actions:

  • Set "Do Not Email" to true on the bounced record.
  • Clear the Email field so no tool can send to that address.
  • Add the record to a "Bounced" campaign for review.

Hard bounces need immediate suppression. For soft bounces, add a Decision element that checks bounce count before suppressing.

Test Before Activating

Debug the Flow with a test record that has no EmailBouncedDate. Set EmailBouncedDate to today's date and confirm the action fires. Activate only after you verify it works on both Contacts and Leads.

Handle Existing Bounced Records

This Flow only catches new bounces going forward. Records that bounced before activation still sit in your lists unsuppressed. Use your bounce report to find them and suppress those records manually or with a batch update.

How to Reduce Email Bounce Rates

You reduce email bounce rates by fixing data quality, authentication, and sending habits before each campaign. Most bounces trace back to preventable issues in one of these three areas. Address all three to keep your bounce rate below the 2% threshold that mailbox providers flag.

Fix Data Quality First

Verify every email address before adding it to your Salesforce records. Remove contacts that have not opened or clicked in the last 90 days.Clean your email lists on a monthly schedule to catch bad addresses early. Use double opt-in for new subscribers to block fake or mistyped addresses at the source.

Lock Down Authentication

Configure SPF, DKIM, and DMARC records for every sending domain in your org. Authentication failures are one of the top causes of soft bounces and spam folder placement. Run a test send to confirm all three records pass before launching a campaign.

Stabilize Sending Habits

Keep your send volume consistent from week to week. Sudden spikes trigger spam filters at receiving servers. Segment your lists so each campaign targets contacts who have engaged recently. Monitor your sender reputation score after every large send.

Bounce Handling in Marketing Cloud

Marketing Cloud Email Studio classifies every bounce into one of four formal categories: Hard, Soft, Block, or Technical. Sales Cloud logs bounce reasons as raw text without any classification. Email Studio assigns a structured category to each failure and acts on it automatically.

Automatic suppression

Email Studio suppresses hard-bounced addresses after a single failure. It suppresses soft-bounced addresses after three consecutive failures to the same recipient. Sales Cloud requires a Record-Triggered Flow for the same result. Email Studio handles it natively.

Block and Technical bounces

Sales Cloud does not track these categories. Block bounces occur when the receiving server rejects a message based on content policy or sender filtering. Technical bounces result from DNS failures, connection timeouts, or server misconfigurations. Email Studio logs both as distinct categories alongside hard and soft.

Bounce data storage

Sales Cloud writes bounce data to the Contact or Lead record. Email Studio writes it to tracking data views. The _Bounce data view logs every bounce event with its category, subscriber key, SMTP code, and timestamp. The Bounce Tracking Extract exports this data on a schedule for reporting.

Where both clouds stop

The two clouds do not share bounce data by default. Organizations sending from both need independent suppression processes. Both clouds react after a bounce has already happened. Neither one verifies addresses or monitors sender reputation before you hit send.

How MassMailer Prevents Bounces Before Sending

MassMailer verifies every email address before your campaign sends. Itsemail verification engine catches syntax errors, inactive domains, and nonexistent mailboxes. Your campaign skips those addresses automatically.

Beyond verification, MassMailer tracks sender reputation in real time. It alerts admins when deliverability scores drop after a send. That early warning gives teams time to pause campaigns or clean lists before reputation damage spreads.

Both capabilities run natively inside Salesforce. MassMailer reads directly from your Contact, Lead, and Campaign records. No middleware, no external platform, no data sync to manage.

Start your free trial and verify your first list before the next campaign goes out.