The safest email send happens twice.

Before an AI email agent sends to real people, it should rehearse the exact action in an environment that cannot create the external effect. The rehearsal resolves the audience, applies exclusions, renders every material variant, validates links and headers, checks schedules and connected automations, simulates provider outcomes, and produces a receipt tied to one immutable campaign digest.

The rehearsal is not a smaller send. It is evidence about the send.

The live operation remains separate. A person or policy can inspect the preflight receipt, approve that exact version, and authorize one execution. If the audience, content, sender, schedule, or another material field changes, the evidence no longer describes the thing waiting to be sent.

We rehearse consequential things because imagination is a poor substitute for state. A campaign may look finished in an editor while its audience query resolves to twice the expected count. The unsubscribe link may work in the default variant and disappear in a conditional block. The discount may render correctly for one locale and expose an empty field for another. A retry path may turn one timeout into two receipts.

An agent can read the plan and predict that these things are unlikely. Preflight asks the system to calculate them. The difference matters. Prediction produces reassurance; rehearsal produces artifacts: counts, hashes, rendered outputs, HTTP results, policy decisions, simulator events, warnings, and failures.

The first “send” therefore remains inside a closed loop. No customer is eligible. No production webhook advances a journey. No revenue attribution event is written. The loop uses controlled recipients or simulators, captures the resulting evidence, and exits with either a verified campaign artifact or a bounded reason to stop.

A preview URL is not a campaign. Neither is the HTML. The thing being approved must include every field that can change who receives the message, what they see, when it is sent, what it costs, and which systems react afterward.

Serialize the material fields canonically and hash them. That digest becomes the identity shared by preflight, approval, and execution. This is the practical extension of showing an approver the exact diff before action. If the digest changes, show the new diff and invalidate only the checks whose inputs changed.

1. 01

   Resolve the audience

   Materialize the eligible recipients from the frozen query. Compare the result with the approved baseline, historical range, and campaign limit.

2. 02

   Apply every exclusion

   Check unsubscribes, complaints, hard bounces, global and workspace suppressions, consent scope, frequency caps, quiet cohorts, and account-level blocks after inclusion logic.

3. 03

   Verify the sender

   Confirm the From and reply-to identities, domain and stream, SPF and DKIM state, DMARC alignment expectation, TLS path, and provider readiness.

4. 04

   Inspect message headers

   Validate Internet Message Format, list identity, one-click unsubscribe fields where required, trace identifiers, and the absence of unsafe or conflicting headers.

5. 05

   Render every material branch

   Generate HTML and plain text for each locale, template branch, dark-mode treatment, missing-value fallback, and representative content extreme, not only the happy path.

6. 06

   Exercise links and destinations

   Resolve redirects, require safe protocols, confirm the intended hostname and final status, preserve required variables, and inspect tracking parameters without treating a scanner request as human intent.

7. 07

   Check timing and collisions

   Evaluate timezone, quiet hours, approval expiry, rate limits, frequency policy, and other campaigns or automations that could contact the same person in the same window.

8. 08

   Rehearse transport outcomes

   Simulate acceptance, bounce, complaint, suppression, automatic response, provider rejection, timeout, and duplicate webhook delivery. Verify that each result enters the right state once.

9. 09

   Observe controlled placement

   Where appropriate, send the frozen rendering to controlled mailboxes and record observed placement, authentication, clipping, and image behavior with the scope of that evidence attached.

10. 10

    Reconcile the receipt

    Require every mandatory check to report against the same digest. Expire stale evidence, separate warnings from failures, and make the blocked next action explicit.

A single green “ready” badge conceals which fact was checked. Keep the layers separate so a passing render does not disguise a failing permission rule, and a successful provider simulation does not imply healthy placement.

A successful test delivery is the least interesting branch. The expensive bugs live in ambiguous outcomes: a provider accepted the request but the application timed out; the same webhook arrived twice; a bounce preceded a delayed delivery event; a suppression changed between audience resolution and execution.

