Keep unresolved accept-all addresses out of automatic campaigns, but don’t automatically discard them. Preserve the verification result, then decide what to do next based on the contact’s source, relationship, and intended use.

Imagine your agent finishes checking a prospect list. Some addresses can move forward. Others clearly belong outside the campaign. Then there’s a group marked risky because their domains accept mail without reliably confirming individual mailboxes.

Should those contacts disappear? Should they enter the same sequence as everyone else?

Neither decision should happen by default.

This is where a useful agent becomes more than a sorting tool. It brings together verification evidence and your team’s rules, handles routine decisions, and gives people a clear explanation when judgment is needed.

What Does Accept-All Actually Mean?

An accept-all domain, often called a catch-all, accepts mail for any address at that domain, whether the mailbox exists or not. So, when the server says “yes,” it isn’t confirming the specific address.

Think of a reception desk that signs for every package, whatever name is on the label. The package getting through the front door doesn’t tell you whether that person actually works upstairs.

Companies set this up for good reasons. Google Workspace, for example, lets organizations route mail sent to mistyped addresses into one shared mailbox so nothing gets lost. It isn’t a sign of a fake business; the domain just won’t confirm or deny individual mailboxes.

That’s why most accept-all addresses come back as risky. Emailable can sometimes reach a firm deliverable or undeliverable result for an address on an accept-all domain, and when it can’t, the address stays risky. Your agent should keep that distinction instead of labeling every accept-all address the same.

Read The Whole Result Before Choosing An Action

Emailable returns a verification state, a reason, and extra fields like accept_all, role, and disposable. The state is the overall verdict; the other fields add context.

Read the reason and flags together. An address can have more than one concern, like an accept-all domain and a shared inbox at the same time, so don’t assume the domain setting explains everything.

Here’s a starting policy for accept-all addresses:

These are workflow decisions. They never replace the verification result, and that matters because unknown doesn’t mean invalid, and risky doesn’t mean undeliverable.

Scores aren’t a shortcut, either. Emailable’s score supports the state rather than replacing it, so your own score threshold should never quietly turn risky into deliverable.

Finally, make sure the right check actually ran. The Emailable CLI includes an optional accept-all check for single-address verification (the --accept-all flag). If that check didn’t run, the information is missing, and missing information should stay missing rather than becoming an assumed “no.”

One Result, Three Different Decisions

A new signup, a fresh prospect, and an existing CRM contact can all share the same unresolved accept-all result and still need completely different next steps. The scenarios below show proposed handling rules, not customer outcomes or automatic Emailable behavior.

1. Signups: Confirm Access Instead of Calling the Address Fake

Rita signs up for your software trial with her work email, and the result comes back risky with an accept-all flag.

Rejecting her outright could turn away a real customer, while unlocking every feature assumes the opposite. A better policy keeps the signup pending while your app sends its normal confirmation email, with a way to correct the address or reach support if it fails.

Keep one distinction clear. A confirmation email proves someone can access the address. It doesn’t prove who they are or what role they hold at the company.

Your agent’s note might read: “The mailbox result is unresolved. Continue through the approved confirmation process rather than rejecting the signup.” That step belongs to your app’s signup flow. It doesn’t let the agent send test emails on its own.

2. Outbound: Let Evidence Lead, Not a Promising Company Name

Now say the same kind of address arrives through a prospecting workflow. There’s no signup, no previous conversation, and no request to be contacted.

The company may be a perfect fit. That’s a good reason to prioritize research, but it doesn’t answer the mailbox question. A cautious outbound policy keeps the address out of automatic sequences and has the agent pull the evidence together for review: where the address came from, when it was collected, whether that exact address has any genuine reply history, and which permission or suppression records apply.

A contact who replied last week asking for a proposal gives a reviewer very different context from a newly guessed address, though it still doesn’t change the saved result.

