Occasionally, your website's users may not receive emails from your Drupal website. There can be several reasons for this, including the following:
This article provides information about how to troubleshoot email issues and how you can resolve some of the issues that can occur when sending email from your website.
When testing your email settings, it's often preferred to do so in a way that does not require emailing all of that environment's users. The following contributed Drupal modules can help you save emails to your logs instead of actually sending emails. The recommended module to do this depends on the version of Drupal you have installed:
Drupal 8 version and above
Download and install the Helper module, which has a mail handler that writes all emails to the database log. After you install the module, add the following code to your settings.php
file to use the Helper module's mail handler:
<?php
$config['system.mail']['interface']['default'] = 'helper_logger';
?>
After you send an email from your website, in the admin menu, go to Reports > Recent log entries to view the email's details.
Download and install the Helper module, which has a mail handler that writes all emails to the database log. After you install the module, add the following code to your settings.php
file to use the Helper module's mail handler:
<?php
$conf['mail_system'] = array('default-system' => 'HelperDebugMailLog');
?>
After you send an email from your website, in the admin menu, go to Reports > Recent log entries to view the email's details.
Websites with different hosting providers that can access mail servers can review the server's email log files. These log files are normally located in /var/log/exim4/
and you can use them to ensure both that Drupal sent the email, and that the server accepted the email.
If you don't see any errors in the log file for the email, and if you didn't receive a bounce to the return address (for example, [email protected]
), the email was successfully sent.
If the email was successfully sent but not delivered to the intended recipient, the problem is usually either that the end user's spam filter caught the email, or that some email server along the path to the user stopped the email (for example, due to over aggressive deny-listing). In this case, try the following:
on behalf of [customer_URL]
where [customer_URL]
is the Acquia customer's website URL
Sender Address Rejected
), examine the Sender Policy Framework (SPF) record. To deal with unwanted email, some email servers refuse email with FROM addresses based on a domain from an unrecognized email server. Email servers use SPF (as defined in RFC 4408) to validate the hosts and domains that are allowed to send email. For more information about SPF records, see the Adding DNS records for Platform Email article.Some email campaigns contain personalized links, so that you can track the number of users who respond to the email and visit your website. This, while valuable for tracking, can cause performance issues. Since each visit in response to the email uses a unique URL, your website will not be able to serve the webpage out of cache. Furthermore, since many visitors are likely to click on the link shortly after receiving the email (if at all), your website is likely to experience a spike in traffic that can't be handled by the cache.
You can avoid these performance issues by not using unique URLs in email campaigns, if possible.
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Wed Oct 22 2025 08:59:29 GMT+0000 (Coordinated Universal Time)