Send email from Django
Anymail is the canonical bridge. Most providers ship Anymail backends; pick a provider with a maintained backend rather than a raw SDK.
Anymail standardizes Django EmailBackend across providers, with first-class webhook handling. Async sends require Celery or a worker.
Send patterns
- Anymail EmailBackend in settings.py.
- Celery tasks for async sends.
- Webhook views via Anymail signal handlers.
- Django templates rendered to HTML before send.
Common mistakes
- Synchronous send blocks the request without a worker.
- Anymail backend mismatch between dev and prod.
- EMAIL_BACKEND env override forgotten in CI.
provider picks for Django
- 01
Postmark
TransactionalFirst-class Anymail backend; webhook signature helpers built in.
100/mo developer plan · $15/mo for 10,000 emails - 02
Mailgun
TransactionalAnymail backend; queue-friendly.
100/day permanent free plan · $15/mo for 10,000 emails (Basic) - 03
Amazon SES
TransactionalAnymail SES backend; pairs naturally with AWS-hosted Django.
Up to $200 in AWS Free Tier credits for new accounts · $0.10 per 1,000 emails - 04
SendGrid
Transactional MarketingAnymail backend; mature.
60-day free trial only (permanent free tier was removed May 2025) · $19.95/mo for 50,000 emails
reading this as developers picking email infrastructure
The question here is which one a backend engineer would rather operate. That means SDK depth in the language already in use, whether a retry can safely be replayed, how much the event log tells you when a customer says the email never arrived, and whether the pricing curve stays sane as volume grows.
Applied to sending email from Django, that means weighing developer experience, SDK breadth, idempotency keys, and operating track record ahead of the rest, against password resets, receipts, and magic links shipped from application code.