Validate Contacts

Sending to addresses that can’t receive mail raises your bounce rate. Bounce rate is one of the two metrics that decide your sending reputation. Validation runs a real deliverability check on your contacts before an email goes out. Each address comes back with one of three verdicts:

• Valid. The mailbox exists and accepts mail.
• Risky. Deliverable, but worth a look: a role account (info@, support@), a disposable address, or a catch-all domain that accepts everything.
• Invalid. The address can’t receive mail. Don’t send to it.

Every result carries a machine-readable reason and, where a typo looks likely, a didYouMean correction (gamil.com to gmail.com). The verdict is saved on the contact, so a list you validated stays validated. A contact that was never checked has no verdict. Brew’s free format check only flags what it can see without a deliverability check: risky addresses (disposable or role) and invalid ones. Only a real check marks an address valid, and a checked contact also records when it was checked (lastValidatedAt). Each checked address costs 2 credits, drawn from the same credit balance as AI email generation. It’s charged only when the check completes.

​

From an Audience

The most credit-efficient way to validate. Open the audience. Then click the three-dot menu in the top right corner of the view (next to Download CSV) and choose Validate contacts. Every contact in that audience is checked.

​

On CSV Import

The CSV import has a validation checkbox. Tick it and every address in the file is deliverability-checked as it’s ingested, so bad addresses never enter your list unflagged.

​

When Adding a Contact Manually

The add-contact form has the same checkbox. Tick it and the address is checked as it’s saved.

​

From MCP

If Brew is connected to your AI client, the easiest flow is to ask for your audiences, pick one, and validate it:

“List my audiences.”

“Validate the contacts in the newsletter audience.”

The agent lists audiences with list_audiences (or the brew://audiences resource), reads the chosen audience’s addresses with search_contacts and its audienceId, and passes them to validate_contacts, up to 100 per call. It replies with the verdict counts and the addresses that came back risky or invalid. The update_contact tool takes the same opt-in validation (validate: true) as the UI checkboxes. update_contacts_csv doesn’t validate, so call validate_contacts after a bulk update.

​

From the API

The same check is available on three endpoints:

• POST /v1/contacts/validate checks up to 100 addresses at once and writes the verdict back onto matching contacts. Each result carries risk, isDisposable, and isRole signals alongside reason and didYouMean.
• POST /v1/contacts and POST /v1/contacts/import-csv accept an optional validate: true to check each address as it’s ingested. Up to 100 addresses validate inline; larger submissions upsert first and validate as a background job, returning a validationJobId.

In the TypeScript SDK it’s brew.contacts.validate(...), and the ingestion methods take the same validate flag. The contact’s verdict field is named validationStatus. If a check can’t complete, the call returns a retryable 503 and you are not billed.

​

What to Do with the Verdicts

• Valid contacts need nothing. Send as usual.
• Risky contacts deserve a look before a big send. Role accounts rarely engage, disposable addresses churn fast, and catch-all domains can’t be confirmed either way. Consider excluding them from your primary sending audience.
• Invalid contacts should leave your active audience. Sending to them produces hard bounces, and hard bounces hurt every future send. See Audience Hygiene for the wider cleanup routine.

​

Need Help?

Our team is ready to support you at every step of your journey with Brew. Choose the option that works best for you: