An agent checks your contact list and reports that the job is complete. That sounds useful. But your campaign manager still needs to know which addresses can move forward, which need attention, and which should stay out of the campaign.

Here’s the starting rule: advance deliverable addresses to your remaining campaign checks, hold risky addresses for review, exclude undeliverable addresses from sending, and keep unknown results unresolved.

The opportunity isn’t simply to verify faster. It’s to give your agent a clear next step for every result, without asking someone to sort the same spreadsheet again.

That’s what this playbook is designed to help you do.

Verification Answers One Question. Your Agent Has To Answer Another

With the Emailable CLI, our command-line tool, an agent like Claude Code or Codex can verify a single address or an entire list from a plain-English request. The CLI is free to use, and new verifications draw from your Emailable credits.

Once your agent has the Emailable skill and approved access, a request can be as simple as “Verify this email with Emailable: sam@emailable.com.” Behind the scenes, the agent runs something like this:

emailable verify sam@emailable.com --json

Emailable answers the first question: how likely is this address to receive mail? Your agent then has to answer a second one: what should happen to this contact next? A deliverable result is a delivery assessment, not a campaign approval. It says nothing about whether the person opted in or unsubscribed last month. Your agent can only make that call if you give it the rules.

Read The Whole Result, Not Just The Label

Every Emailable response includes a state field with the main result: deliverable, undeliverable, risky, or unknown. The reason field explains why, a score from 0 to 100 adds supporting confidence, and flags like accept_all, disposable, role, and free add context. When Emailable spots a likely typo, did_you_mean suggests a correction.

Keep all of these values intact. Squeezing them into “good” or “bad” throws away exactly the context a reviewer will need later. Here’s a conservative starting policy to adapt:

Give Every Result A Next Step

1. Deliverable Means “Keep Checking,” Not “Send”

A deliverable result means Emailable has high confidence the address exists and can receive mail. It doesn’t establish marketing permission or guarantee inbox placement.

Say a webinar attendee has a deliverable address but unsubscribed from your newsletter in March. Your agent should keep both facts: the address passed verification, and the person still stays off the newsletter. A next-action field reading “continue campaign checks” captures that better than a “safe to send” label. A high score doesn’t change this, either. It supports the result, but it doesn’t replace your consent and suppression checks.

2. Undeliverable Means Stop Sending, Not Stop Thinking

Keep undeliverable addresses out of your sending audience, and record the specific reason: an invalid format, a domain that doesn’t exist, a rejected mailbox. Those differences matter when someone investigates where the bad data came from.

Maybe a sales rep copied an address wrong from a meeting note. Your agent can flag that record for correction, but it shouldn’t guess a similar-looking address, overwrite the original, or send a test email to see what happens. If Emailable returns a did_you_mean suggestion, park it in a review field for a person to confirm. And excluding an address from sending doesn’t mean deleting the customer record.

3. Risky Is a Decision to Make, Not a Verdict to Obey

Risky isn’t another word for undeliverable. It means there’s a quality concern or uncertainty that needs more context.

Accept-all domains are one of the most common causes. These servers accept mail for any address, so no verification service can reliably confirm whether a specific mailbox exists, which is why these addresses are usually classified as risky. Emailable’s optional accept-all check (the --accept-all flag) can sometimes resolve one to a firm deliverable or undeliverable result. When it does, keep that result.

The same label can justify very different decisions. An existing customer who replied last week and an unfamiliar address from an old prospecting list are both “risky,” but they don’t deserve the same treatment. Have your agent gather what a reviewer needs: the reason, the flags, the source, and any genuine relationship history.

Then give the review queue an owner, and record who approved what and why. That approval is a business decision; it never rewrites the verification result. And an empty approval field should keep a contact on hold, not quietly turn into a yes at the next export.

4. Unknown Means “Not Yet,” Not “No”

Unknown means the check couldn’t reach a confident answer at that moment. A timeout or a temporary problem at the receiving server can cause it, so it doesn’t mean the mailbox is fake. A real customer might sign up just as their company’s mail server is briefly down.

Keep unknown results out of automatic campaign selection and put them in a follow-up queue with limits: when to recheck, how many attempts are allowed, and who takes over if the answer stays unclear.

