Set up cold email infrastructure

Prepare a separate sending domain, two mailboxes, DNS readiness, and warm-up checks before outbound.

Use this day_1 play before cold email when no two warmed mailboxes exist on a separate sending domain. Do not use it for a primary company domain, immediate cold sends, or a purchase without exact approved quote.

Needs and produces

Needs: separate sending domain, sender name, first-month budget. Prerequisites: real sender name, budget for first domain and mailbox month, and separate sending domain, never primary company domain.

Produces quoted and approved sending domain, two mailboxes, DNS readiness, and warm-up checks before outbound. Leading metric: two mailboxes ready for safe outbound after warm-up.

Ordered steps

1
Check existing mailbox state
Use senders.mailboxes.list to check for two already warmed mailboxes on separate sending domain.
2
Quote domain and mailbox capacity
Use senders.mailboxes.purchase_domains_suggest to quote look-alike sending domains without buying one. Use senders.mailboxes.purchase_capacity to quote capacity for two mailboxes before purchase.
3
Add approved domain and plan DNS
Use senders.domains.sending.add to add approved separate sending domain only after explicit purchase approval. Use senders.domains.sending.dns_plan to plan SPF, DKIM, and DMARC records, then senders.domains.sending.apply to apply approved DNS plan.
4
Purchase and check mailboxes
Use senders.mailboxes.purchase to purchase approved two mailboxes only after explicit purchase approval. Use senders.domains.sending.readiness_get for DNS and sending readiness, senders.mailboxes.health_get for health and warm-up status, and senders.mailboxes.placement_test for placement before cold email.

Credits and controls

Inspection, domain suggestions, capacity, DNS planning, readiness, health, and placement checks are quoted or read first. Domain and mailbox purchase spend only after named approval control. infra-purchase controls steps 4 and 7 because adding sending domain and purchasing mailboxes create paid external commitments.

Start

What is Dreamstate - Dreamstate runs GTM work in one workspace across the web app, Architect, CLI, MCP, and REST.
Quickstart - Connect through Architect, the CLI, or MCP, then ask Dreamstate for the outcome you want.

Guides

Your first session - Build a first workbook from workspace context and a sourcing plan.
Warm network first - Turn post engagement into a worksheet and a sequence.
Run a 50-lead outbound pilot - Build a worksheet, validate a sequence, and prepare a small outbound pilot.
Build a founder posting system - Create a social drafting and scheduling system from workspace context.
Turn replies into meetings - Use Inbox context and CRM records to draft follow-up work.
Run a visibility sprint - Measure visibility evidence and save useful findings in Context.
Speed to lead - Build a workflow that connects worksheet, sequence, and trigger work.
Weekly review - Review runs, sequence activity, worksheets, and credit activity every week.
Set up cold email infrastructure - Prepare a separate sending domain, two mailboxes, DNS readiness, and warm-up checks before outbound.
Migrate one Clay table - Import one Clay table, rebuild columns, review ten pilot rows, and compare per-row cost.
Prioritize identified website visitors - Add identified visitors to CRM context and read a daily ranked contact queue.
30-day GTM review - Review monthly spend, campaign results, failed-run causes, and one verdict per live motion.
Launch a client workspace - Set up client context, review three plays, and quote first paid step.
Clean up a worksheet - Use worksheet state and provenance to clean up working rows.
Keep the CRM clean - Maintain saved records and their relationships in the workspace.
Find out why something failed - Inspect workflow, worksheet, and sequence evidence to diagnose a failed run.

Surfaces

