Every transactional email service is, underneath, the same thing: someone else's AWS account with a nicer API and a markup. The markup buys real conveniences (templates, logs, a dashboard), but it also buys you a shared sending reputation and a per-email price that is 10 to 40 times what Amazon charges. SES lists at $0.10 per thousand emails. The resold version of that email routinely costs a cent each.
Bring-your-own-keys (BYOK) is the arrangement where you keep the conveniences and skip the resale: a platform holds your templates, triggers, delivery rules and tracking, and hands the actual send to providers you connect with your own credentials. Here is the full setup, using Messy as the platform layer.
Why the keys matter beyond price
- Your reputation is actually yours. On shared infrastructure, the spammer three tenants over is your deliverability problem. On your own SES account with your own domain, inbox placement reflects your behavior alone.
- No migration cliff. If you outgrow the platform, the provider relationship, the verified domain and the reputation all stay with you. Switching tools stops meaning warming up a new IP.
- One bill you can read. AWS charges you for delivery; the platform charges a flat fee for orchestration. Nobody profits from your volume, so nobody designs pricing around it.
Step 1: the DNS trio
Deliverability starts with three DNS records proving you are allowed to send as your domain. You set these once, at your DNS host, regardless of which platform sits on top:
- SPF: a TXT record listing servers allowed to send for your domain. For SES that means including
amazonses.comin your existing record. - DKIM: cryptographic signing. SES gives you three CNAME records when you verify the domain; paste them in and wait for the green check.
- DMARC: the policy tying the two together. Start with
p=noneand a reporting address, tighten toquarantineonce the reports look clean.
While you are in the SES console, request production access (new accounts start sandboxed to verified recipients) and create an IAM user whose permissions are scoped to sending only.
Step 2: connect the keys
In Messy, add an SES integration under Channels with that IAM key pair and your region, then register your from-address as a sending identity. Integrations attach per environment, so staging can run a different key (or a mailtrap-style SMTP catcher) while production runs the real one. If the SES integration ever fails, delivery falls back to the account-level default integration rather than dropping the message.
Step 3: triggers instead of embedded HTML
The habit worth breaking is rendering email HTML inside your application. Register a template under a trigger key, and let your app send data:
curl -X POST https://api.messy.sh/messages/trigger \
-H "Authorization: Bearer $MESSY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"trigger": "order.confirmed",
"channel": "email",
"message": { "to": "sam@example.com" },
"data": { "name": "Sam", "order_id": "1042", "total": "€89.00" }
}'The template lives in Templates, where support can fix a typo without a deploy. The response comes back pending, flips to sent on delivery, and from there opens, clicks and bounces accrue to the message record, searchable when a customer says the invoice never arrived. Wiring a typed client for this into your codebase is playbook one; a coding agent does it in about ten minutes.
Step 4: rules before you need them
The cheapest incident is the one that cannot happen. Delivery rules evaluate every recipient before anything sends, so set two on day one: staging may only email @yourcompany.comaddresses, and security-sensitive mail (OTPs, password resets) is exempt from link tracking. Five minutes now, one averted "why did staging email 4,000 customers" retro later.
Where this sits in the bigger picture: transactional email is usually the first channel teams pull into a proper messaging layer, because the wins are immediate and the risk is low. The map of what comes after (routing, recipient state, the other channels) is in the notification infrastructure guide.
