# Transactional Email Sandbox & Setup | TrackMailer

Last reviewed: 30 August 2026

[HTML](https://www.trackmailer.io/) · [Documentation](https://docs.markengroup.cloud/trackmailer)

The developer-first email activation layer for preparing transactional messaging, recipient logic and measurable delivery.

## Current status

The TrackMailer workspace, contacts, groups, saved filters, API-key management and Sandbox validation are available. Customer delivery, provider events and conversion attribution are not active.

## “Accepted” is not the same as delivered—and delivered is not the outcome.

Transactional email becomes operational infrastructure when password resets, receipts and lifecycle messages affect trust, support load and revenue.

- **A 200 response is not delivery:** Provider acceptance, inbox delivery, hard and soft bounces, and complaints are different states.
- **Open rate is an imperfect signal:** Privacy proxies, image blocking, caches and scanners make opens unsuitable as a single source of truth.
- **Email context stops too early:** A click matters more when campaign and session context can later connect it to a signup or purchase.

## Move from intent to evidence, one explicit state at a time.

TrackMailer separates configuration, validation, provider acceptance, delivery events and downstream attribution. That prevents a draft, Sandbox response or provider request from being counted as a delivered message.

- **Available — Prepare:** Model contacts, required fields, consent-aware groups, saved filters and an exact sender domain inside one project.
- **Sandbox — Validate:** Check a typed request in the authenticated Sandbox. A valid result says sent=false and persisted=false.
- **Planned — Deliver:** A future verified worker will separate provider acceptance, delivery, bounce and complaint states.
- **Planned — Attribute:** A future TrackAny.Click connection will carry email clicks into session, conversion and revenue context.

### Sandbox request contract

```json
{
  "operation": "transactional.send",
  "sender": {
    "senderDomainId": "<your project domain id>",
    "fromLocalPart": "service"
  },
  "to": "recipient@example.com",
  "subject": "Your receipt",
  "text": "Thanks for your order.",
  "idempotencyKey": "receipt_2026_001",
  "purpose": "receipt"
}
```

Use this contract in TrackMailer's authenticated Sandbox. It validates only; there is no public customer send URL in this release.

## Design the message around the job it must do.

- **Security and account messages:** Prepare password, verification and account-alert contracts with an explicit purpose and sender identity.
- **Receipts and lifecycle notifications:** Validate idempotent transactional payloads on your server before a delivery pipeline is enabled.
- **Consent-aware audiences:** Build typed contact fields, manual groups and saved filters without treating a preview as a final send list.

## Give your coding agent a contract—not permission to guess.

The safest AI-assisted email task starts with an exact server boundary, explicit status and a request that cannot hide a browser secret or pretend Sandbox delivered a message.

- `Validate this transactional payload in TrackMailer Sandbox.` — The agent can use the documented operation and interpret sent=false correctly.
- `Explain DKIM, SPF, DMARC and MAIL FROM for this sender subdomain.` — The agent should use the exact records returned by the dashboard, never invent DKIM values.
- `Model a consent-aware recipient group for this Firebase app.` — The agent can map stable custom fields and suppression rules without putting the API key in React.

## Build on what exists. See what still blocks delivery.

- **Available — Audience controls:** Typed contact fields, groups and saved filters reduce brittle one-off recipient logic while preserving consent and suppression boundaries.
- **Sandbox — API keys and request validation:** Scoped keys and the authenticated Sandbox expose schema errors without sending, persisting contacts or generating tracking events.
- **Preview — Sender identity setup:** Exact domain proof, DKIM and MAIL FROM guidance make the sender boundary inspectable; the full customer-domain journey still needs production acceptance.
- **Planned — Delivery and outcome evidence:** Provider events, verified recipient mapping and TrackAny.Click attribution remain prerequisites for trustworthy delivery and revenue reporting.

## An email touchpoint becomes valuable when the next step stays measurable.

The planned integration preserves email, click, session, conversion and revenue context without copying raw contact data into every event. It is architecture, not an active customer pipeline.

Email intent → Verified delivery event → Attributed click → Session → Conversion or revenue

Provider verification and TrackAny.Click production ingestion are still required before this flow is available.

## Email trust is a chain of checks, not a badge.

TrackMailer keeps the sender, recipient, tenant and event boundaries explicit before customer delivery is enabled.

- **Server-side secrets and scopes:** API keys belong on your server, are shown once and are limited by mode, scope, project and allowed sender domains.
- **Exact domain ownership:** A parent domain does not authorize arbitrary child domains; each sender identity requires its own project proof and provider checks.
- **Tenant and permission checks:** Organization, project, product entitlement and current role are resolved on the server rather than trusted from request fields.
- **Consent and suppression stay authoritative:** A new import does not silently reactivate a contact who unsubscribed, bounced or complained.

## The shortest honest answers.

### Can TrackMailer send customer email in production today?

No. Customer delivery, queues, provider events and conversion attribution are not active. The workspace and Sandbox can prepare and validate the contract without sending.
### What does a successful Sandbox response prove?

It proves that an authenticated request matches the current schema and project rules. It explicitly returns sent=false and persisted=false; it is not a delivery receipt.
### Does an open prove a person read the email?

No. Privacy proxies, image blocking, caching and automated scanners affect open measurements. Delivery, click, bounce and complaint signals must be interpreted separately.