Cold email infrastructure, end to end

$ Set up https://www.routergrowth.com/SKILL.md, then find me a sending domain for acme, register it, set up SPF DKIM and DMARC, and create an inbox.

Most outbound stacks buy the domain in one place, host DNS in another, send from a third, and discover the authentication was wrong when the reply rate is already zero. The pieces are not hard. The seams between them are.

Eight capabilities cover the whole path here: find a domain, register it, write the DNS, verify it for sending, check the authentication independently, create the inbox, send, and read what comes back.

The pipeline

domain.search        →  what is available and what it costs
domain.register      →  buy it, with you as registrant
email.domain         →  verify it for sending, get the DNS records
domain.dns           →  write those records
email.domain_health  →  independent check: MX, SPF, DKIM, DMARC
email.inbox          →  the sending address
email.send           →  send, or reply in a thread
email.messages       →  replies, bounces and opens

Step 1: a domain that is not your main one

Never send cold outbound from your primary domain. A deliverability problem on a sending domain costs you a campaign; the same problem on the domain your invoices and password resets go through costs you the company's email.

curl -X POST https://api.routergrowth.com/v1/run \
  -H "Authorization: Bearer $ROUTERGROWTH_API_KEY" \
  -d '{"capability": "domain.search", "input": {"name": "acme", "tlds": ["com", "io", "co"]}}'

Availability and price per TLD. Pick something close to your brand and readable when a recipient checks it: getacme.com, acme-hq.com, tryacme.com. Avoid a TLD with a bad sending reputation, and avoid anything that looks like a throwaway, because the recipient's spam filter has an opinion about that too.

curl -X POST https://api.routergrowth.com/v1/run \
  -H "Authorization: Bearer $ROUTERGROWTH_API_KEY" \
  -d '{
    "capability": "domain.register",
    "input": {
      "domain": "getacme.com", "years": 1, "privacy": true, "auto_renew": true,
      "registrant": {"first_name": "Alex", "last_name": "Rivera",
                     "email": "alex@acme.com", "country": "FR"}
    }
  }'

You are the registrant contact. The response carries the order, the expiry and the nameservers.

Step 2: authentication, which is the whole game

curl -X POST https://api.routergrowth.com/v1/run \
  -H "Authorization: Bearer $ROUTERGROWTH_API_KEY" \
  -d '{"capability": "email.domain", "input": {"domain": "getacme.com"}}'

This returns a domain_id, a status, the exact DNS records to create and a setup_url. Write the records with domain.dns:

curl -X POST https://api.routergrowth.com/v1/run \
  -H "Authorization: Bearer $ROUTERGROWTH_API_KEY" \
  -d '{"capability": "domain.dns",
       "input": {"domain": "getacme.com", "records": [ ... from email.domain ... ]}}'

Three records decide whether your mail is read or filed:

• SPF lists which servers may send for the domain. One record, and only one. Two SPF records is a permanent fail, and it is the single most common misconfiguration.
• DKIM signs each message so the receiver can verify it was not altered. Missing DKIM is a soft fail at most providers and a hard one at some.
• DMARC tells receivers what to do when SPF or DKIM fails, and where to send reports. Start at p=none to collect reports without rejecting your own mail, then tighten to quarantine once the reports are clean.

Google and Yahoo both require authentication for bulk senders, and enforcement has only tightened. Unauthenticated cold mail does not land in spam, it frequently does not arrive at all.

Step 3: check it independently

curl -X POST https://api.routergrowth.com/v1/run \
  -H "Authorization: Bearer $ROUTERGROWTH_API_KEY" \
  -d '{"capability": "email.domain_health", "input": {"domain": "getacme.com"}}'

A score plus the resolved MX, SPF, DMARC and DKIM state, with explicit issues and warnings. Run it after the DNS propagates, then on a weekly cron forever. Records get edited by people who are not you, and a broken SPF discovered by a falling reply rate is discovered a month late.

Run it on your primary domain too. Most companies have at least one warning sitting there.

