{"id":389,"date":"2026-09-10T02:23:16","date_gmt":"2026-09-10T07:53:16","guid":{"rendered":"https:\/\/photonconsole.com\/blog\/?p=389"},"modified":"2026-09-12T08:41:30","modified_gmt":"2026-09-12T14:11:30","slug":"django-email-configuration-for-production-applications","status":"publish","type":"post","link":"https:\/\/photonconsole.com\/blog\/django-email-configuration-for-production-applications\/","title":{"rendered":"Django Email Configuration for Production Applications"},"content":{"rendered":"\n

Your Django app sends email perfectly in development. You deploy it, and the emails stop arriving. Password reset links never reach users, signup confirmations vanish, and send_mail()<\/code> keeps returning 1<\/code> as though everything worked.<\/p>\n\n\n\n

Django is doing exactly what you configured it to do. The problem is that the settings which work on a laptop are not the settings that work on a server, and Django’s defaults are deliberately designed for development rather than production.<\/p>\n\n\n\n

This guide covers the full production setup: the settings.py<\/code> values that matter, connection handling, asynchronous sending with Celery, the password reset flow, and the specific configuration mistakes that let Django email fail without raising anything.<\/p>\n\n\n\n

Quick Answer: How Do You Configure Email in Django?<\/h2>\n\n\n\n

Set the SMTP backend and connection details in settings.py<\/code>, reading credentials from environment variables:<\/p>\n\n\n\n

import os\n\nEMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'\nEMAIL_HOST = 'smtp.photonrelay.com'\nEMAIL_PORT = 587\nEMAIL_HOST_USER = os.environ['EMAIL_HOST_USER']\nEMAIL_HOST_PASSWORD = os.environ['EMAIL_HOST_PASSWORD']\nEMAIL_USE_TLS = True\nEMAIL_TIMEOUT = 10\nDEFAULT_FROM_EMAIL = 'Your App <noreply@yourdomain.com>'\nSERVER_EMAIL = 'errors@yourdomain.com'<\/code><\/pre>\n\n\n\n
from django.core.mail import send_mail\n\nsend_mail(\n    subject='Your verification code',\n    message='Your code is 492019.',\n    from_email=None,          # falls back to DEFAULT_FROM_EMAIL\n    recipient_list=['user@example.com'],\n    fail_silently=False,\n)<\/code><\/pre>\n\n\n\n
The application code is rarely the problem. What decides whether a message reaches an inbox is the backend you selected, the host you authenticate against, and whether your domain is authorised to send. An authenticated relay such as PhotonConsole<\/a> on port 587 removes most of the failure modes covered below.<\/p>\n\n\n\n
How Django’s Email Layer Works<\/h2>\n\n\n\n
Django routes every outgoing message through a configurable backend. The backend decides what actually happens to the message: sent over SMTP, printed to the console, written to a file, or held in memory for tests.<\/p>\n\n\n\n
The official Django email documentation<\/a> lists five built-in backends. Only one of them sends anything.<\/p>\n\n\n\n
Backend<\/th>What it does<\/th>Use in<\/th><\/tr><\/thead>
smtp.EmailBackend<\/code><\/td>Sends over SMTP<\/td>Production<\/td><\/tr>
console.EmailBackend<\/code><\/td>Prints the message to stdout<\/td>Local development<\/td><\/tr>
filebased.EmailBackend<\/code><\/td>Writes each message to a file<\/td>Local inspection<\/td><\/tr>
locmem.EmailBackend<\/code><\/td>Stores messages in memory<\/td>Automated tests<\/td><\/tr>
dummy.EmailBackend<\/code><\/td>Discards everything silently<\/td>Disabling mail entirely<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Django does not deliver email itself. It hands a correctly formatted message to whichever backend is configured, and the SMTP backend hands it to whatever host you named. If you want the underlying protocol explained first, see our guide to what SMTP is<\/a>.<\/p>\n\n\n\n
Why Django Email Fails in Production<\/h2>\n\n\n\n
\"\tDiagram
Four settings that let Django report a successful send while nothing is delivered.<\/figcaption><\/figure>\n\n\n\n
Most email failures in Django come from configuration or authentication rather than defects in the framework. These five account for the majority.<\/p>\n\n\n\n
1. The Console Backend Is Still Active<\/h3>\n\n\n\n
Most tutorials and starter templates set EMAIL_BACKEND<\/code> to the console backend so development does not send real mail. If that setting reaches production, every message is printed to your application logs and nothing is sent. send_mail()<\/code> still returns 1<\/code>, because from Django’s point of view the send succeeded.<\/p>\n\n\n\n
This is the most common cause of “Django says it sent the email but nothing arrived”.<\/p>\n\n\n\n
2. EMAIL_USE_TLS and EMAIL_USE_SSL Are Both Set<\/h3>\n\n\n\n
These two settings are mutually exclusive, and Django raises an error if both are True<\/code>. More commonly, one is set to match the wrong port. Use TLS with port 587, or SSL with port 465, and never mix the pairings.<\/p>\n\n\n\n
3. DEFAULT_FROM_EMAIL Was Never Changed<\/h3>\n\n\n\n
Django’s default from address is webmaster@localhost<\/code>. That address does not exist on your domain, so it fails DMARC alignment and gives bounces nowhere to go. Mailbox providers treat mail from a non-existent sender with suspicion, in line with Google’s sender guidelines<\/a>.<\/p>\n\n\n\n
4. No Authentication Records on Your Domain<\/h3>\n\n\n\n
Without SPF and DKIM, receiving servers cannot verify your application is allowed to send as your domain. Our guide to SPF, DKIM and DMARC<\/a> covers the records, and the free email deliverability checker<\/a> shows what your domain currently publishes.<\/p>\n\n\n\n
5. Your Host Blocks Outbound SMTP<\/h3>\n\n\n\n
AWS, Google Cloud, DigitalOcean and Azure restrict outbound port 25 by default. AWS documents its port 25 throttle removal process<\/a>, though removal does not solve the reputation problem underneath. Our breakdown of SMTP connection timeouts<\/a> covers the diagnosis.<\/p>\n\n\n\n
Quick Fix<\/p>\n\n\n\n
Django Reports Success but No Email Arrives<\/p>\n\n\n\n