LiveChat 
Support 
Magento 2 Order Confirmation Email: Configure, Customize, and Fix Delivery
The Magento 2 order confirmation email is the first transactional message a customer receives after placing an order, and it sets the tone for the entire post-purchase experience. When it arrives promptly, branded, and well-formatted, it reassures buyers and reduces support tickets. When it never arrives, you get anxious customers, chargebacks, and lost trust. This guide walks through configuring, customizing, and troubleshooting order confirmation emails in Magento 2 (Adobe Commerce Open Source), with particular attention to the most common reason these emails silently fail: the email queue and cron.
Key Takeaways
• Order confirmation emails are configured under Stores > Configuration > Sales > Sales Emails, and templates are customized under Marketing > Email Templates.
• Magento 2 does not send transactional emails instantly. It queues them and dispatches them through cron, so a stalled or missing cron job is the number-one cause of “email not sending.”
• Reliable delivery depends on a correctly configured mail transport (SMTP is strongly recommended over default sendmail) plus SPF, DKIM, and DMARC authentication.
• Always test with a real inbox and check spam placement, not just whether Magento reports the email as sent.
How Does the Magento 2 Order Confirmation Email Actually Work?
Understanding the sending flow is the key to troubleshooting it. In Magento 2, when a customer completes checkout, the platform does not immediately hand the message to your mail server. Instead, it creates the order, generates the email content from a transactional email template, and places the message into a database queue table. A scheduled cron job then picks up queued emails and dispatches them in batches.
This decoupled, asynchronous design keeps checkout fast and resilient, because the customer is not forced to wait on a potentially slow mail server. The trade-off is a hard dependency: if cron is not running, queued emails sit in the database forever and the customer never receives anything. This single architectural fact explains the majority of “order confirmation email not sending” reports.
A subtle consequence many store owners miss: because emails are queued and sent by cron rather than at checkout, the Magento admin order page can still show the order as placed and even mark the email as “sent” once cron processes the queue. The order being successfully created tells you nothing about whether the email left your server. Always treat order creation and email delivery as two separate systems with two separate failure points.
How Do You Configure the Order Confirmation Email in Magento 2?
All sending behavior for order emails lives in one place. Navigate to Stores > Configuration > Sales > Sales Emails in the admin.
Within this section you will find an Order group that controls the order confirmation email specifically. The settings that matter most are:
- Enabled — must be set to *Yes* for the email to send at all.
- New Order Confirmation Email Sender — the store contact identity (for example, Sales or Customer Support) used as the visible sender.
- New Order Confirmation Template and New Order Confirmation Template for Guest — which transactional template renders for registered customers versus guests.
- Send Order Email Copy To — a comma-separated list of addresses that receive a BCC or separate copy, useful for monitoring.
- Send Order Email Copy Method — choose between BCC and a separate email.
There is also a global Asynchronous sending toggle under Stores > Configuration > Sales > Sales > General. When asynchronous sending is enabled, emails are always queued for cron. When disabled, Magento attempts to send during a cron run differently, but in all standard configurations cron remains involved. The store contact identities themselves (the “from” names and addresses) are defined under Stores > Configuration > General > Store Email Addresses, so make sure those are filled in with real, monitored mailboxes on your domain.
How Do You Customize the Order Confirmation Email Template?
The default template is functional but generic. To brand it, go to Marketing > Email Templates and click Add New Template.
From the Template dropdown, load the New Order (and New Order for Guest) default template as a starting point so you inherit the correct structure and variables. Edit the subject and HTML content, then save. Finally, return to Stores > Configuration > Sales > Sales Emails > Order and select your new custom template in the New Order Confirmation Template dropdown so Magento uses it instead of the default.
Templates use Magento’s variable syntax to inject order data. Common variables you will work with include the following.
| Template variable | What it renders | |
|---|---|---|
| `{{var order.increment_id}}` | The customer-facing order number | |
| `{{var order.getCustomerName()}}` | The customer’s full name | |
| `{{var order_data.is_not_virtual}}` | Whether the order has shippable items | |
| `{{var formattedShippingAddress\ | raw}}` | The formatted shipping address block |
| `{{var formattedBillingAddress\ | raw}}` | The formatted billing address block |
| `{{layout handle=”sales_email_order_items” order=$order}}` | The line-item table of purchased products | |
| `{{var store.frontend_name}}` | The store name for branding | |
| `{{trans “Thank you for your order”}}` | A translatable static string |
Always preview and send a test before going live. A broken variable or unclosed tag can cause the template to fail to render, which in some cases prevents the email from sending at all. Keep your logo hosted on a reliable, fast URL so it loads in every inbox.
Why Is My Magento 2 Order Confirmation Email Not Sending?
When emails do not arrive, work through these causes in order, from most to least common. Use this checklist to isolate the failure:
- [ ] Is cron running? Confirm a system cron job invokes Magento’s scheduler (typically `php bin/magento cron:run`) every minute. No cron means no queued email ever leaves. This is the first thing to check, every time.
- [ ] Is the email queue backed up? Inspect the email queue tables and the `cron_schedule` table for jobs stuck in a `pending` or `error` state.
- [ ] Is Sales Email enabled? Verify *Enabled = Yes* under Stores > Configuration > Sales > Sales Emails > Order.
- [ ] Are store email addresses valid? Empty or malformed sender addresses cause silent failures.
- [ ] Is the mail transport configured? Default sendmail/PHP mail frequently fails or lands in spam on shared and cloud servers. Confirm SMTP credentials if you use an SMTP extension.
- [ ] Did the template break? A custom template with a syntax error can stop rendering. Revert to the default to test.
- [ ] Is the message being filtered? Check the recipient’s spam folder and your sending domain’s reputation.
- [ ] Are there errors in the logs? Review `var/log/system.log` and `var/log/exception.log` for mail-related exceptions.
If you can manually flush the queue with a cron run and the email then arrives, you have confirmed cron scheduling as the root cause. If the queue flushes but mail still does not arrive, the problem is downstream in your mail transport or deliverability.
Should You Use SMTP or Default Sendmail in Magento 2?
By default, Magento hands outbound mail to the server’s local mail transport (PHP `mail()` / sendmail). On a well-configured dedicated mail server this can work, but on most modern hosting environments it is unreliable: messages are often rejected, throttled, or sent straight to spam because the server’s IP lacks a trusted sending reputation and proper authentication.
SMTP is the recommended approach. Routing transactional email through an authenticated SMTP service (your own mail server or a dedicated email-sending provider) gives you:
- Authenticated, trackable delivery with proper credentials rather than anonymous local relay.
- Better inbox placement because reputable SMTP services maintain warmed-up IPs and enforce authentication.
- Bounce and error visibility so you can see when a message fails instead of guessing.
In Magento 2 you typically enable SMTP through a dedicated SMTP extension or module, then enter your host, port, encryption (TLS/SSL), username, and password. After configuring it, send a test email from the extension and from a real order to confirm both paths work.
How Do You Ensure Order Emails Reach the Inbox?
Getting Magento to *send* is only half the job; getting messages *delivered* to the inbox is the other half. Deliverability is governed by domain authentication standards that receiving mail servers check before trusting your mail.
- SPF (Sender Policy Framework) — a DNS TXT record listing which servers are authorized to send mail for your domain. Add the IPs or includes of whatever sends your Magento mail.
- DKIM (DomainKeys Identified Mail) — a cryptographic signature added to each message, verified against a public key in your DNS. It proves the message was not tampered with and genuinely came from your domain.
- DMARC — a policy record that tells receivers what to do when SPF or DKIM fails, and gives you reporting on abuse and misconfiguration.
Always send from an address on your own domain (for example, `[email protected]`), never from a free webmail address, because free providers’ policies will cause authentication failures. After configuring these records, test against a deliverability checker and inspect message headers to confirm SPF and DKIM both pass.
Reliable Magento 2 Hosting and Email From DarazHost
Most order confirmation email failures trace back to two infrastructure problems: cron that is not running reliably and a mail setup that lacks proper authentication. Both are hosting concerns. DarazHost provides hosting environments built for Magento 2 and ecommerce workloads, with the resources to keep cron jobs executing on schedule so your email queue never stalls. Our platform supports proper mail and SMTP configuration alongside professional domain email with SPF, DKIM, and DMARC authentication, so your transactional messages are trusted and land in the inbox rather than the spam folder.
Beyond email, DarazHost delivers the performance ecommerce stores need — fast page loads and stable checkout under traffic — backed by 24/7 support from a team that understands Magento. If you are tired of debugging why confirmation emails vanish, a hosting platform that handles cron and mail authentication correctly removes the guesswork. and .
Frequently Asked Questions
Why does my Magento 2 order confirmation email take a long time to arrive? Magento queues transactional emails and sends them on a cron schedule rather than instantly. A short delay is normal and reflects the cron interval. If emails take many minutes or never arrive, cron is likely not running every minute or the queue is backed up.
Can Magento 2 send order confirmation emails without cron? No. In standard configurations the order email is queued and dispatched by Magento’s scheduler, which runs via cron. Without a working cron job, queued emails are never processed and customers receive nothing, even though the order is created successfully.
Where do I change the “from” name and address on order emails? Set the store contact identities under Stores > Configuration > General > Store Email Addresses, then choose which identity the order email uses under Stores > Configuration > Sales > Sales Emails > Order in the *New Order Confirmation Email Sender* setting.
Do I really need SMTP, or is default sendmail enough? On most shared and cloud hosting, default sendmail is unreliable and frequently lands in spam. Authenticated SMTP gives you better inbox placement, error visibility, and trackable delivery, so it is strongly recommended for any production store.
My emails send but land in spam — how do I fix that? Spam placement is almost always a deliverability and authentication issue, not a Magento bug. Configure SPF, DKIM, and DMARC for your sending domain, send from an address on your own domain, and route mail through a reputable authenticated SMTP service.
