sendvia vs Postmark

What each costs at 10,000, 100,000, 500,000 and 1,000,000 emails a month, who owns the sending account, and where Postmark is the better buy.

Should I use sendvia or Postmark?

Use sendvia if you already run on AWS, want the sending reputation and the Amazon bill to stay in an account you control, and send enough that a flat monthly fee beats a rate per email. Choose Postmark if you would rather somebody else owned the problem when mail stops landing and answered the phone about it, or if your list already lives in your own application and you only need something to hand messages to. At the smallest volume this page prices, the money argument runs the other way, and what is left is the rest of the page.

Is sendvia cheaper than Postmark?

Postmark is cheaper at 10,000 emails a month. sendvia is cheaper at 100,000, 500,000 and 1,000,000 emails a month.

sendvia is $19.00 a month flat plus Amazon SES at $0.10 per 1,000 emails, billed by Amazon straight to your own account. At 1,000,000 emails that is the flat fee plus $100.00 of SES, and the flat half of it is the half that never moves.

Where a cell says a figure is computed, it is worked out from that provider's own published rate for extra emails on the cheapest plan that can carry the volume, and the note names which plan that is. Naming it matters here more than anywhere else on the site: three plans are sold at the same entry volume, the cheapest to start has the dearest rate for extra emails, and a reader on a different plan would pay something else entirely.

Feature by feature

Every cell below carries the page it was read from and the date it was read. Where a plain yes or no would mislead, the cell says what the difference actually is instead of rounding it.

Whose AWS account, whose reputation, whose IPs

sendvia sends through an IAM user in your own AWS account. Amazon meters the mail and bills you for it directly, the SES sending identity is yours, and the addresses it leaves from are Amazon's shared SES pool unless you pay Amazon for a dedicated one. Revoke the key and sending stops the same minute, with the verified domains, the DNS records and the bounce history still sitting where they were.

Postmark is the other arrangement, with a division inside it that none of the other three offer. Your mail leaves on their servers and the reputation is theirs to protect, which they do actively, and which is most of what the price buys.

Postmark also runs parallel but separate sending infrastructures for transactional and broadcast traffic, IP ranges included, so a bad campaign cannot pull the receipts down with it. That is the difference on this page worth understanding before any other. sendvia has one SES identity and one reputation covering both kinds of mail, and no way to divide them; if you need that division, you need two AWS accounts and two sendvia accounts to get it, and nothing here will do it for you.

What their side costs you at the registrar is small, and the DNS setup row above has it: one DKIM record and one CNAME for the return path. sendvia asks for more than that, because more of the sending identity is yours to prove.

The trade runs both ways, and ours costs you something. You set up the AWS account, you create the IAM user, and a new SES account starts inside Amazon's sandbox, capped at 200 emails a day to verified recipients, until Amazon grants production access.

Does sendvia support SMTP like Postmark?

Postmark publishes SMTP settings of its own at smtp.postmarkapp.com. sendvia runs a relay on smtp.sendvia.io, port 587, with 2525 as a fallback for networks that block it, and your API key is the password.

The send call, side by side

Both are a single POST. 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>"
  }'

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"
  }'

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."}

The relay takes the same credentials, so the same tool drives it:

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.eml

Logs and retention

sendvia keeps 7 days of send logs on the free plan and 90 on the paid one, and nulls the stored message body at half the retention period before the row itself is deleted. 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, and it is the row to read carefully. sendvia leaves DELIVERY out of its SES subscription because subscribing to it flooded the webhook and stalled the site, so a message with no failure recorded against it two minutes after sending is marked delivered. That is an inference drawn from silence. Resend, Postmark, Mailgun and SendGrid all receive a real delivery event from their own systems, and sendvia does not.

Log history is the row where sendvia does worst against this particular rival, and the note inside that cell says exactly how much worse. Both figures follow the same convention as every other plan-gated row on the page: the low and the high across everything the provider publishes, paid add-ons included, rather than the flattering end of either.

Campaigns and lists

sendvia stores contacts, builds segments from rules over their fields and their engagement, imports a CSV with column mapping for exports out of other tools, and sends a newsletter to a list on the same flat fee as the transactional mail. List-Unsubscribe and List-Unsubscribe-Post go on every newsletter send, so the one-click unsubscribe Gmail and Yahoo ask for is there without you configuring it.

Postmark takes the other view of where a list belongs. Yours stays in your own application, and bulk mail leaves through a broadcast stream that is kept apart from the receipts. If you already have a subscriber table you are happy with, that is one fewer place for it to live. If you do not, it is a thing you now have to build, and the rows in the table above are where that shows up.

What does Postmark do better than sendvia?

These come out of the same data file the table above does, and each one links to the page it was checked against.

Who each one is for

Neither line is a slogan. If the one on the left describes you better than the one on the right, the rest of this page is a set of details you do not need.

Can I migrate from Postmark to sendvia?

Yes, and most of the work is on the Amazon side rather than in sendvia. You need an AWS account, an IAM user allowed to use SES and SNS, and production access, which Amazon reviews and usually grants within 12 to 24 hours. After that you verify a sending domain, publish the records sendvia generates for it, and point your application at the new endpoint.

Check what is missing before you start rather than after: there is no dedicated IP option, no inbound email or parsing, no teams or sub-accounts and no official SDKs. Add to that the thing this particular route will miss most, which is that sendvia sends receipts and campaigns through one SES identity and one reputation rather than keeping them apart.

The list itself is the easy half, because on this route there usually is not one to move: it was already in your application. Migrate from Postmark to sendvia walks through the rest. Plan the parallel run yourself: same traffic through both for a week, compare what lands, then cut over.