Step 4: inbox, send, read

curl -X POST https://api.routergrowth.com/v1/run \
  -H "Authorization: Bearer $ROUTERGROWTH_API_KEY" \
  -d '{"capability": "email.inbox",
       "input": {"name": "alex", "domain": "getacme.com", "display_name": "Alex Rivera"}}'

Then send, with an unsubscribe URL, because you are the sender of record:

curl -X POST https://api.routergrowth.com/v1/run \
  -H "Authorization: Bearer $ROUTERGROWTH_API_KEY" \
  -H "Idempotency-Key: campaign-q4-lead-4821" \
  -d '{
    "capability": "email.send",
    "input": {
      "inbox_id": "inb_...", "to": "alex.rivera@acme.com",
      "subject": "3 lifecycle roles in 45 days",
      "text": "Saw you posted three lifecycle marketing roles...",
      "unsubscribe_url": "https://getacme.com/u/abc123"
    }
  }'

email.messages polls the inbox for replies, bounces and opens as labels. Bounces matter more than replies in week one: a hard bounce rate above 2% is a sign the list was not verified properly, and it is the fastest way to lose a new domain.

Warm-up, honestly

A new domain has no sending history, which means no reputation, which means receivers are suspicious by default. The pattern that works is boring:

Verify every address with contact.verify before it enters this. The waterfall enrichment guide covers that half of the pipeline.

Where it breaks

• DNS propagation is not instant. Check email.domain_health before you send, not immediately after writing records.
• Two SPF records is a hard failure. If the domain had any prior mail setup, look before you add.
• Volume is not the constraint people think it is. Reputation is earned per recipient domain. A thousand sends a day to one large provider is a different risk from a thousand spread across many.
• You are the sender of record. Consent, unsubscribe handling and the applicable rules (CAN-SPAM, GDPR, and whatever applies where your recipient is) are yours. The API sends what you tell it to.

Run it as an agent

routergrowth run -c domain.search -i '{"name":"acme","tlds":["com","io"]}'
routergrowth run -c email.domain -i '{"domain":"getacme.com"}'
routergrowth run -c email.domain_health -i '{"domain":"getacme.com"}'

An agent can run the whole setup and then keep the weekly health check on a schedule, which is the part humans stop doing after month two.

What does each call cost?#

Prices below are the starting price per successful call. /v1/inspect returns the exact figure before the run and reserves it against your balance; failures and unbilled no-matches release the hold in full.

One prepaid balance covers every row. Capabilities marked coming soon are listed but not yet executable.

FAQ#

Why not just send from my company domain?

Because reputation is attached to the domain, and cold outbound is the highest-risk mail you send. A spike in complaints or bounces on a sending domain costs you that campaign. The same spike on your primary domain can affect password resets, invoices and every internal thread. Separate domains contain the blast radius, and they let you retire one without consequence.

How long does warm-up actually take?

Four to six weeks to reach meaningful volume, and the number that decides it is engagement, not days. A domain sending 20 verified emails a day that get replies warms faster than one sending 200 to a cold, unverified list. If bounces exceed 2% or complaints exceed 0.1%, the correct move is to reduce volume, not to wait longer at the same volume.

What does email.domain_health check that the setup did not?

The setup writes the records; the health check reads what the world actually resolves. Those diverge more often than you would like: a record edited by someone else, a registrar that rewrote a value, a second SPF entry added by another tool, propagation that never completed. Running it independently, on a schedule, is how you find that before your reply rate does.

Do I need DMARC at p=reject?

Not to start, and starting there is a common way to block your own mail. Begin at p=none, which collects reports and rejects nothing, and read the reports for a few weeks to see everything legitimately sending as your domain. Move to quarantine, then reject, once that list is empty of surprises.

Can I use my own domain instead of registering a new one?

Yes. email.domain takes any domain you control, returns the records to add and reports verification status. You write the records wherever your DNS lives. Registering through domain.register is a convenience so that the whole path is one API, not a requirement.