Section 19 · Safety, Deliverability & Governance

19.3Sending reputation protection

Built — needs DMA's data

What DMA asked for · Decision Book p.34

Send from proper infrastructure, and watch the domain's health before scaling reactivation.

Why it matters to DMA: A burned sending domain would undermine every email capability in the book.

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

Every email goes through one send governor. It enforces a daily cap, a warm-up ramp (small volumes first, rising only while the numbers stay healthy) and a per-inbox cap, at the moment of sending.
Bounces and complaints are counted per sending pool; crossing the limit pauses that pool automatically, and a person has to resume it.
Email health checks the sending domain's SPF, DKIM, DMARC and MX records and shows them on one screen.
In the POC all mail goes to a test inbox; the real sending domain and its DNS records come from DMA (on the kickoff checklist).

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

Step 1 of 3

An email

Day 3 of warm-up: the ramp allows 40 today.

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

1Outreach and staff mail
Source
Every email the system sends.
2Sync
Copies Nutshell changes into the bridge database
Not involved.
3Bridge database
A copy of the CRM data, plus what the AI works out
Daily counters, ramp stage and pause state per pool.
4AI
Claude models, only through DMA's own gateway
Not involved.
5Write gate
The only way back into Nutshell: checked, approved when needed, sent once
Sent prospect emails are logged to Nutshell as activities.
6Nutshell
The system of record
The rep sees what was sent.

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
ctrl.send_counters	Per sending pool and day: sent, bounced, complaints, ramp stage, paused.	9
ctrl.mail_log	Every email sent or held, and why.	18

How the tables connect (2)

Column	Points to	Kept by
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.Domain health

SPF, DKIM, DMARC and MX for the sending domain.

localhost:13301/settings?tab=email

What happens in the system

A designed warm-up (synthetic example; the real ramp is set with DMA).

Stage	Daily cap	Moves up when
1	20	Bounces under 2% and no complaints for 3 days
2	50	Same, for 3 more days
3	100	Same, for a week

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	The domain checks and the send limits.

Built — needs DMA's data

Built — needs DMA's data. This capability runs in the POC today. It needs DMA's own content or data to go live; no code change is needed for that.