Features Pricing Compare Cost calculator Guides Quickstarts Docs All systems nominal

Django quickstart

Point Django's EMAIL_BACKEND at sendvia's SMTP relay, send one email with send_mail(), and find it in your send log. Requires the paid SMTP add-on.

Last reviewed:

Get an API key

Create a sendvia account and a key is issued immediately, sitting on the Account page, prefixed sv_live_. Every example below writes it as a placeholder:

sv_live_xxxxxxxxxxxxxxxxxxxxxxxx
The SMTP relay is a paid add-on, not part of the free plan. It sits on top of Premium (19 a month) and is not self-serve: once you are on Premium, email [email protected] to have it switched on. Sending over SMTP before that returns a 403, no matter how correct the settings below are. Billing shows whether it is already enabled.

You also need a domain verified in your account, since the mail below is sent from an address on it. Add one under Domains if you have not already, and give its DNS records time to propagate.

Send one email

Django's own EMAIL_BACKEND already knows how to talk SMTP, so pointing it at sendvia is a settings change rather than a new dependency.

EMAIL_BACKEND = "django.core.mail.backends.smtp.EmailBackend"
EMAIL_HOST = "smtp.sendvia.io"
EMAIL_PORT = 587
EMAIL_HOST_USER = "sendvia"
EMAIL_HOST_PASSWORD = "sv_live_xxxxxxxxxxxxxxxxxxxxxxxx"
EMAIL_USE_TLS = True
DEFAULT_FROM_EMAIL = "[email protected]"

EMAIL_HOST_USER accepts anything; sendvia authenticates on the password alone, which is the API key above. If a network blocks 587, set EMAIL_PORT to 2525 instead and nothing else changes.

from django.core.mail import send_mail

send_mail(
    "Hello from sendvia",
    "This is a test email sent through sendvia.",
    "[email protected]",
    ["[email protected]"],
)

send_mail() raises on a connection or authentication failure, but a clean return does not by itself prove the message went anywhere: sendvia can still refuse it after accepting the SMTP session. The next step confirms what actually happened.

See it in the log

SMTP sends land in the same send log as API sends, tagged with an SMTP badge so the two are easy to tell apart. Check the History page, or query the API directly with the same key:

curl "https://api.sendvia.io/v1/[email protected]" \
  -H "Authorization: Bearer sv_live_xxxxxxxxxxxxxxxxxxxxxxxx"
{
  "total": 1,
  "limit": 25,
  "offset": 0,
  "logs": [
    {
      "id": 42,
      "to_address": "[email protected]",
      "from_address": "[email protected]",
      "subject": "Hello from sendvia",
      "status": "delivered",
      "error_message": null,
      "sent_at": "2026-08-20 10:03:01",
      "delivered_at": "2026-08-20 10:05:01"
    }
  ]
}

The row moves from queued to sent within moments of the relay accepting it. Read the status after that carefully: sendvia never receives a delivery confirmation from the recipient's mail server, over SMTP or the API. Two minutes after a clean send it marks the message delivered on its own, an inference from the absence of a bounce rather than a receipt. A real bounce or failure overwrites that status the moment one arrives; nothing plays the same role for an honest delivery. Logs like this stick around for 7 to 90 days, depending on your plan.

Troubleshooting

Neither failure below raises an exception send_mail() will show you: the relay accepts the SMTP session either way, and sendvia's own checks decide what happens to the message behind it. The log is where you actually see which one you hit.

The SES sandbox rejects your test recipient

A new SES account starts inside Amazon's sandbox: 200 emails a day, sent only to recipient addresses you have verified yourself in the SES console, pending an AWS review that usually takes 12 to 24 hours. Send to any other address while sandboxed and the log shows status: "failed" with AWS's own rejection reason sitting in error_message, the same as it would for a send through the REST API.

Verify the test recipient in the SES console while you wait, or request production access, which lifts the restriction for every recipient at once.

The domain has not been verified

sendvia checks the domain on DEFAULT_FROM_EMAIL against the domains verified on your account, the same rule the REST API enforces as a 422 before it ever calls AWS. Get that wrong, typically by pointing Django at a domain you have not added yet, and the message never leaves. There is no response body to read the way a REST call gives you one, so confirm the domain's status directly on the Domains page rather than guessing from Django's side.

Add the domain if it is missing, publish the DNS records sendvia gives you, and resend once the check passes.

Two failures almost everyone hits on the first send.
SymptomCauseFix
Log status failed, AWS rejection in error_messageSES sandbox: the recipient is not verifiedVerify the recipient in SES, or request production access
No mail arrives, nothing in Django raisesThe from domain is not verified on your accountAdd and verify the domain under Domains