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 SendGrid 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. SendGrid's own verification asked for a small set of entries there, added by hand unless the registrar happens to be GoDaddy.
| Record | What it did |
|---|---|
| CNAME entries for domain authentication | Signed and authorised outbound mail, added by hand or, on GoDaddy, through an automatic connection. |
| Read from the domain authentication guide. | |
Those entries 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 it and the SPF TXT above 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.
SendGrid takes POST https://api.sendgrid.com/v3/mail/send and wraps the recipients in a personalizations array rather than a flat to field.
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.sendgrid.com/v3/mail/send \
-H "Authorization: Bearer your_api_key" \
-H "Content-Type: application/json" \
-d '{
"personalizations": [{"to": [{"email": "[email protected]"}]}],
"from": {"email": "[email protected]"},
"subject": "Your receipt",
"content": [{"type": "text/html", "value": "<p>Thanks for your order.</p>"}]
}'Read from www.twilio.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. SendGrid publishes SMTP settings of its own at smtp.sendgrid.net.
| Detail | SendGrid | sendvia |
|---|---|---|
| SMTP relay | Yes, smtp.sendgrid.net on 587 | Yes, an SMTP relay on 587 with 2525 as a fallback |
| The SendGrid column was read from www.twilio.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 SendGrid.
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 SendGrid 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.