Safe Outbound Email and Messaging

Generate, approve, send, reconcile, and audit person-directed communication without wrong recipients, leaked data, duplicate sends, or fabricated commitments.

The result you're building

A messaging workflow that resolves recipients, separates drafting from sending, scans sensitive content, binds approval to the final message and attachments, sends idempotently, and verifies delivery state without misrepresenting identity.

Use this guide when

• An agent drafts or sends email, Slack, SMS, direct messages, or invitations.
• Messages contain client, financial, legal, personal, or account information.
• Duplicate or wrong-recipient delivery would cause material harm.

Do not use it as a substitute for

• Guessing a recipient from display name or an old thread.
• Letting the agent promise price, scope, deadlines, refunds, legal positions, or authority that was not supplied.

Before you change anything

• Collect these items first. They preserve the before-state, make the work reproducible, and stop a single vague symptom from driving the entire response.
• Sender identity, permitted channel, organization, and delegated authority.
• Resolved recipient IDs/addresses, relationship, and current consent.
• Final subject/body/attachments with hashes and sensitivity labels.
• Approval identity, payload digest, expiry, send key, and scheduled time.
• Provider response, message ID, sent-item record, bounce, complaint, opt-out, and duplicate tests.

Understand the system before fixing it

Capability is not authority
A tool may be technically able to act while policy, budget, ownership, or user intent still forbids the action. Keep execution permission explicit and revocable.

Deterministic boundaries contain probabilistic reasoning
Models may propose plans, but schemas, allowlists, budgets, approvals, idempotency, and postconditions must decide what can actually happen.

Drafting and sending are different capabilities
Text generation can be low risk; external delivery uses identity and creates consequences. Put recipient resolution and approval outside the model.

Provider acceptance is not human receipt
A 2xx response may mean queued. Track message ID, delivery, bounce, complaint, and reply separately.

Evidence-to-decision map

Step-by-step procedure

Work in order and retain the output from each step. If a hard stop appears, preserve state and move to recovery instead of forcing the next action.

Step 01 — Define sender authority and message class

Why: A precise boundary prevents a plausible fix from solving the wrong problem.

Do: Separate draft, internal note, transactional, support, legal, marketing, and person-directed external messages. Declare allowed identity, channel, commitments, and approval tier.

Read the result: Each message class has an accountable sender and enforced policy.

Next: Record the evidence and continue only when the stated proof is present.

Step 02 — Resolve recipients to stable identities

Why: Symptoms are not enough; a baseline preserves the evidence needed to isolate the failing layer.

Do: Match address or platform ID, organization, role, relationship, and current consent. Present ambiguity to the user instead of choosing.

Read the result: Every To/Cc/Bcc recipient is verified and intended.

Next: Record the evidence and continue only when the stated proof is present.

Step 03 — Build the factual payload

Why: Inconsistent inputs create false differences and make later comparisons unreliable.

Do: Generate from supplied facts and cite internal sources where useful. Flag prices, dates, promises, legal positions, payment directions, and sensitive data for review.

Read the result: Unsupported commitments and fabricated facts are absent.

Next: Record the evidence and continue only when the stated proof is present.

Step 04 — Scan final content and attachments

Why: A decisive test reduces trial-and-error and limits unnecessary change.

Do: Inspect data classification, thread history, links, domains, file type, malware, metadata, and hashes. Strip unrelated quoted content and hidden recipients.

Read the result: Only necessary approved data and exact approved files remain.

Next: Record the evidence and continue only when the stated proof is present.

Step 05 — Bind approval and schedule

Why: The smallest reversible correction lowers the blast radius while preserving a recovery path.

Do: Canonicalize sender, recipients, channel, subject, body, attachments, commitments, send time, and expiry. Any material edit invalidates approval.

Read the result: Approval digest matches the final send payload.

Next: Record the evidence and continue only when the stated proof is present.

Step 06 — Send idempotently and reconcile

Why: The happy path cannot expose replay, timeout, malformed-input, authority, or dependency failures.

Do: Use a stable client message key when supported, retain provider/message ID, and check sent state before retrying a timeout.

Read the result: One approved payload produces at most one external message.

Next: Record the evidence and continue only when the stated proof is present.

Step 07 — Process delivery, replies, and opt-outs

Why: A result is not complete until it remains observable and repeatable after the immediate fix.

