Sending Mail with Drupal: Reliable Email Setup for Business Sites

By Greg Nowak. Last updated 2026-06-30.

Email is one of those Drupal features that only gets attention after it fails. A password reset does not arrive. A quote request lands in spam. An internal approval email works on staging but disappears in production. The site may look healthy, while the business process behind it is leaking trust.

For a modern Drupal 10 or 11 site, reliable email is not just a coding task. Drupal has to compose the message cleanly, the transport has to hand it to the right mail service, and the sending domain has to be trusted by recipient systems. Treat those as three separate responsibilities and the setup becomes much easier to reason about.

Let Drupal Compose, Let Mail Infrastructure Deliver

Drupal core provides a mail manager service for composing and optionally sending messages. In custom code, the usual pattern is still to call plugin.manager.mail and let your module implement hook_mail() for the subject, body, and headers that belong to that message type.

That split is useful. Business logic stays near the feature that owns it, text is easier to review, and the delivery backend can change later without rewriting every notification. The important operational caveat is that Drupal's success result only means the message was accepted at PHP level. It does not prove that Gmail, Microsoft 365, or a customer's mail server accepted it.

$mailManager = \Drupal::service('plugin.manager.mail');
$params = [
  'customer_name' => $customerName,
  'project_name' => $projectName,
];

$result = $mailManager->mail(
  'my_module',
  'project_notice',
  $to,
  $langcode,
  $params
);

Choose the Right Mail Path

The best setup depends on risk, volume, and how polished the emails need to be. Most business sites should avoid relying blindly on PHP mail(), especially when contact forms, onboarding flows, commerce emails, or operational alerts matter.

Drupal email setup decision matrix

Option	Best fit	Watch point
Host PHP mail or sendmail	Low-risk development or simple internal notifications on a well-managed server	Depends heavily on host mail configuration and gives limited delivery visibility
SMTP Authentication Support	Most business sites that need authenticated relay through Microsoft 365, Google Workspace, SendGrid SMTP, Mailgun SMTP, or similar	SMTP only; provider APIs, webhooks, and advanced analytics need another layer
Core Symfony mailer backend	Teams wanting a Drupal core transport replacement configured with a DSN	Still marked experimental in Drupal 11 API docs, so use deliberately
Mailer Plus	Sites needing richer HTML email, attachments, embedded images, async sending, or more advanced mail architecture	Larger migration and maintenance decision; evaluate project status before adopting

A Practical SMTP Baseline

For many Drupal sites, the simplest reliable path is authenticated SMTP through a provider already responsible for the organization's mail. The Drupal SMTP Authentication Support module is built for this: it bypasses PHP's native mail() function and sends directly to an SMTP server. Its current stable release supports Drupal 9.5, 10, and 11.

composer require 'drupal/smtp:^1.4'

After installing it, configure the SMTP host, port, encryption mode, username, and password in Drupal configuration or through your deployment process. Keep credentials out of code where possible. Use the hosting platform's secrets manager, environment variables, or another controlled configuration path.

If you are testing Drupal core's Symfony mailer backend instead, use a settings override like this and adapt the host, port, and credentials to your provider:

$config['system.mail']['interface'] = [
  'default' => 'symfony_mailer',
];
$config['system.mail']['mailer_dsn'] = [
  'scheme' => 'smtp',
  'host' => getenv('SMTP_HOST'),
  'port' => 587,
  'user' => getenv('SMTP_USER'),
  'password' => getenv('SMTP_PASS'),
  'options' => [],
];

Do not choose Symfony mailer just because it sounds newer. Core's backend is useful as a transport replacement inside Drupal's existing mail model. If the real requirement is branded multipart email, attachments, provider-specific APIs, queueing, or failover, that is a broader mail-system decision.

Make the From Address Boring and Correct

A common mistake is using the visitor's email address as the visible From: address on contact form messages. That often breaks authentication because your Drupal site is not authorized to send on behalf of the visitor's domain. Use a verified site domain in From:, such as [email protected], and put the visitor's address in Reply-To when appropriate.

This is also easier for staff. The message clearly came through the website, replies still go to the customer, and the sending domain can be authenticated consistently.

Deliverability Is Part of the Build

Since February 1, 2024, Google's Gmail sender requirements have made the baseline very explicit. All senders to Gmail accounts need SPF or DKIM authentication. Senders above 5,000 messages per day to Gmail need SPF, DKIM, and DMARC, along with other requirements such as TLS, valid forward and reverse DNS, low spam rates, and aligned sender identity.

Even if your Drupal site is not a bulk sender, the same checklist is sensible. Publish SPF for the service that sends the mail. Turn on DKIM signing with the provider. Add DMARC, starting with a monitoring policy if the domain has not used it before. Test real messages to Gmail, Microsoft 365, and your own mailbox, then inspect headers rather than trusting the Drupal success message.

What to Check Before Launch

Confirm every transactional email has a clear owner, recipient, subject, and fallback path.
Use a verified domain in From: and reserve Reply-To for customer responses.
Send test messages from production-like infrastructure, not only from local development.
Check logs in Drupal and in the mail provider, especially for rejected authentication or TLS errors.
Retest after DNS changes, mail provider changes, hosting migrations, and form redesigns.

The goal is not an overbuilt mail platform. The goal is a setup your team can understand, monitor, and fix without guesswork. If your Drupal emails support sales, support, compliance, or customer onboarding, that reliability is worth designing on purpose.

If you want a practical review of a Drupal mail flow, delivery problem, or modernization plan, talk to Greg about tightening the setup before missed messages become a business problem.

Related on GrN.dk

Need help with this kind of work?

Talk to Greg about Drupal email Get in touch with Greg.

Sources

Last modified

2026-06-30