Section 20 · Sales Rep Work Elimination / Zero-Entry CRM
20.10Email finding + verification
Partly built — finishing in Phase 1- No.
- 20.10
- DMA's reference
- Decision Book p.38
- Phase
- Phase 1
- Autonomy
- L2 · Prepare, then wait for approval
- DMA's decision
- Yes
What DMA asked for · Decision Book p.38
Find missing e-mail addresses and verify the ones we have.
Why it matters to DMA: Bounces hurt the sending domain; a good address is worth more than a good e-mail.
In our words, from DMA's Product Decision Book v3, page 38.
How we do it
- Built: verification. Every contact address is checked without sending anything: format, whether the domain accepts mail, disposable domains and role addresses. There is no mailbox probing.
- Outreach to an invalid address is refused in code; a risky one is held (and checked again daily) until a person chooses "send anyway".
- Not yet: finding new addresses. That needs a finder service DMA picks; found addresses would be verified the same way before use.
Already in place
- Verification of every address, enforced before sending.
What the later phase adds
- Finding missing addresses through a finder service DMA picks.
The flow
It plays on its own while it's on screen; hover or use the controls to pause or step through.
An address
A contact's e-mail.
- Nutshell
- Rule in code
- Stored data
Where the data goes
The same six stages on every page. Nothing reaches Nutshell except through the write gate.
- 1Nutshell
Source
Contact e-mail addresses from Nutshell.
- 2Sync
Copies Nutshell changes into the bridge database
Keeps the mirror current; a changed address is checked again.
- 3Bridge database
A copy of the CRM data, plus what the AI works out
One result per address: valid, risky, invalid or unknown, with the reasons and any person's "send anyway".
- 4AI
Claude models, only through DMA's own gateway
No AI model is involved: rules decide.
- 5Write gate
The only way back into Nutshell: checked, approved when needed, sent once
Nothing is written to Nutshell. Outreach to an invalid address is refused in code; a risky one is held.
- 6Nutshell
The system of record
Nutshell is not changed.
The tables behind it
Drawn from the POC's database catalogue: structure only, no data.
PK primary keyFK reference the database enforces (solid line)ID reference kept by id (dashed line)
| Table | What it holds | Columns |
|---|---|---|
| ai.email_verifications | Each contact address's check result (valid, risky, invalid) and why. | 10 |
How the tables connect (1)
| Column | Points to | Kept by |
|---|---|---|
| ai.email_verifications.run_id | agent.runs | The application (by id) |
Worked example
Synthetic demo data: every name, business and number is made up.
List verification in the POC today. The synthetic addresses use reserved test domains, so they pass as "not checked outside production".
Results
| Result | Addresses |
|---|---|
| Valid | 376 |
| Risky | 0 |
| Invalid | 0 |
In the running POC
Settings → Email: the sending domain, the warm-up and list verification.
- 1Checked live against a demo domain that has no email set up yet: all four checks fail, and each comes with the exact record to add.
- 2The warm-up: today's cap and the last 14 days.
- 3List verification: counts per result and per reason.
Dashboard · Settings → Email: sending domain, warm-up and list verification. Captured from the running POC on September 25, 2026; synthetic data.
See it live
Opens the exact screen in the running POC, in a new tab.
| Open | Where | What to try |
|---|---|---|
| Settings → Email health | DMA AI dashboard | List verification: counts per reason, and "send anyway" per address. |
Status
Partly built — finishing in Phase 1. The parts run in the POC today; the rule that joins them is being finished for Phase 1.