Your own AWS setup, a re-verified domain, and two call sites to update: what changes, and what you give up by moving.
This page walks through moving outbound sending from Postmark to sendvia. The short version: an AWS account of your own, a domain re-verified under your own SES identity, and two call sites in your codebase to update. Nothing about your application code has to change beyond the request itself.
Create the AWS account first if you do not already have one, then a dedicated IAM user for sendvia rather than the account root. The setup guide covers both, along with requesting production access.
A new SES account starts inside Amazon's sandbox: sending is limited to email addresses you have verified individually, at up to 200 a day. Amazon reviews a production access request itself, and typically clears it in 12 to 24 hours. You can add and verify a domain while still in sandbox, so start the request early and use the wait for the next two steps.
Once the IAM user exists, paste its access key and secret into sendvia and add the sending domain. sendvia generates the records the next step needs.
Nothing about your DNS host changes here: only the records on it do. Postmark's own verification asked for a small set of entries there, the ones the table below replaces.
| Record | What it did |
|---|---|
| DKIM (TXT) | Signed outbound mail so mailbox providers could trust the sender |
| Return-Path (CNAME) | Pointed bounces back through Postmark's own servers |
| Read from postmarkapp.com's DKIM setup guide. Both were added by hand at the registrar or host. | |
Those two can come out once the records below are confirmed active. sendvia's own DNS panel checks each one live and marks it once it resolves.
| Type | Host | Value |
|---|---|---|
| CNAME × 3 | <token>._domainkey.yourdomain.com | <token>.dkim.amazonses.com |
| MX | bounce.yourdomain.com | 10 feedback-smtp.us-east-1.amazonses.com |
| TXT | bounce.yourdomain.com | v=spf1 include:amazonses.com ~all |
| TXT | _dmarc.yourdomain.com | v=DMARC1; p=none; rua=mailto:[email protected] |
The MX and TXT pair on bounce.yourdomain.com is not decoration. That is sendvia's MAIL FROM host: always a bounce subdomain of the domain you send from, never a plain sender-looking subdomain, because that shape is too easily mistaken for a customer's own inbox. Skip the MX and the SPF TXT above it authenticates nothing at all, so it changes nothing: SES falls back to its own amazonses.com envelope domain and DMARC ends up resting on DKIM alone. Once DKIM and DMARC are both confirmed, tighten the DMARC policy from p=none to p=quarantine and then p=reject, and add BIMI if you publish a brand logo. The setup guide covers both.
Postmark takes POST https://api.postmarkapp.com/email, authenticated with an X-Postmark-Server-Token header rather than a bearer token, and names its fields in title case.
curl -X POST https://api.sendvia.io/v1/send \
-H "Authorization: Bearer sv_live_your_api_key" \
-H "Content-Type: application/json" \
-d '{
"from": "[email protected]",
"to": "[email protected]",
"subject": "Your receipt",
"html": "<p>Thanks for your order.</p>"
}'Read from app/api.php on .
curl -X POST https://api.postmarkapp.com/email \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-H "X-Postmark-Server-Token: your_server_token" \
-d '{
"From": "[email protected]",
"To": "[email protected]",
"Subject": "Your receipt",
"HtmlBody": "<p>Thanks for your order.</p>",
"MessageStream": "outbound"
}'Read from postmarkapp.com on .
Both answer with JSON and both report a result per recipient. A successful sendvia call comes back as {"success":true,"total":1,"sent":1,"failed":0} plus a results array.
The reply that surprises a reader arriving from a provider which owns the sending account is the 422. sendvia refuses a from-address on a domain it has not verified inside your own SES account, because it has no sending identity of its own to fall back on. Verify the domain and the same call goes through.
# 422 {"error":"The domain \"yourdomain.com\" has not been verified. Add and verify it in the dashboard first."}Two ceilings worth knowing before you port a batch job: a single call takes up to 50 recipients, and /v1/send/batch takes up to 500 messages. A scheduled send accepts send_at up to 72 hours ahead.
The same swap applies wherever your codebase or transactional templates send mail through a relay rather than the REST API. Postmark publishes SMTP settings of its own at smtp.postmarkapp.com.
| Detail | Postmark | sendvia |
|---|---|---|
| SMTP relay | Yes, smtp.postmarkapp.com on 25, 2525 or 587 | Yes, an SMTP relay on 587 with 2525 as a fallback |
| The Postmark column was read from postmarkapp.com on . The sendvia column comes from sendvia_profile() in app/data/competitors.php, which is sourced to the code that implements each answer rather than to a marketing page, and reads any plan figure in it straight out of app/config.php. | ||
Point whatever library or mail transfer agent you use at the new host, port and credentials, and nothing else about the message needs to change.
curl --url smtp://smtp.sendvia.io:587 \
--user "sendvia:sv_live_your_api_key" \
--mail-from [email protected] \
--mail-rcpt [email protected] \
--upload-file receipt.emlRun both providers in parallel before you retire the old one. Send the same traffic through each for a week, compare what lands in the inbox and the spam folder, and watch bounce and complaint rates on both sides before you touch the old key.
What it records against a message is a bounce, a complaint, a delivery delay or a rejection, published by SES to an SNS topic in your own account. Delivery is not on that list. sendvia marks a message delivered when nothing has gone wrong two minutes after it was sent, which is an inference rather than a confirmation. Resend, Postmark, Mailgun and SendGrid all receive a real delivery event from their own systems, and sendvia does not. If your parallel run needs a real delivery signal to compare against, get it from the side still running through Postmark.
Once bounce and complaint rates hold steady and the logs agree, move the remaining traffic over and cancel the old account. sendvia keeps 7 days of send logs on the free plan and 90 on the paid one, so keep the old provider's own history if you need it further back than that.
Moving is not free of trade-offs. This is what the data on this site records Postmark doing that sendvia does not. Read it before you commit to a date.
Set against that: no dedicated IP option, no inbound email or parsing, no teams or sub-accounts and no official SDKs are what sendvia itself does not do, whichever provider you are moving from. Weigh both lists before you start, not after.