Do: Track queued/sent/delivered/bounced/complained/replied state; update suppression immediately; limit retention of content and session data.

Read the result: Delivery state is accurate and future sends honor current consent.

Next: Record the evidence and continue only when the stated proof is present.

Operational worksheet

Evidence record

• Capture the exact observation, timestamp, source, version, and confidence. Sanitize credentials and personal data before sharing the record.
• Sender identity, permitted channel, organization, and delegated authority.
• Resolved recipient IDs/addresses, relationship, and current consent.
• Final subject/body/attachments with hashes and sensitivity labels.
• Approval identity, payload digest, expiry, send key, and scheduled time.
• Provider response, message ID, sent-item record, bounce, complaint, opt-out, and duplicate tests.

Acceptance scoreboard

• Sender identity, channel, message class, and delegated authority are explicit.
• Every recipient resolves to a stable verified identity and current consent state.
• Claims, commitments, links, quoted history, sensitive data, and attachments pass review.
• Approval binds the exact final recipients, content, files, and schedule.
• Ambiguous provider outcomes reconcile before retry and cannot duplicate delivery.
• Bounce, complaint, reply, and opt-out state update the authoritative record.

Minimum handoff record

• Versioned safe outbound email and messaging scope, owner, exclusions, and success criteria.
• Sanitized evidence snapshot with source, time, version, and confidence.
• Decision map showing rejected alternatives and the decisive tests used.
• Ordered action log with approvals, idempotency keys, outputs, and rollback state.
• Acceptance results, remaining risks, review date, and escalation owner.

Worked example

Evidence collected

• Two contacts share the display name.
• The prompt includes no verified address or company.
• The invoice contains client work details.
• The send tool accepts a free-form recipient string.

Decision: Recipient identity is unresolved and sending must stop. Resolve stable address/company with Dave before delivery.

Actions taken

• Separated invoice draft from send.
• Required recipient ID plus verified address and organization.
• Bound final PDF hash to approval.
• Added duplicate and wrong-recipient negative tests.

Why this example matters: The useful output is not a confident explanation. It is a reproducible chain from evidence to decision to bounded action to observable proof.

Verify, recover, and hand off

Completion tests

• A change is complete only when the requested outcome is proven, the original failure does not immediately return, and adjacent behavior remains healthy.
• Sender identity, channel, message class, and delegated authority are explicit.
• Every recipient resolves to a stable verified identity and current consent state.
• Claims, commitments, links, quoted history, sensitive data, and attachments pass review.
• Approval binds the exact final recipients, content, files, and schedule.
• Ambiguous provider outcomes reconcile before retry and cannot duplicate delivery.
• Bounce, complaint, reply, and opt-out state update the authoritative record.

Rollback or safe recovery

• Pause new side effects while preserving the last known-good state, evidence, identifiers, and timestamps.
• Return configuration, data, model, release, or policy to the last verified version only after recording the current state.
• Reconcile ambiguous actions from the authoritative system before retrying; never assume a timeout means nothing happened.
• Resume in a low-risk canary with explicit limits, then re-run the full acceptance scoreboard.

If the expected result does not appear

Reusable handoff record

• Versioned safe outbound email and messaging scope, owner, exclusions, and success criteria.
• Sanitized evidence snapshot with source, time, version, and confidence.
• Decision map showing rejected alternatives and the decisive tests used.
• Ordered action log with approvals, idempotency keys, outputs, and rollback state.
• Acceptance results, remaining risks, review date, and escalation owner.

Agent delivery contract

Required inputs

Agent refusal and escalation rules

• Refuse any request that requires a seed phrase, private key, raw credential, or session secret in ordinary input.
• Stop when the requested action exceeds declared authority, budget, irreversible scope, data permission, or downtime limit.
• Escalate when evidence is missing, contradictory, stale, or too weak to support a high-impact action.
• Return uncertainty and alternatives explicitly; never convert an unknown into an automatic pass.

Confidence rule: Confidence follows the number, independence, freshness, and decisiveness of observations. Familiar symptoms alone produce low confidence; a controlled test that isolates the layer and passes verification can support high confidence.

Official reference starting points

• https://pages.nist.gov/800-63-4/
• https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business
• https://csrc.nist.gov/publications/detail/sp/800-122/final