Django 6.1's MAILERS setting opens as many SMTP connections as the EMAIL_BACKEND it replaces

Django 6.1 introduced a new setting called MAILERS, designed to replace EMAIL_BACKEND and the ten EMAIL_* settings associated with it. The assumption was that this new configuration system would improve how SMTP connections are established. To verify this, a test was conducted with the following findings:

Finding 1: MAILERS does not reduce connections by itself

Sending 50 emails using legacy EMAIL_BACKEND and MAILERS resulted in exactly the same 50 SMTP connections each time. The only way to reduce the number of connections was to manually reuse a connection object, which was the same approach used before the introduction of MAILERS. MAILERS is not a connection pool but a configuration format, and it does not change the behavior of SMTP connections being created with every email sent.

Finding 2: MAILERS provides better error handling

When a misspelled option was passed to the SMTP backend using the old EMAIL_BACKEND method, it resulted in a warning and the connection was still created. However, when the same typo was introduced inside the MAILERS configuration, it caused a fatal error and no emails were sent. This demonstrates that MAILERS offers stronger error handling, as a misconfigured mailer will now fail at startup instead of silently sending emails with default settings that were not chosen.

Finding 3: using cannot be combined with replaced arguments

The using argument in send_mail() was designed to replace connection, fail_silently, auth_user, and auth_password arguments. Passing both using and one of the replaced arguments raises a TypeError, preventing any issues from occurring silently. However, this can be problematic if code builds the connection or authentication arguments conditionally upstream of the send_mail() call, potentially turning a working call into a crash if both using and the replaced arguments are set.

Finding 4: Improved error handling during deployment

Django 6.1 includes a deploy check, mail.E001, which fails manage.py check --deploy if the default mailer is a console, dummy, file-based, or in-memory backend. It also includes a warning, mail.W001, if MAILERS has no default entry. This provides better error handling during deployment, as configuration issues will be caught early and prevent emails from being sent.

However, this can also be a trap if existing EMAIL_HOST_* settings blocks are manually copied into the MAILERS OPTIONS, as any key that doesn't match the backend's constructor argument names will now cause the entire mailer to fail instead of being ignored.