Your own AWS setup, a re-verified domain, and two call sites to update, for the outbound side. sendvia does no inbound routing, so that half stays put.
This page walks through moving outbound sending from Mailgun 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. If anything on the domain also receives mail, read step three before you touch a record.
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.
sendvia does no inbound routing of any kind, so an MX record kept for receiving mail has to stay exactly where it is. Only the outbound records move.
| Record | What it did |
|---|---|
| SPF and DKIM (TXT) | Authorised and signed outbound mail. This half moves. |
| Tracking (CNAME) | Routed open and click tracking through a subdomain. This half moves. |
| MX, if you receive mail | Delivers inbound mail to be routed, parsed and stored. This half stays. sendvia has no equivalent. |
| Read from the domains section of Mailgun's user manual. All were added by hand at the registrar or host. | |
The SPF and DKIM entries above 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 (new host) | 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] |
Note that sendvia's MX above sits on bounce.yourdomain.com, not on the domain apex, so it cannot collide with an inbound MX kept at the apex for receiving mail. The two can coexist. That bounce subdomain 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.
Mailgun takes POST https://api.mailgun.net/v3/yourdomain.com/messages as an ordinary form post rather than JSON, authenticated with HTTP basic auth under the literal username api.
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.mailgun.net/v3/yourdomain.com/messages \
--user "api:your_api_key" \
-F from="[email protected]" \
-F to="[email protected]" \
-F subject="Your receipt" \
-F text="Thanks for your order."Read from documentation.mailgun.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 HTTP API. Mailgun publishes SMTP settings of its own at smtp.mailgun.org, on ports 25, 465, 587 and 2525.
| Detail | Mailgun | sendvia |
|---|---|---|
| SMTP relay | Yes, alongside the HTTP API | Yes, an SMTP relay on 587 with 2525 as a fallback |
| The Mailgun column was read from www.mailgun.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, for outbound mail at least. 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 Mailgun.
Once bounce and complaint rates hold steady and the logs agree, move the remaining outbound traffic over and cancel only what you are certain sends nothing and receives nothing. 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 Mailgun 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.