By Greg Nowak. Updated 5 September 2026.
Drupal email failures are often invisible. The website stays online, the form displays a confirmation, and nobody notices that a sales enquiry, password reset, order update, or approval request never reached its recipient.
A dependable setup has four parts: Drupal must compose the correct message, a transport must accept it, recipient systems must trust it, and somebody must notice when delivery fails. Treat email as an operational workflow—not a final checkbox in the website build.
Map the Messages Before Choosing the Mailer
Start with the business process, not the module catalogue. List every message the site sends and record its owner, recipient, urgency, data sensitivity, and fallback. A weekly report and a password-reset message do not need identical handling.
For a contact form, decide where submissions are stored if email fails. For account access, decide who investigates repeated bounces. For agency work, clarify whether the client, hosting provider, or development team owns the mail-service account and DNS records after handover.
| Approach | Best suited to | What to verify |
|---|---|---|
| Local sendmail or host mail | Development and low-risk internal messages on a properly managed server | Server ownership, reputation, logs, reverse DNS, retries, and bounce handling |
| Authenticated SMTP relay | Most business sites needing a straightforward, supported delivery path | TLS, credential storage, sending limits, provider logs, and domain authentication |
| Drupal core Symfony mailer backend | Teams deliberately evaluating Drupal core’s DSN-based transport option | It remains experimental in Drupal 11 and formats the existing core mail model as text |
| Provider API or fuller mail system | HTML templates, attachments, queues, webhooks, failover, or detailed delivery events | Module maintenance, API ownership, retry behaviour, portability, and monitoring |
Keep Message Composition Separate from Transport
Drupal’s mail manager lets a module define the subject, body, language, and headers before passing the message to the configured backend. That separation is valuable: business logic should not have to change merely because the organisation moves to another SMTP provider.
$params = [
'customer_name' => $customerName,
'project_name' => $projectName,
];
$message = $this->mailManager->mail(
'my_module',
'project_notice',
$to,
$langcode,
$params
);Inject MailManagerInterface into production services rather than repeatedly calling Drupal’s global service container. More importantly, do not treat $message['result'] as proof that the recipient received anything. Drupal documents that success only means the message was accepted at PHP level. Delivery evidence must come from SMTP responses, provider events, bounce processing, or inbox testing.
Use Authenticated SMTP as a Sensible Baseline
For many business sites, authenticated SMTP through a transactional mail service or approved organisational relay is the shortest route to a manageable setup. Drupal’s SMTP Authentication Support module bypasses PHP mail(), uses PHPMailer, supports Drupal 9.5, 10, and 11, and currently installs with:
composer require 'drupal/smtp:^1.4'Keep the hostname, username, and password in deployment-managed secrets or environment-specific settings. Do not commit credentials or casually export them with site configuration. Confirm the provider’s authentication policy, permitted sender addresses, rate limits, and TLS settings before launch.
Drupal 11 also includes an experimental Symfony Mailer backend. It is a transport replacement, not a complete branded-email system. A settings override can select it and supply an SMTP DSN:
$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' => [],
];Use it only after checking the actual requirements. HTML templates, attachments, asynchronous sending, provider APIs, and failover may justify a broader architecture.
Send From a Domain You Control
A contact form should not copy the visitor’s address into From:. Your website is not authorised to send as that person’s Gmail, Microsoft, or company domain, so the message can fail authentication or look like spoofing.
Use a stable address on your own domain—such as [email protected]—for From:. Put the visitor’s validated address in Reply-To:. Staff can still reply normally while the real sending identity remains defensible.
SPF, DKIM, and DMARC Are Part of the Build
Google currently requires all senders to personal Gmail accounts to use SPF or DKIM, valid forward and reverse DNS, TLS, standards-compliant messages, and a spam rate below its stated threshold. Senders exceeding 5,000 Gmail messages per day need SPF, DKIM, and DMARC, with sender alignment; marketing and subscribed messages at that volume also need one-click unsubscribe.
For a business site, configure both SPF and DKIM where possible, then introduce DMARC with reporting. First inventory every legitimate sender using the domain: the website, staff mail, CRM, helpdesk, newsletter platform, invoicing system, and any legacy applications. An incomplete inventory can make a well-intended DMARC change disrupt legitimate mail.
Test Delivery, Not the “Message Sent” Screen
- Trigger every business-critical message from production-like infrastructure.
- Test Gmail, Microsoft-hosted email, and at least one organisational mailbox.
- Inspect received headers for SPF, DKIM, and DMARC results.
- Check the visible sender,
Reply-To, subject, links, language, and plain-text content. - Review Drupal logs and provider activity for authentication failures, rejections, deferrals, and bounces.
- Confirm that critical form submissions are stored or routed through a fallback when email fails.
- Name the person or team responsible for alerts and investigation.
Repeat this test after hosting migrations, DNS changes, transport changes, module upgrades, and major form work. If email supports sales, access, service, or approvals, it deserves acceptance criteria and ongoing monitoring just like the visible website.
If ownership is unclear or messages are disappearing between Drupal and the inbox, ask Greg to review the complete mail path—from application code and DNS to testing, monitoring, and handover.
Related on GrN.dk
- Sending Mail from a Linux Server with Postfix: A Reliable, Relay-First Setup
- Website Email Deliverability in 2026: A Practical Fix-It Checklist
- Cloudflare Service Keys Stop in September: Find Every Caller
Need help with this kind of work?
Ask Greg to review your Drupal email setup Get in touch with Greg.
