Sending mail from your site

Your site sends email all the time, mostly without you thinking about it: a welcome message when someone registers, a link when they reset their password, a receipt after an order. This page is about that outbound mail — what works out of the box, what you should not try to send from your site, and what to check when a message doesn't arrive.

The short version: everyday site email just works, and newsletters belong somewhere else. Read on for why, and for the two-minute checklist when something looks stuck.

What works out of the box

The normal, one-at-a-time messages your site sends to individual people are handled for you. You don't have to set anything up, and you don't have to touch the server. This kind of mail is called transactional email, and it includes things like:

  • New-account and registration confirmations
  • Password-reset links
  • Order and payment receipts
  • "Someone replied to your comment" style notifications
  • Contact-form submissions landing in your inbox

If your site sends a handful of these to real people as they use the site, you're in the clear. Nothing to configure.

What not to send: newsletters and bulk mail

Sending a newsletter, a marketing blast, or any large batch of email straight from your site is discouraged, and on hosted BOA it is often blocked outright. Please don't do it. The kinds of sends that count as bulk mail are:

  • Marketing newsletters to a list of subscribers
  • Announcement or campaign emails to many people at once
  • Automated drip or re-engagement sequences
  • Anything that goes out to a list rather than to one person doing one thing

Here's why it matters, in plain terms. Your site shares its server — and the server's mail reputation — with other people's sites. If a big send from one site trips spam filters (a stale list, a bad batch, high bounces), the whole server's reputation can take the hit. Suddenly everyone's registration and password-reset emails start landing in spam or bouncing. So bulk sending isn't just risky for you, it's risky for your neighbours, which is why it's kept off these hosts.

The fix is easy and it's better for you anyway: send bulk mail through a dedicated email service provider (ESP).

Use an email service for newsletters

An ESP is a service built specifically to send lots of email well — they handle deliverability, unsubscribe links, bounce and complaint handling, and keeping off blocklists, all of which are a real job. Popular ones include Mailchimp, Brevo, SendGrid, Mailgun, Postmark, and Amazon SES; any reputable ESP is fine. BOA doesn't care which one you pick.

You can wire an ESP into your site in one of two common ways:

  • Manage the list at the ESP. Import your subscribers into Mailchimp (or similar) and compose and send campaigns from their dashboard. Your Drupal site isn't involved in the send at all — this is the simplest and most robust option for a newsletter.
  • Let your site send through the ESP. Install a Drupal SMTP module and point it at your ESP's SMTP details. Your site then hands each message to the ESP to deliver instead of sending it directly. This also improves delivery of your ordinary transactional mail — see the next section.

Either way, the actual sending happens at the ESP, on their reputation, not on the shared server's.

Sending through an SMTP service (optional but recommended)

If you want your everyday transactional mail to be as reliable as possible — or you want your site itself to send through your ESP — install a Drupal SMTP module on your site and configure it under:

/admin/config/system/smtp

That's a page in your own Drupal admin, in the site you already log into. You fill in the host, port, and username/password your ESP gives you, and your site routes its mail through that service from then on. Nothing about this needs the server or a support request — it's all in your hands, in the Drupal UI.

This is worth doing because a proper SMTP service takes care of the SPF, DKIM, and DMARC records that modern inboxes look for before they trust a message. Get that right and far more of your mail lands in the inbox instead of the spam folder.

How to tell if your site's mail is being sent

The most reliable check is simply to send a real message and watch for it:

  1. Trigger a message you can predict — for example, register a test account, or use your site's own "test email" feature if it has one (most Drupal SMTP modules add a test-message option to their settings page).
  2. Send it to an address you control (ideally at a different provider than the site's own domain).
  3. Wait a minute or two, then check both the inbox and the spam folder of that address.

If it arrives, your outbound mail is working. If it only ever shows up in spam, that's usually a deliverability problem — the SPF/DKIM/DMARC setup described above — rather than a "mail isn't being sent" problem, and moving your site to an SMTP service almost always clears it up.

When a message doesn't arrive

Work down this list before assuming anything is broken. Most missing mail is one of the first three.

Check on your side first:

  1. Look in the spam folder of the recipient. Delivered-but-filtered is by far the most common outcome, and it's a reputation issue, not a fault.
  2. Check the "From" address in your site's settings. If it's a made-up or mismatched address (like admin@localhost), inboxes distrust it. Set it to a real address at your own domain.
  3. Re-check your SMTP module settings if you use one — a wrong host, port, or password means nothing goes out. If the module offers a test-message option, it will tell you quickly whether the connection works.
  4. Confirm you're not sending in bulk. If you queued a newsletter from the site, that's the likely reason it stopped — move it to an ESP as above.

When it's not on your side: if your transactional mail (a single password-reset, say) genuinely isn't going out even with your From-address and SMTP settings correct, the cause may be on the server — for example the host's mail delivery being paused, or the server's IP address being on a blocklist. You can't see or change that from your account, and it isn't something you should try to fix. Open a support request with your host and describe exactly what you sent and when — that's the right and fastest path.

What you don't need to worry about

You may hear about mail "relays," sendmail permissions, or port-25 blocks on BOA. Those live on the server and are managed by your host — not settings in your account, and not files you edit. They exist to protect the shared mail reputation for everyone. (There is no per-account send quota or volume dial to worry about either — BOA doesn't meter how much transactional mail you send.) You never need to configure any of it; sending your transactional mail normally and pushing newsletters to an ESP is the whole of your responsibility here.

Related