When you are working with a Drupal site, especially one that syncs live data down to development or staging environments, one of the most significant risks is accidentally sending automated emails to your real users. Whether it is a subscription notification, a password reset, or a scheduled newsletter, sending "test" content to your production user base is a mistake that can damage your brand's reputation.

To prevent this, you need a robust strategy to disable Drupal emails or redirect them safely during the development lifecycle. In this guide, we will explore several proven methods to handle outgoing mail, ranging from quick settings.php overrides to using powerful modules like Devel and Reroute Email.

Using the Devel Module for Local Logging

If you are already using the Devel module—which is a staple for most Drupal developers—you have access to a built-in mail system called DevelMailLog. Instead of delivering emails to an SMTP server or using the server's local sendmail, this system intercepts the email and writes it to a file in your temporary directory.

This is often the preferred method because it allows you to verify that an email would have been sent and inspect its content without actually bothering a recipient.

For Drupal 7

To enable this in Drupal 7, add the following lines to your settings.php file:

$conf['mail_system'] = array(
  'default-system' => 'DevelMailLog',
);

By default, these files are stored in temporary://devel-mails. If you want to specify a custom directory for these logs, you can add an additional variable:

$conf['devel_debug_mail_directory'] = '/path/to/your/custom/folder';

For Drupal 8, 9, 10, and 11

In modern versions of Drupal, the configuration system handles the mail interface. You can enable the Devel mail handler using Drush:

drush -y pm-enable devel
drush -y config-set system.mail interface.default devel_mail_log

This tells Drupal to use the Devel logging plugin for all outgoing mail. You can then view the output in your site's temporary directory to debug your mail templates.

The Core "Test Mail Collector" Method

If you prefer not to rely on third-party modules like Devel, Drupal core provides a built-in mechanism used primarily for automated testing. This is known as the test_mail_collector.

By setting your mail interface to this collector, Drupal will store all outgoing emails in the State system rather than sending them. This is incredibly useful for lightweight environments where you don't want to install extra modules.

Add this to your settings.php:

// Prevent sending emails, store it in Drupal within the state system.
// Use drush sget system.test_mail_collector to see emails sent.
$config['system.mail']['interface']['default'] = 'test_mail_collector';

To retrieve the emails captured this way, you can use Drush or access them programmatically via \Drupal::state()->get('system.test_mail_collector', []);.

Rerouting Emails to a Single Address

Sometimes, you don't want to stop emails entirely; you just want to make sure they all go to you (the developer) instead of the actual user. This is where the Reroute Email module shines.

This module intercepts all outgoing mail and redirects it to a predefined address. It also appends a header to the email body explaining who the original recipient was, which is vital for testing complex workflows like multi-user notifications.

Configuration via settings.php

You can hardcode the rerouting logic in your environment-specific settings to ensure it is never accidentally disabled:

if (module_exists('reroute_email')) {
  // Enable email rerouting.
  $conf['reroute_email_enable'] = 1;
  // Send everything to a safe developer address.
  $conf['reroute_email_address'] = "[email protected]";
  // Include a message in the body about the reroute.
  $conf['reroute_email_enable_message'] = 1;
}

Environment-Specific Logic (Pantheon Example)

If you are using a hosting provider like Pantheon, you can automate the process of disabling mail based on the environment. This prevents the common human error of forgetting to change settings when moving from Dev to Live.

You can use a conditional block in your settings.php to detect the environment and set a custom flag. 

// Stop email on dev environment.
if (isset($_SERVER['PANTHEON_ENVIRONMENT']) && $_SERVER['PANTHEON_ENVIRONMENT'] === 'dev') {
  $conf['development_environment'] = TRUE;
}

Then, in a custom module, you can implement hook_mail_alter to act on that flag:

/**
 * Implements hook_mail_alter().
 */
function mymodule_mail_alter(&$message) {
  if (variable_get('development_environment', FALSE)) {
    // Prevent the mail from being sent.
    $message['send'] = FALSE;

    // Log the mail to watchdog for debugging.
    watchdog('Development Env', 'The following email was blocked: !message', array(
      '!message' => '<pre>' . print_r($message, TRUE) . '</pre>'
    ));
  }
}

External Tools: MailHog and MailCatcher

For professional local development setups (like DDEV, Lando, or custom Docker stacks), using an external "mail trap" is the gold standard. Tools like MailHog or MailCatcher act as a local SMTP server.

Instead of configuring Drupal to log to a file, you configure your PHP environment or Drupal's SMTP settings to point to the local service (usually on port 1025). These tools provide a beautiful web interface (usually on port 1080) where you can browse all outgoing mail as if it were a real inbox.

If you are using a standard PHP setup, you can change your sendmail_path in php.ini:

sendmail_path = /usr/bin/env catchmail -f [email protected]

This ensures that no matter what your Drupal configuration is, the server itself will catch the mail before it ever reaches the internet.

Frequently Asked Questions

Can I disable emails without any modules at all?

Yes. In modern Drupal, you can set the default mail interface to an empty string in your settings.php. This effectively breaks the mail delivery chain safely: $config['system.mail']['interface']['default'] = '';. Alternatively, using the test_mail_collector mentioned above is a cleaner way to do this without modules.

Why is hook_mail_alter better than disabling the SMTP module?

Using hook_mail_alter allows you to add logic. For example, you could allow emails to be sent to @yourcompany.com addresses while blocking all others. Disabling a module is a "nuclear" option that doesn't allow for this type of granular testing.

Does disabling mail affect the performance of my dev site?

Actually, it often improves it. Sending mail via an external SMTP server adds latency to the request. By switching to DevelMailLog or test_mail_collector, the "sending" process becomes a simple file write or database entry, making form submissions significantly faster during development.

Wrapping Up

Protecting your users from accidental emails is a critical part of a professional Drupal workflow. For quick debugging, the Devel module is your best friend. For rigorous testing of user workflows, the Reroute Email module or MailHog provides the best visibility.

Regardless of the method you choose, always ensure these overrides are placed in your settings.php or settings.local.php files to ensure they remain environment-specific and never accidentally make it to your production server.