Also keep verification results separate from tool errors. A network failure or rate limit isn’t an unknown result, and since the CLI already retries rate-limited requests on its own, your agent shouldn’t wrap its own retry loop around one.

5. Disposable Addresses Need a Relationship Rule

Disposable addresses are temporary inboxes. They may accept mail today and disappear next week. If your service relies on account recovery or renewal notices, your policy might ask the user for a longer-term address. Keep the flag and original result intact, and let a person handle exceptions rather than having your agent ban accounts on its own.

6. Role-Based Addresses Depend on the Message

billing@, support@, accounts@. Role-based addresses belong to a function rather than a person, and many are perfectly deliverable. If a customer gives you their accounts-payable inbox for invoices, removing it would defeat the purpose. Dropping that same inbox into a personalized prospecting sequence would be a different mistake. Teach your agent to look at what you’re sending, not just the address type.

Don’t Pay To Verify The Same List Twice

The best time to verify is when an address first enters your workflow. At signup, the person is still there to fix a typo, which is exactly why verification belongs in your signup flow. For lists already in your system, have your agent work through three steps:

1. Check what already exists. Match each address against saved results and the date it was actually verified.

2. Find what needs checking. Separate new addresses, changed addresses, and results older than your freshness policy allows.

3. Get approval for the work. Confirm the scope and check your credits with emailable account status --json before running anything new.

Remember that the day you downloaded a file isn’t the day its addresses were verified. And if marketing asks for a deliverable-only export on Monday and a risky review file on Tuesday, Tuesday’s request doesn’t need a second verification. Filtering saved results doesn’t use any credits.

What This Looks Like On A Real List

In our Claude Code test, the batch ran with a command along these lines:

emailable batch verify contacts.csv --field email --wait --json

The results were saved as bulk-verified.csv. These numbers reflect that specific list, not a benchmark; a list with lots of accept-all business domains will naturally return more risky results. Later, a follow-up request pulled the 38 risky addresses from the existing batch without a new verification:

emailable batch get <batch-id> --wait --jq '.emails[] | select(.state == "risky")'

That’s the payoff. Once results exist, your agent can reuse them at no extra cost. A natural next request would be “Sort my saved verification results into separate files, keeping the reasons.” The original results stay alongside those files, so anyone opening the review file can see why each contact is there.

Turn Your Rules Into A Reusable Skill

A skill is a set of instructions an agent can reuse. Emailable’s installed skill teaches tool use; your results-triage rules define how that tool’s findings fit your workflow.

You don’t need a long prompt for every task. Give the reusable skill three clear responsibilities:

1. Know when to start and what to read. Trigger after a batch completes or when someone requests a review of saved results. Require the correct source, address or record identifier, state, reason, and any flags needed by the policy. Missing evidence goes to exceptions.
2. Apply the decision table and explain the output. Preserve original values, add a separate next action, and create clearly named candidate, review, exclusion, and unresolved outputs. Record the rule version, source, counts, and saved locations.
3. Stay within boundaries and prove the split. Set a credit budget, require approval for fresh verification, and reuse existing batch IDs for retrieval. Keep sending, deletion, and live CRM changes outside this triage task unless separately authorized.

An interrupted job needs a recovery rule, too. Check the existing batch before submitting the same list again. A missing summary does not establish that verification failed. Ask for help when the outcome cannot be confirmed, rather than spending credits on a guess.

Use actual permission controls alongside written instructions, and keep credentials and unnecessary contact details out of prompts and screenshots.

Treat unexpected results explicitly. Emailable also documents a list-specific duplicate result. Don’t drop duplicates or unfamiliar values merely because your first example contained four categories.

Before trusting the skill with a larger list, test it on an authorized sample. Check that every source row is accounted for, original states remain unchanged, and missing information produces a hold rather than an approval.

Reopen the outputs. A claimed export isn’t enough; the contents need to match the rule.

Better Automation Gives Every Result A Next Step

The aim isn’t an agent that always says yes. It’s an agent that moves clear cases forward, explains uncertain cases, and knows when to stop. Start with one verified list. Agree on the decisions, preserve the evidence, and inspect the handoff before expanding the workflow.

That’s how verification becomes more than a finished check. It becomes a repeatable part of how your team works, with fewer unexplained decisions left for the next person.