Multi-stream sending

Run separate transactional, marketing, and notification streams. Independent IPs, configuration sets, suppressions per stream.

Why multi-stream?

The single biggest deliverability mistake: sending password resets from the same IP/domain as your marketing newsletter. If 0.5% of marketing recipients complain, AWS pauses your entire sending account — including critical transactional mail.

Multi-stream isolates this. Each stream has its own:

Configuration set (separate SES reputation tracking)
IP pool (separate sender reputation)
From-address default
Analytics view

Setup

1. Create the streams

transactional

curl -X POST https://api.mailgrid.space/api/streams \
  -H "Authorization: Bearer $KEY" \
  -d '{
    "name": "transactional",
    "type": "transactional",
    "defaultFrom": "noreply@yourdomain.com",
    "configSet":   "tx-prod"
  }'

marketing

curl -X POST https://api.mailgrid.space/api/streams \
  -H "Authorization: Bearer $KEY" \
  -d '{
    "name": "marketing",
    "type": "marketing",
    "defaultFrom": "news@yourdomain.com",
    "configSet":   "mkt-prod"
  }'

2. Create matching SES configuration sets

In AWS SES console, create one configuration set per stream. Wire each to its own SNS topic if you want separate analytics. Or share one topic — Mailgrid records the streamId on each event so you can filter later.

3. Send via the right stream

tagged send

{
  "from": "hello@yourdomain.com",
  "to": "user@example.com",
  "subject": "Password reset",
  "html": "<p>Click here</p>",
  "streamId": "<transactional-stream-id>"
}

Best practices

Different from-domains per stream if you can. auth@ vs news@ isolates reputation at the recipient level too.
Dedicated IPs for marketing — protects transactional traffic from any deliverability hit.
Stream-aware unsubscribes — your marketing stream should obey unsubscribes; transactional generally doesn't need them.
Audit logs — filter by stream to see who sent what.