Contacts at the same company don’t inherit each other’s evidence, either. A reply from one person doesn’t validate a guessed address for their colleague. Grouping by domain is a good way to organize review, but it’s not a way to approve every mailbox at once.

The question that matters isn’t whether the company is important. It’s whether there’s a documented reason to continue.

3. CRM Imports: Keeping a Record Isn’t the Same as Contacting It

Your customer success team is importing account contacts before renewal season, and an existing customer’s address comes back as an unresolved accept-all result.

Deleting the contact could wipe out useful relationship history, but importing it as campaign-ready hides the uncertainty. Under an approved import policy, the agent can import the record with its result, account owner, and relationship notes attached while keeping it blocked from automatic campaigns.

A renewal contact with an active conversation could go straight to the assigned customer success manager. A newly imported contact with no source history could stay pending until the owner adds more information.

Keep separate fields for verification, relationship context, and sending eligibility. Saving a contact and approving a message are different decisions, and your import workflow should keep that line visible.

What Our Test Showed

In our Claude Code test, 38 of the 77 addresses came back risky. Looking closer, 31 were catch-all addresses, and 7 were generic or shared inboxes. Those numbers describe this one list, not business email in general.

That breakdown changes the work. “Show me the risky addresses” is a useful first filter, but the reason and flags explain why each record needs attention. A catch-all address at a known customer and a shared info@ inbox on a cold list call for very different reviews.

The agent also pulled these results from the completed batch instead of running a new verification. The existing results were all this step needed, so no extra credits were spent.

That’s the value of keeping the supporting fields. Every review starts with a reason, not just a pile of addresses.

Turn Your Accept-All Rules Into A Skill

A triage skill should turn these principles into consistent decisions. It shouldn’t give the agent room to improvise.

Trigger it when a verification result includes an accept-all flag, or when someone asks to review accept-all records in an existing file. Give it the original results, the intended use, and the relevant source, relationship, and permission records. If supporting records are missing, turn them into questions for a person, not invented answers.

The skill applies your decision table and use-case rules, then writes a separate review file. It keeps the original state and reason, adds the proposed action, explanation, reviewer, and decision date in their own columns, and leaves approval fields blank until a real person fills them in.

With that in place, the everyday request stays simple:

“Save my risky accept-all contacts in a separate review file, keeping their original results.”

Spell out the safeguards, too: keep source files intact, avoid duplicate batches, require approval before any fresh verification, set a credit budget, and don’t allow sending or CRM changes without authorization.

Before you rely on it, run the skill on an authorized real list as a dry run that only writes review files. Check that every source row is accounted for, original results are unchanged, and blank decisions stay pending.

Give Reviewers A Question, Not Just A List

“Please review” isn’t a handoff. A good review queue tells the person exactly what they need to decide, with something like: “This address is risky with an accept-all flag. It came from this source. Here’s the relationship history we have. Our outbound rule requires approval, and none is recorded.”

Bring a person in when:

1. The evidence conflicts, such as a recent conversation alongside a new negative result.

2. Someone asks for an exception, like contacting an unresolved high-value lead.

3. The next step goes beyond what’s approved, including extra verification spending or a live CRM change.

Give every case an owner and a review deadline. A missed deadline should leave the contact pending, never approved.

Rechecks need limits as well: when a new verification is justified, how many attempts are allowed, and how many credits it can use.

And even an approved exception has to respect unsubscribe and do-not-contact records. Mailbox verification isn’t a subscription decision, and Google’s sender guidelines treat opt-in and easy unsubscribes as separate requirements.

Good Judgment Beats A Cleaner Dashboard

Accept-all handling should not be a contest to approve the most addresses or remove the most uncertainty from a dashboard.

The useful outcome is a clear next step: a signup awaiting confirmation, a prospect held for evidence, or a customer record preserved without triggering an unwanted campaign.

Start with one verified list and one written policy. Keep the evidence visible, make exceptions explicit, and test the handoff before expanding the workflow.

Good agents do not need to pretend every answer is certain. They need to make the next decision understandable.