Salesforce will store any email you put in it. It will not tell you which ones still work. An address that looks fine in a Salesforce field can be dead, and you only find out when it bounces. Reps and sequencers send to whatever the record holds, so a list full of stale or mistyped addresses quietly burns your sending domain.
The fix is not a one-time scrub. You verify the emails already in Salesforce, write the result back to each record, suppress the bad ones, and re-check on a schedule. This is how to verify email addresses inside Salesforce without sending a single test email.
Step 1: Pull the Salesforce records you want to verify into Clay
Start with the records that actually get emailed, not your whole org. The contacts and leads your sequencers touch are where a bounce hurts.
Use Clay's Salesforce integration to import the objects you want to check, ideally filtered to an active segment instead of every record. The import brings each record's Salesforce Record ID alongside its email. That ID is the key you write the verification result back to later. Pulling a defined slice also keeps your verification credits pointed at addresses you will really send to.
Step 2: Verify each address without sending an email
Verification checks whether a mailbox will accept mail, without actually emailing it. The result is a status, not a guess.
Clay runs each address through an email verifier (providers like ZeroBounce, Findymail, LeadMagic, and Hunter) and returns one of five statuses. The address that looks perfectly normal is exactly the one that catches teams out, because formatting tells you nothing about whether the mailbox is live.
Run verification on each address to see the verdict behind a normal-looking email
Mailbox exists and accepts mail
Safe to send
Formatting tells you nothing about deliverability. Only the verification status reveals whether a Salesforce address will actually accept mail, and the one that looked fine is often the dead one.
Step 3: Resolve the catch-all addresses
Catch-all domains are the gray area. They accept any address at the domain, so a standard check cannot confirm whether a specific mailbox exists.
A lot of corporate domains are catch-all, so leaving every amber row as a coin flip throws away reachable contacts. Run the catch-all rows through a dedicated catch-all verifier (providers like Findymail and LeadMagic) that returns a confidence read instead of a shrug. The ones it clears with high confidence become sendable; the genuinely risky ones stay flagged.
The same address: a standard check vs a dedicated catch-all verifier
m.lee@catchall-co.comOn a normal domain the server confirms this exact mailbox exists.
ZeroBounce benchmark99.25%
accuracy
99.37%
coverage
A standard check confirms a normal mailbox outright. On a catch-all domain a dedicated catch-all verifier still clears most addresses with high confidence, so you recover reachable contacts instead of discarding every amber row.
Step 4: Write the status back to Salesforce and suppress the bad ones
A verdict that lives in Clay protects no one. It has to land on the Salesforce record and change what gets sent.
Write the status to a custom field with the Update record action, keyed on the Salesforce Record ID. Because the ID points at one record, the write updates it in place and never creates a duplicate. Writes cannot be undone, so test against the Salesforce Test Env first, and map only the status field. Then make the field do work: filter your sequencer and rep views to Valid only, and flag Invalid and Role-based so nobody emails them. The verification is only worth running if it changes who receives a send.
Auto-plays verified to write-back to suppression to send. Click a node to inspect it.
Verified in Clay
Each address carries a status: Valid, Invalid, Catch-all, Role-based, or Unknown
Hands to Write to Salesforce: 1,000 records checked, each with a status
The status only protects your domain once it is written to the record by ID and used to suppress the bad addresses before any send.
Step 5: Re-verify on a schedule, because addresses decay
A list verified once is accurate for a while, then it is not. People leave, mailboxes get deactivated, and a clean address from last quarter starts bouncing.
Turn on auto-update so the verification re-runs on a cadence and the status on each Salesforce record stays current. A monthly re-check on your active segments keeps the worst surprises out of your sends. The same status field then quietly does its job on every send without anyone re-exporting a list.
The recurring verification loop. Click a node to inspect it.
Pull active records
Import the active segment with Record IDs
Email verification is a maintenance loop, not a one-time scrub: pull, verify, write the status by ID, and re-run on a cadence.
Teams that verify before they send protect the domain that everything else depends on.
increase in cold email performance Rippling saw after building enriched, verified data into its outbound on Clay
Read the full storyCommon failure modes, and how to avoid them
Most verification efforts slip in four predictable ways.
- Treating bounces as the verification step: Sending to unverified records and reading the bounce-backs is what damages the domain in the first place. Verify before the send, not after it.
- Discarding every catch-all address: Throwing away every amber row tosses reachable contacts a dedicated catch-all verifier would clear. Resolve them, do not delete them.
- Verifying in Clay but never writing the status back: Salesforce still looks clean and reps keep emailing the dead ones. Write the result back to the record by ID so it changes who gets a send.
- Verifying once and never again: The list rots between scrubs as people change jobs. Turn on auto-update so the check re-runs on a schedule.
Outcomes teams report after building clean, verified data on their CRM with Clay
What teams report after building verified data on their CRM with Clay