Why Your Magento 2 Transactional Emails Are Not Sending

Start here: the 60-second triage

Before you touch a single SMTP field, answer four questions in order. The large majority of “Magento not sending email” cases are solved at step one or step two, and jumping straight to SMTP wastes hours.

1. Is asynchronous sending on, and is cron actually running? (The usual culprit.)
2. Can the server send mail at all, or is Magento handing messages to an unconfigured sendmail?
3. Is the sending domain authenticated with SPF, DKIM, and DMARC so mail is not silently dropped or spam-filed?
4. Is the specific email type enabled, and does its template still compile?

Cause number one: async sending plus a dead cron

Since Magento 2.3, order, invoice, shipment, and credit memo emails are not sent during the web request. When sales_email/general/async_sending is enabled (the default), Magento marks the sales row with send_email = 1 and email_sent = NULL, then moves on so checkout stays fast. A background cron job, sales_send_all_emails in Magento_Sales, is what actually queries those rows and sends the mail. If cron is not running, that job never fires and no email ever leaves the box, no matter how perfect your SMTP settings are.

Check the setting and the backlog first:

# 1 = async (queued), 0 = send during the request
bin/magento config:show sales_email/general/async_sending

-- how many order emails are waiting to be sent?
SELECT entity_id, increment_id, email_sent
FROM sales_order
WHERE send_email = 1 AND email_sent IS NULL;

If that query returns rows, the pipeline is fine but the flush never ran. Confirm cron is installed and alive for the web user, then force the due jobs:

crontab -l | grep magento
tail -n 50 var/log/cron.log
# run it twice: the first pass schedules jobs, the second executes them
bin/magento cron:run
bin/magento cron:run

After cron runs, re-check the query above. The email_sent column should flip to 1 and the mail should be on its way. If cron is not installed at all, that is its own problem, walked through in fixing Magento cron when it is not running.

Force a send to prove the pipeline

To separate a queue problem from a mail-transport problem, take cron out of the equation and send synchronously. Turn async off, flush config cache, and place a test order:

bin/magento config:set sales_email/general/async_sending 0
bin/magento cache:flush
# now place a real test order in the storefront

If the confirmation email arrives with async off but not with async on, your problem is cron or the consumer, so go back to the previous section. If it still does not arrive with async off, the message is failing at the transport layer, which means SMTP. Turn async back on once you finish testing; synchronous sending slows checkout under real load.

Magento has no built-in SMTP

This surprises people coming from other platforms. Out of the box, Magento’s Magento\Framework\Mail layer hands every message to the local mail transport, PHP’s mail() function, which in turn calls the server’s sendmail binary. On a typical container or VPS that binary is either missing, unconfigured, or sending from an IP with no reputation, so the mail is refused or dropped straight into spam. There is no host, port, or password field in core Magento because core does not speak SMTP.

The fix is an SMTP extension that routes mail through a real transactional provider (a dedicated email service, not a personal mailbox). This store runs Mageplaza SMTP. After installing it, configure it under Stores > Configuration > Mageplaza Extensions > SMTP:

• Host and Port: your provider’s relay, commonly port 587 with STARTTLS or 465 with SSL.
• Authentication: LOGIN, with the API user and key or password from the provider.
• Protocol: TLS or SSL to match the port you chose.

Then use the extension’s Send Test Email button. A green result means the credentials and TLS handshake are correct; a failure here reports the exact SMTP error (auth rejected, connection refused, TLS mismatch) before you waste time elsewhere. You can confirm the module took over transport from the CLI:

bin/magento config:show smtp/general/enabled
bin/magento config:show smtp/configuration/host

Deliverability: SPF, DKIM, DMARC, and the From address

Once SMTP works, mail can still vanish if the sending domain is not authenticated. Mailbox providers now treat unauthenticated mail as spam by default. Three DNS records on your sending domain do the heavy lifting:

• SPF: a TXT record listing the servers and providers allowed to send for the domain.
• DKIM: a public key your provider gives you, published as a TXT record, so recipients can verify the signature the provider adds to each message.
• DMARC: a policy record that tells receivers what to do when SPF or DKIM fail, and where to send reports.

Inside Magento, the sender identities must match the authenticated domain. Set them under Stores > Configuration > General > Store Email Addresses, or read them on the CLI:

bin/magento config:show trans_email/ident_general/email
bin/magento config:show trans_email/ident_sales/email

Use an address on your own domain, for example orders@yourstore.com. Never send from a free mailbox like @gmail.com or @yahoo.com: their DMARC policies reject mail sent by a third party on their behalf, so those order emails bounce outright. Finally, open your provider dashboard. Bounces, blocks, and complaints logged there tell you whether the provider accepted the message and exactly what the recipient server said back.

Per-type toggles and broken templates

Every transactional email type has its own on/off switch, and a disabled type sends nothing with no error at all. Check them under Stores > Configuration > Sales > Sales Emails (order, invoice, shipment, credit memo) and under Customers > Customer Configuration for the welcome email. The config paths are worth knowing:

bin/magento config:show sales_email/order/enabled
bin/magento config:show sales_email/invoice/enabled
bin/magento config:show sales_email/shipment/enabled

The second silent killer is a custom email template with a bad directive. Magento email templates use a restricted directive syntax, and an unbalanced or non-whitelisted directive throws an exception during rendering, so the send aborts before the message is even built. Common offenders are a stray or nested {{depend}}, a {{var}} pointing at data the email context does not expose, or a leftover comment that is not a real directive. If email broke right after someone edited a template in the admin, that template is the first suspect: revert it to the default and test again.

Where to look: logs and the queue tables

Turn on email logging so failures are recorded instead of disappearing. Mageplaza SMTP has an Email Log that captures every attempt with its status and error message; enable it and read that grid first. At the framework level, watch the standard logs while you place a test order:

tail -f var/log/system.log var/log/exception.log var/log/debug.log

A template directive error shows up in exception.log, and an SMTP auth or connection failure shows up wherever your extension logs. For queued mail that looks stuck, inspect the message queue tables directly:

-- generic message queue backlog
SELECT COUNT(*) AS queued FROM queue_message;
SELECT status, COUNT(*) FROM queue_message_status GROUP BY status;

-- bulk and async operation records; read the recent result_message values
SELECT id, status, result_message FROM magento_operation
ORDER BY id DESC LIMIT 20;

Rows piling up in queue and queue_message with nothing draining them, or failing magento_operation records, both point straight back to a consumer or cron that is not running, the same root cause as the first section.

The quick decision list

Run down this list top to bottom and stop at the first “no.”

1. Is cron alive? crontab -l | grep magento and a fresh var/log/cron.log. No cron means no queued mail, ever.
2. Are consumers running? bin/magento queue:consumers:list plus a running process (or cron’s consumer runner) for background work.
3. What is the async setting? config:show sales_email/general/async_sending, and test with it off.
4. Is an SMTP extension configured? Core has none, so send a test email from the extension.
5. Sender identity plus SPF, DKIM, DMARC? An own-domain From address, with all three DNS records passing.
6. Does the template compile? No broken {{depend}} or {{var}}; revert custom templates to test.
7. Is the email type enabled? sales_email/*/enabled and the welcome-email toggle.