How to Verify Email Addresses in Salesforce Without Breaking Records

Salesforce does not verify email addresses before you send to them. It checks the format of the Email field, and if Bounce Management is switched on it flags a lead or contact after a hard bounce. To find dead addresses before they bounce, export leads and contacts with their record Id, run the file through a verifier, and write the results back by Id with Data Loader.

The field descriptions and tool limits below come from Salesforce's own documentation, read on 6 October 2026.

What Salesforce already does about bad addresses

Salesforce reacts to bounces after the fact; it never checks a mailbox before a send. The feature that handles this is Bounce Management, configured on the Deliverability page in Setup.

Salesforce's deliverability guidelines describe what happens when it is on:

• If an email to a contact, lead or person account bounces, "an alert icon appears next to the email address in the detail page."
• The icon appears for a hard bounce, "a permanent delivery failure". It "doesn't appear with a soft bounce".
• "Other users can't send an email to the address until it's updated or confirmed."
• The Bounced Contacts and Bounced Leads standard reports list every address that has bounced, with the reason, the date, and the record.

That is useful, but it has two limits. It is driven by email Salesforce itself sends (the same page notes that bounces come back to Salesforce, not to the sender's own mailbox), so a campaign sent through a separate tool cannot be expected to update these fields. And every flagged record has already cost you a bounce. On a list imported from an old spreadsheet or a data vendor, that can be a lot of bounces at once, and mailbox providers count them all against your domain. Our bounce rate limits by platform post lists where the published lines sit.

The bounce fields, from the object reference

Three standard fields hold bounce data, and writing to them yourself does not change Salesforce's behaviour. From the Contact object reference:

Field	Type	What Salesforce says it holds
EmailBouncedDate	dateTime	"the date and time of the bounce" if bounce management is activated and an email results in a hard bounce
EmailBouncedReason	string	"the reason for the bounce"
IsEmailBounced	boolean	Whether the email "results in a soft or hard bounce"
HasOptedOutOfEmail	boolean	Labelled Email Opt Out: whether the contact "doesn't want to receive email from Salesforce"

The Lead object has EmailBouncedDate, EmailBouncedReason and HasOptedOutOfEmail with matching descriptions.

Both pages warn: "Email bounce functionality isn't triggered by record updates, including updates to this field." Writing verification results into EmailBouncedReason will not make Salesforce show alerts or block sends, so keep them in your own field.

Note also that the field description for IsEmailBounced covers soft bounces, while the alert icon only appears for hard bounces. If you report on bounces, filter on EmailBouncedReason and read it, rather than treating the flag alone as "address is dead". A hard bounce and a temporary failure need different responses.

Step 1: Add a field to hold the result

Create a custom picklist field on Lead and on Contact to store the verification status, plus a date field for when it was checked. Values such as valid, invalid, risky and unknown are enough.

This keeps "a verifier said this mailbox does not exist" apart from "an email we sent bounced", and the date tells you when to re-check. How often to re-verify covers sensible intervals.

Step 2: Export leads and contacts with their Id

Export the record Id alongside the Email field, because the Id is what lets you write results back to exactly the right record.

You have two built-in options, and Salesforce's import tool comparison explains the difference:

Tool	Records	Import	Export	Editions
Data Import Wizard	Up to 50,000	Yes	No	All except Personal and Database.com
Data Loader	Between 5,000 and 5 million	Yes	Yes	Enterprise, Unlimited, Performance, Developer, Database.com

The Data Import Wizard cannot export at all, so for a list of any size, export with Data Loader.

With Data Loader, the export guide says to click Export, or Export All "if you want to also export archived activity records and soft-deleted records". For verification you want plain Export: there is no point checking addresses on deleted records.

Select at least these fields:

• Id
• Email
• HasOptedOutOfEmail
• EmailBouncedReason and EmailBouncedDate

Export leads and contacts as separate files, because they are separate objects and are updated separately.

Step 3: Verify the file outside Salesforce

Deduplicate the Email column, verify the unique addresses, then join the results back to every row that shares them.

The same address often sits on a lead and a contact, or on several contacts. Verifying unique addresses saves time, and a lookup in a spreadsheet maps each result back to every Id. Cleaning and verifying a list in Excel has the formulas for that round trip.

The verifier should check the domain's MX records, hold an SMTP conversation with the mail server, and detect catch-all domains, which accept every address and so cannot confirm any single mailbox. If you use SimpleVerifier, a CSV of up to 100,000 rows comes back with email, status and reason columns, and you can export valid, risky and invalid separately. Any tool works if it tells you why an address failed.

Build an update file with three columns: Id, your status field, and your checked-date field. Only include rows you want to change.

Step 4: Write the results back by Id

Use Data Loader's Update operation and map the Id column, so each result lands on the record it came from.

The Data Loader guide covers the steps: choose Update, pick the object (Lead or Contact), select your CSV, then map its columns to Salesforce fields. For an upsert, the file "must contain a column of ID values for matching against existing records", which is either an external ID or the Salesforce record Id. For a plain update from an export, the record Id is what you have, and it is unambiguous.

When the job finishes, Data Loader "generates two unique CSV log files. One file name starts with 'success,' and the other starts with 'error.'" Open the error file every time.

The Data Import Wizard can also update existing records, and its tipsheet lists "Update existing matched records; ignore unmatched records (no insert)" as supported. It is fine for up to 50,000 records. Matching on Email instead of Id is where it goes wrong: when one address sits on several records, the match is no longer one-to-one.

Step 5: Decide what each status means in Salesforce

Do not delete records with bad addresses; mark them and keep them out of sends.

Verification result	Suggested action
valid	Nothing to do. Record the date checked
invalid (mailbox or domain does not exist)	Set your status field to invalid. Tick Email Opt Out so nobody emails it by accident. Look for a new address from the account or a recent signature
risky (catch-all, role address, disposable)	Keep. Send in smaller batches or only one-to-one
unknown (timeout, greylisting)	Re-verify in a few days before acting

A record with a dead email often still has a phone number or opportunity history, and deleting it invites the next import to recreate it. One caution on Email Opt Out: Salesforce defines it as the person not wanting email. If your team treats that field as a consent record, filter sends on your status field instead and keep opt-out for real unsubscribes.

Keep new bad addresses out

Verify at the point of entry, and re-verify imports before they reach Salesforce.

• Forms. Check the address before submission, while the person can still fix a typo.
• Imports. Verify vendor files and event lists before importing them.
• Re-checks. Report on records whose checked date is old and run them through Steps 2 to 4 again.

For a one-off check on a single lead before a call or an important email, the free email verifier shows the result and the reason for one address at a time.