Section 19 · Safety, Deliverability & Governance

19.2Email verification and suppression

Built in the POC

What DMA asked for · Decision Book p.34

Cut bounces and honour unsubscribes across the whole system.

Why it matters to DMA: It protects the sending reputation the whole reactivation engine depends on.

In our words, from DMA's Product Decision Book v3, page 34.

Before a list is used, every address is checked: the domain must accept mail (MX), disposable and role addresses (info@, sales@) are marked, and people the notes say left or bounced are excluded.
Unsubscribes, bounces and complaints go on a suppression list, kept as hashes of the addresses. Every email of every kind checks it at the moment of sending, not only when it was approved.
Every email carries a one-click unsubscribe link, and the suppression applies everywhere at once: outreach, replies and any later campaign.
Outreach to an invalid address is refused; a risky one is held until a person chooses "send anyway", with a note, and that choice is logged.

It plays on its own while it's on screen; hover or use the controls to pause or step through.

Step 1 of 4

The list

A wave of 50 former clients.

The same six stages on every page. Nothing reaches Nutshell except through the write gate.

1Nutshell + replies
Source
Contacts, and unsubscribes or bounces as they arrive.
2Sync
Copies Nutshell changes into the bridge database
Keeps contacts current.
3Bridge database
A copy of the CRM data, plus what the AI works out
Verification results and the suppression list (hashes only).
4AI
Claude models, only through DMA's own gateway
Not needed: rules.
5Write gate
The only way back into Nutshell: checked, approved when needed, sent once
Can mark do-not-contact in Nutshell under its field rule.
6Nutshell
The system of record
Do-not-contact follows the person.

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	The result of checking each address, and any person's override.	10
ai.email_domains	Per domain: does it accept mail, is it disposable.	6
ctrl.suppressions	Addresses that must never be emailed, as hashes, with the reason.	4
ctrl.mail_log	Every email sent or held, with the governor's reasons.	18

How the tables connect (3)

Column	Points to	Kept by
ai.email_verifications.run_id	agent.runs	The application (by id)
ctrl.mail_log.approval_id	ctrl.approvals	The application (by id)
ctrl.mail_log.decision_id	ctrl.decision_log	The application (by id)

Synthetic demo data: every name, business and number is made up.

1 / 2

What you see

1.Email health

The sending domain's health, the send limits and the list checks, on one screen.

localhost:13301/settings?tab=email

What happens in the system

Addresses checked in the POC today (live counts on the synthetic sample). Outside the POC every address is checked against live DNS.

Result	Contacts
Addresses checked (all on reserved test domains in the POC, so marked valid without a live DNS check)	376
Left or bounced, from the notes (never emailed)	28

localhost:13301/settings?tab=email

Settings → Email health: the domain check, the warm-up limits 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.
2Warm-up: today's cap, what was sent, and the last 14 days of sends, bounces and complaints.
3List verification: every address checked; in the POC they are reserved test domains, marked as such.

Dashboard · Settings → Email: sending domain, warm-up and list verification. Captured from the running POC on September 25, 2026; synthetic data.

Opens the exact screen in the running POC, in a new tab.

Open	Where	What to try
Email health	DMA AI dashboard	Domain health, limits and list checks.

Built in the POC

Built in the POC. This capability runs in the POC today, on synthetic data, end to end.