Amazon SES documents simulator addresses for successful delivery, bounce, complaint, automatic response, and suppression-list behavior. The point is not that every platform must use those addresses. The useful pattern is to expose the state machine to representative provider outcomes without inventing customer addresses or damaging reputation metrics.

Assert the application response, not merely the provider event. A bounce should suppress the right address with the right scope. A complaint should stop applicable marketing. An automatic reply should not invite a send retry. A timeout should enter an unknown outcome and reconcile by provider identifier or idempotency key, because a retry is not permission to send twice.

A clean preflight does not guarantee inbox placement. SPF, DKIM, and DMARC establish identity and alignment properties; they do not reserve the inbox. A controlled mailbox shows what that mailbox observed under those conditions. It does not tell you what every provider will decide for every recipient.

It also does not prove attention, persuasion, or incremental revenue. An open can be an automated image request. A click can come from a scanner. An order can occur inside an attribution window without being caused by the message. The rehearsal should protect the action it can inspect, then preserve the distinctions needed for honest measurement afterward.

This limit makes preflight more valuable, not less. It prevents a finite engineering check from growing into a ceremonial guarantee. The receipt should say exactly what passed, which environment produced the result, how fresh it is, and what remains uncertain.

The agent can coordinate the work: select the required checks, explain a failure, propose a bounded repair, and assemble the evidence. The application should calculate recipient counts, enforce suppressions, validate protocols, compare digests, call simulators, and decide whether a mandatory policy passed.

These transitions belong in the same stopping contractused by the broader agent loop. Preflight is not a place where the model can lower a threshold because the campaign is almost ready.

The receipt is the bridge between rehearsal and authority. Without it, the reviewer sees a green badge and must trust whichever system produced it. With it, the reviewer can inspect the exact plan and the evidence behind each result.

Keep the output finite. Link to full renders and event evidence instead of pasting logs into the approval screen. Rank failures first, show warnings with their consequence, and identify the smallest action that can make the campaign reviewable again.

A preflight should not end with a score like 92 out of 100. Scores invite people to trade unrelated checks against one another. A perfect render cannot compensate for missing consent. A valid DKIM signature cannot compensate for a broken unsubscribe endpoint.

“Go” is permission to execute one bound version, not a permanent reputation certificate. Check time-sensitive invariants again at the live gate: digest identity, approval validity, suppression freshness, incident state, schedule, and idempotency. Then send once and reconcile the provider receipt.

Moosewave keeps the campaign plan, audience state, content versions, preflight results, approval, execution, and delivery evidence inside one accountable run. The agent can prepare the work quickly while the product preserves the boundary between rehearsal and live effect.

Start with the current audience and exclusions, render the selected template, inspect authentication and controlled placement in deliverability, and check whether connected automations create another message or state transition. Transactional paths can exercise bounded provider outcomes through the email APIwithout collapsing acceptance, delivery, bounce, complaint, and unknown outcomes into one status.

See the sequence in the interactive product walkthrough, or inspect how Claude, Codex, and other compatible clients can prepare work through the Moosewave MCP layer while the live send remains a separately authorized tool action.

• Google, Email sender guidelines. Current authentication, DNS, TLS, formatting, spam-rate, alignment, one-click unsubscribe, and monitoring requirements for mail sent to Gmail accounts.
• Yahoo Sender Hub, Sender best practices. Authentication, complaint, DNS, segmentation, list management, and unsubscribe guidance.
• IETF RFC 5322, Internet Message Format. Message structure, field syntax, line limits, and message identifiers.
• IETF RFC 8058, One-click unsubscribe. The HTTPS POST mechanism and required list-email signaling.
• Amazon SES, Sending test email with the mailbox simulator, and how SES sending works. Controlled success, bounce, complaint, automatic reply, suppression, acceptance, and feedback-loop behavior.
• W3C, Web Content Accessibility Guidelines 2.2. A useful baseline for distinguishability, text alternatives, structure, and interaction checks in linked experiences and compatible email rendering.

Sources checked 23 August 2026. Provider requirements can change; the linked primary source takes precedence until this article is reviewed again.