Web app and deep links - Use web links in results to open exact Dreamstate objects in the app.
Architect - Architect works in the app with packs, skills, and the same controls used by other surfaces.
CLI - Use the dreamstate CLI to authenticate, select workspaces, and discover capabilities.
CLI reference - Review Dreamstate CLI commands and their documented syntax.
MCP server - Connect an MCP client to Dreamstate and use the canonical controls.
MCP reference - Review the controls exposed by the Dreamstate MCP server.
Connect Claude - Connect Claude to Dreamstate MCP with a browser OAuth sign-in.
Connect Claude Code - Connect Claude Code to Dreamstate MCP from the terminal.
Connect ChatGPT - Connect ChatGPT to Dreamstate MCP through a custom connector.
Connect Codex - Connect Codex to Dreamstate MCP with config.toml and OAuth.
Connect Cursor - Connect Cursor to Dreamstate MCP as a remote MCP server.
Other MCP clients - Connect another MCP client to Dreamstate with OAuth or an API key header.
REST API - Use the REST API to search tools, read schemas, run tools, and inspect runs.
Agent clients - Choose a Dreamstate MCP connection guide for Claude, ChatGPT, Codex, Cursor, or another client.

Workspace

Workspaces, members and roles - A workspace defines membership, permissions, billing, and the data boundary for work.
API keys and scopes - Use workspace API keys with explicit scopes and workspace boundaries.
Agency workspaces - Use Agency to manage client workspace work.
Tags, comments and saved views - Use workspace tags, comments, and saved views to organize shared work.

Knowledge

Context - Context stores revisioned Markdown documents attributed to the member and client that wrote them.
Skills - Skills teach practice and do not grant authority or bind tools.
Notes, inspiration and bookmarks - Use research screens for notes, inspiration, and bookmarks.
AI visibility and analytics - Use AI visibility analytics to measure business content evidence.

Data

Workbooks and worksheets - A workbook contains worksheets, each with one row source, columns, and optional score.
Row sources - A worksheet uses one row source to provide its working rows.
Columns - Columns enrich and judge rows in a worksheet.
Cells and provenance - Cells hold row values and their available run provenance.
CRM records - CRM stores canonical records already saved in the workspace.

Execution

Modes - Mutating calls name a mode and the server does not default to live work.
Runs - Runs record execution work and can expose links to exact app objects.
Sequences and enrollment - Sequences separate drafting, validation, publishing, enrollment, starting, delivery, and replies.
Workflows and triggers - Workflows organize automation graphs with scheduled and event triggers.
Social posts and publishing - Social work covers drafts, schedules, publish actions, accounts, and performance analytics.
Inbox - Inbox handles messages and replies inside existing conversations.
Tasks - Tasks manage assigned work, due dates, delegation, and review state.

Providers

Packs - Packs route work by domain and explain what each domain owns.
The tool catalog - Search the tool catalog, read an exact schema, then run a capability.
Integrations - Integrations manages third-party connections and connection diagnostics.
Senders and mailboxes - Senders manages suppression, mailbox health, sender identities, and sender policy.
Data providers and costs - Data providers can require a connection or your own key before they can run.

Plays and templates

Plays - A play is an advisory order of steps toward one outcome.
Blueprints and the marketplace - A blueprint installs a workspace system and supports saved snapshots.
Reply playbooks - Reply playbooks provide Inbox guidance for scenarios and sequence rules.

Safety and cost

Credits and billing - Credits and billing are managed at the workspace boundary.
Spend caps and budgets - Paid work can use a quote and a maximum credits ceiling.
Sending safety - Sequence work keeps publishing, enrolling, starting, delivery, and replies separate.
Do not contact - Do not contact rules suppress future outbound messages across channels.
Owner actions - Owner actions use signed-in sessions, fresh approval, and idempotency keys for sensitive workspace changes.

API reference

Capability ids and naming - Capability ids identify catalog operations across the Dreamstate surfaces.
Envelope and errors - The canonical envelope communicates success and failure information.
Pagination - Pagination uses cursors to traverse collections.
Rate limits - Rate limits describe request limits for API use.
Idempotency - Idempotency keys make owner action requests safe to retry.
Webhooks - Webhooks deliver signed workspace event callbacks.
OpenAPI explorer - OpenAPI shows generated request and response schemas for Dreamstate operations.