# Verify emails in Salesforce with Spaw

Verify new Salesforce leads and contacts through Zapier or Make, store the verdict in custom fields, and clean existing records with a bulk run.

Updated: 2026-09-03

Salesforce orgs collect addresses through web-to-lead forms, list imports and integrations, and a bad address on a lead costs a rep's time before it bounces. Spaw does not publish an AppExchange package. The recommended path is a Zap or a Make scenario that triggers on a new lead or contact, verifies the address, and writes the verdict into custom fields that your reports, list views and flows can use.

## Prepare the org

1. Add three custom fields to Lead, and the same three to Contact if you verify both: a picklist or text field for the verdict, a text field for the reason, and a number field for the risk score. Names such as `Email_Verdict__c`, `Email_Verdict_Reason__c` and `Email_Risk_Score__c` read well in reports.
2. Create a secret API key on the API keys page of your Spaw dashboard.

## Verify new records as they are created

1. In Zapier or Make, start with the Salesforce trigger for a new record and choose the Lead object (or Contact).
2. Add the verification step: a Webhooks by Zapier POST or a Make HTTP request to `https://spaw.co/api/v1/email` with the header `Authorization: Bearer sk_live_…` and this body, mapping the record's email:

```json
{
  "email": "mia@acme.com"
}
```

The [Zapier page](/integrations/zapier) and the [Make page](/integrations/make) walk through the exact settings. When the Spaw apps for both platforms are listed, the step becomes a Verify Email action with a saved connection; the fields do not change.

3. Add a filter so records without an email are skipped.
4. Add the Salesforce action that updates a record, pick the same object, match on the record id from the trigger, and map `data.deliverable`, `data.reason` and `data.risk_score` into the custom fields.
5. Test by creating a lead with the address `deliverable@spaw.test`, one of six free test addresses that answer a fixed result and never appear in your history.

Teams that prefer to stay inside Salesforce can call the same endpoint from Apex with a Named Credential holding the bearer token; the [OpenAPI document](/integrations/openapi) describes every request and response for that work. This page keeps to the no-code path.

## Clean existing leads and contacts

Export the addresses with their record ids, run the file through a bulk verification on the Spaw dashboard or with the [bulk endpoint](/docs/api/create-bulk-job), and load the result CSV back with a data loader, matching on the id. The result keeps your original columns and adds the verdict, reason, risk score and suggestion columns, so the mapping is one to one. Undeliverable rows also land on your Spaw suppression list, which later batch and bulk runs answer for free.

## What to do with the verdict

Build list views and assignment rules on the verdict field. `deliverable` leads route to reps as usual. `risky` leads deserve a look at the reason before a sequence: `catch_all` means the domain accepts every address and the mailbox is unconfirmed, `role` means a shared inbox, `disposable` means a throwaway domain. `undeliverable` leads should be flagged rather than deleted, because a filled `data.did_you_mean` value, for example `mia@acme.com` for `mia@acme.cmo`, is often a lead worth one correction. A validation rule or flow can block a lead from converting while the verdict is undeliverable.

## Cost

Each new record that answers deliverable or risky spends 1 credit; undeliverable answers and repeats within seven days are free, as are the test addresses. Zapier and Make bill their own tasks. A bulk run bills per row as it is processed and verifies duplicates once.

Reference: https://spaw.co/integrations/salesforce