Why Aren't Your PrestaShop Order Confirmation Emails Reaching Customers?

Order confirmation emails reassure customers that their purchases have gone through and help them track what happens next. When these emails fail to arrive, customers may worry about their orders, contact support, or even place duplicate orders.

For PrestaShop merchants, missing emails can point to issues with store settings, SMTP configuration, or email delivery. Let’s explore the common causes and how to make sure your order confirmations reach customers reliably.

Why Aren't My PrestaShop Order Confirmation Emails Reaching Customers?

An order comes in, the payment clears, and the customer hears nothing from your store.

PrestaShop order confirmation emails usually fail because PHP mail() is unreliable on shared hosting, the sending domain lacks SPF/DKIM/DMARC authentication, the order status never triggers the email, or PrestaShop's SMTP settings are misconfigured. Switch to authenticated SMTP, verify DNS records, and test via Advanced Parameters > Email.

That answer only helps once you know which layer is failing. Think of delivery as four stacked gates: the message has to be generated (code and configuration), handed off to a mail server (transport), trusted by receiving providers (DNS authentication), and placed in the inbox rather than spam or a promotional tab. A break at any gate produces the same customer complaint: no email, or one hiding in junk.

Most merchants replace the module when the real fault sits in DNS or transport, two layers nothing in PrestaShop controls.

Treat this as triage, not guesswork. Start at the top of the stack and work down:

• Configuration: is the order status set to trigger a confirmation at all, and is the mail method correct?
• Transport: is PHP mail() quietly dropping messages on a shared server, or does authenticated SMTP carry them?
• Authentication: do SPF, DKIM and DMARC records exist for the domain in your From address?
• Placement: are delivered messages landing in spam, filtering or a promotional folder?

Placement alone eats a bigger share than most store owners expect. Email Deliverability Benchmark found global inbox placement just below 85 percent, so roughly one in six legitimate emails never reaches an inbox. That gap costs real money: customers missing receipts assume the order failed, then email support or open a chargeback.

The rest of this guide gives you a 10-minute triage flow and a permanent SMTP fix, so you can move from "I think emails are broken" to a tested, authenticated sending path.

For your marketing stream, PrestaShop Advanced Newsletter gives you a controlled way to build subscriber lists and send custom emails from the same shop, so you can confirm your sending path works outside the checkout flow too.

How Does PrestaShop Actually Send Order Confirmation Emails?

Before you change a single setting, know the exact route a confirmation email takes. PrestaShop does not fire it the moment a customer clicks "Order with an obligation to pay". The sequence starts earlier and has five distinct stages.

1. The order is created with an initial state (usually "Awaiting payment" or "Awaiting bank wire payment" for a bank transfer, or a pending state during card validation).
2. A state change to "Payment accepted" happens when the payment module confirms the transaction, or when you manually move the order to that state in the Orders list.
3. The Mail Alerts module picks up the event and queues the order_conf email template, filling it with order details, carrier info and product lines.
4. The template renders using your shop's theme overrides and language files.
5. The message is handed to a transport (PHP's mail() function by default or an SMTP server if you have configured one), which passes it to the receiving mail server (the MTA).

The single most misunderstood part is stage two. If an order never reaches "Payment accepted", the order confirmation email never sends no matter how healthy your server is. That is why the same PrestaShop install can deliver some confirmations and silently drop others: the trigger state simply was not reached.

Stage five is where the "silent" part of the leak happens. PHP's mail() hands the message to your host's local mail transfer agent, and whether that MTA is properly authenticated, has a clean sending IP, and respects SPF and DKIM records is outside PrestaShop's control. The permanent fix, covered later, is replacing mail() with an authenticated SMTP connection.

Finally, the content itself is templated: order_conf pulls from your theme's mail folder, so a missing or edited template file will break rendering without any error reaching the customer. The PrestaShop customer account verification by email module sends a separate activation message, which is a useful comparison point when testing whether mail travels at all.

Triage in 10 Minutes: Which Layer is Failing?

A PrestaShop order confirmation email passes through five checkpoints: the mail transport, the sending module, the order status trigger, the server queue, and the recipient's inbox. Testing them in order stops you from rebuilding your SMTP settings when the real fault is a status toggle nobody ticked.

Run these five checks back to back. Each gives a pass or fail signal that points straight at the next fix.

1. Send A Test Email. Go to Advanced Parameters > Email and use the "Send a test email" tool. If it arrives, your transport and DNS are broadly working. If it fails or never appears, stop here and go to the mail transport fixes.
2. Check the Order's Message Log. Open the order in Orders > Orders and look at the customer messages panel. A logged confirmation means PrestaShop generated the email; an empty panel means it never fired.
3. Check the Server Mail Log. Look at /var/log/mail.log on a VPS, or the email deliverability log in your hosting panel. You want to see whether the message was handed off, rejected, or queued.
4. Confirm Mail Alerts is on. In Modules > Module Manager, search for Mail Alerts and check it is enabled, installed and showing as hooked (not "transplanted" to a missing position). This module is what triggers the order confirmation in most stores.
5. Check the "Payment Accepted" Status. In Shop Parameters > Order Settings > Statuses, open "Payment accepted" and confirm "Send email to customer" is ticked. If it isn't, every paid order stays silent.

Read the results as a map rather than a score. Test email fails but logs show a delivery attempt: suspect DNS authentication. Test email passes but the message panel is empty: suspect the status or the module. Logs show a rejection from your provider: suspect a sending limit or a blocked mail() function.

One failed checkpoint narrows the fault to a single layer, so you fix one thing instead of rebuilding five. Write down which check failed before you touch any configuration, because changing three settings at once leaves you blind to which one actually solved it.

PrestaShop SMTP vs PHP Mail() for Order Confirmations: Which Should You Use?

PHP mail() hands your order confirmation to the local mail transfer agent and walks away. It never authenticates against your sending domain, and it has no idea whether Gmail accepted the message or quietly binned it. This is why a confirmation that shows as "sent" in PrestaShop can be missing from the customer's inbox minutes later.

PrestaShop's legacy mail transport is that same PHP function by default. For a live store processing orders, it is the single most common reason confirmations land in spam or disappear entirely.

If order confirmations matter to your revenue, send them over authenticated SMTP, not PHP mail().

Transactional providers such as Brevo, Mailgun, SendGrid, Amazon SES, and Postmark are built for this traffic. They authenticate your domain, expose delivery logs, and report hard bounces back so you can act.

To switch, go to Advanced Parameters, then Email. Set Send mail to "Always send" while testing, choose SMTP as the method, and enter the host, port (587 for TLS, 465 for SSL), encryption and credentials from your provider. Save, then use the built-in test email field. OAuth authentication is offered on some PrestaShop versions and providers, so check the options on your screen before assuming password login is the only route.

The DNS Layer: SPF, DKIM and DMARC Fixes That Stop Gmail and Outlook Filtering You

Even a working SMTP connection can still land every order confirmation in spam if your sending domain isn't authenticated. Gmail, Outlook and Yahoo all check three DNS records, SPF, DKIM and DMARC, before deciding whether to trust a message. If they're missing or misaligned, your mail is treated as suspicious even when the content is a legitimate order receipt.

The catch that trips up most stores is alignment. The domain in those DNS records must match the domain in PrestaShop's Shop Parameters > Contact email settings, specifically the "From" address your transaction emails use. If you send from orders@yourstore.com but authenticate yourstore.com through a third-party sender, the domains won't align and DMARC still fails you.

Work through the records in this order:

• SPF: publish a single TXT record listing your sending provider's include. If your provider is Mailgun, Brevo or your host's mail server, add exactly the mechanism they document, for example, include:_spf.mailgun.org. Never publish two SPF records on the same domain, because receivers treat that as a hard fail.
• DKIM: your provider generates a public key and hands you a DNS TXT record to publish under a selector hostname. Copy it exactly, including any quotation marks, then send a test order and check the authentication results in the received headers.
• DMARC: add a TXT record at _dmarc.yourstore.com. Start with p=none so you receive reports without blocking mail, then tighten to p=quarantine once the reports show SPF and DKIM passing for everything you send.
• Alignment: confirm the From domain in PrestaShop matches the domain you authenticated. Swapping to a subdomain sender is fine only if you publish the records on that subdomain too.

SPF and DKIM prove the message left a server you authorised, and DMARC ties that proof back to the domain customers actually see. Skipping any one of the three leaves a gap a spam filter will exploit.

Order Status, Mail Alerts and Template Problems that Silently Drop Confirmations

If your SMTP and DNS layers are clean but confirmations still vanish, the fault is usually inside PrestaShop itself. These causes are deceptively quiet: the order completes, the customer sees the thank-you page, and no email is ever generated.

Start with the Mail Alerts module under Modules > Module Manager. If it is disabled, or has been unhooked from the displayOrderConfirmation and actionValidateOrder hooks, PrestaShop has nothing telling it to send an order email. Re-enable it and re-hook it from the module's position controls.

Next, check your order states under Shop Parameters > Order Settings > Statuses. The state that fires the confirmation (normally Payment accepted) must carry the Send email to customer flag and a valid email template attached. Without that flag, validation changes the order status but sends nothing.

• A From address that uses a domain your host will not relay, such as a mailbox hosted elsewhere, is often rejected outright.
• A corrupted or edited order_conf template in your theme's mails folder can throw a silent exception during rendering.
• A customer email typo, or guest checkout where the address was mistyped, means the message goes nowhere valid.
• Another module hooked into order validation and overriding mail sending can block the default behaviour.

The confirmation template and its attachments are the fragile part, so test order_conf on a staging copy before every theme update. Clear PrestaShop's cache afterwards, then place a test order and watch the mail logs.

Step-by-step Fix: From Broken to Inbox in 20 Minutes

You have diagnosed where the failure sits. Now run the repair in order, testing after each step so you know exactly which change fixed it.

Fix the trigger first: a perfect SMTP setup still sends nothing if the order status never fires the email.

1. Confirm Mail Alerts is Active and The Trigger Fires. In the PrestaShop back office, open Modules and check that Mail Alerts (the built-in mailalerts module) is installed and enabled. Then place a test order and move it to the "Payment accepted" status, watching the customer's order history to confirm the status change actually saved. If no email appears in MailHog or in the sending provider's log, the problem is the trigger, not delivery.
2. Switch from PHP Mail() to Authenticated SMTP. Go to Advanced Parameters, then Email, set "Send mail with" to SMTP and enter the host, port, encryption, username and password from your transactional provider (SendGrid, Mailgun, Postmark, Brevo or Amazon SES all work). Click "Send a test email" and confirm it arrives.
3. Publish SPF, DKIM and DMARC Records. Add the SPF and DKIM records your provider supplies in the domain's DNS zone, then publish a DMARC record starting at p=none so you can monitor before enforcing. Wait for DNS propagation (usually under an hour) before sending anything important.
4. Send Real Test Orders to Gmail and Outlook. Place two genuine orders, one to a Gmail address and one to an Outlook or Hotmail address. Open each received message, choose "Show original" in Gmail or "View message source" in Outlook, and read the authentication results line, which should show spf=pass, dkim=pass and dmarc=pass. Any "fail" or "softfail" sends you back to stage three.
5. Set up Bounce and Complaint Handling. Register a return-path or bounce address with your provider and connect your DMARC rua reporting address so hard bounces and spam complaints are visible. Prune the addresses that bounce instead of ignoring them.
6. Re-test Weekly with A Seed Inbox. Keep a dedicated Gmail and Outlook address that you never mark as spam, place one small test order each week, and check that the confirmation still reaches the inbox rather than the promotions or spam folder. This catches DNS drift and IP reputation problems before customers do.

Once the seed inbox receives clean, authenticated confirmations week after week, the leak is closed. Anything still landing in spam at that point is a reputation issue, not a configuration one.

If slow follow-up emails matter as much as the receipt, PrestaShop AI abandoned cart reminders keep recovery messages flowing over the same authenticated path.

How Do I Test Deliverability Without Pestering Real Customers?

Send to a seed list instead of your customer file. A seed list is a handful of mailboxes you control across the big providers: one Gmail, one Outlook or Hotmail, one Yahoo, one iCloud, and a Gmail account set to a different language or region to spot filtering differences. Place a real test order on your PrestaShop store, then open the confirmation in each mailbox and check where it lands.

In Gmail, open the message, click the three-dot menu and choose "Show original". The panel lists SPF, DKIM and DMARC with a pass or fail result for each. If any of the three says fail, stop editing templates and go back to your DNS records, because no amount of wording tweaks will fix an authentication failure.

For a scored opinion, run the same message through mail-tester.com or GlockApps. Mail-tester gives a score out of 10 and names the specific issues, while GlockApps shows inbox, spam and missing placement across many providers at once. Treat any authentication warning as the priority and ignore cosmetic suggestions until that clears.

Make it a habit: once a week, place a low-value test order and repeat the seed check. A small recurring task like this catches a lapsed DKIM key or a new blocklist entry before it quietly eats a weekend of sales, and it costs nothing but ten minutes.

An order confirmation email that never arrives is one of the quietest ways a PrestaShop store loses money. The customer paid, waited for proof, got silence, and now wonders whether the order even exists. In most cases, the cause is one of three things: PHP mail() being dropped or filtered into spam, a domain missing SPF and DKIM authentication, or an order that never reaches the status triggering the confirmation. Each section above diagnoses one cause, tells you how to spot it, and gives you the fix. Work top to bottom, because the simplest causes are also the most frequent.

Symptoms of A Broken Order Confirmation

Before you change a single setting, confirm you are actually facing the missing-confirmation problem and not something adjacent. These are the tells that point to the email pipeline rather than a checkout bug.

• The order appears in Orders with a valid status, but the customer says no email arrived.
• Emails reach some customers (usually Gmail or Outlook users on their domain) but not others.
• Confirmation emails land in the customer's spam or junk folder instead of the inbox.
• You receive the new-order alert yourself, so email is leaving the shop, but the customer copy never shows up.
• Test emails from the back office arrive, yet real transactional emails do not.
• Customers email you asking "did my order go through?" minutes after checkout.
• Messages bounce with SPF, DKIM, or "message rejected" errors.
• Order confirmations arrive hours late, or not at all, on busy sale days.

If even your own test email fails, the problem is transport. If tests pass but customers stay silent, the problem is more likely triggering, spam filtering, or authentication.

What Causes This Problem?

Every missing confirmation traces back to one of a handful of causes. The table below ranks them by how often they show up in real support tickets, from most to least common.

Quick Fixes to Try First

Each step below is fast, and most stores find their answer within the first four. Rule out the basics before you start editing configuration files.

1. Open Orders in the back office and check the order's status. If it is not "Payment accepted" or another status configured to send, the confirmation has not fired yet.
2. Go to Advanced Parameters > Email and resend the confirmation manually to test whether the template works at all.
3. Send a test email from the same screen. If it fails, the transport is the issue, not the order.
4. Check Modules > Module Manager and confirm Mail alerts is installed and enabled.
5. Verify the "from" address under Shop Parameters > Contact belongs to your own domain, not a free Gmail or Hotmail address.
6. Ask the customer to check spam and junk. Deliverability problems often show up here first.
7. Confirm your shop can send any email (password reset, contact form) to see whether the whole pipeline is down.
8. If you have just migrated hosts, recheck the mail settings, as the new server may not have the same outbound configuration.

If all eight pass and the customer still has nothing, move into the diagnostic chapters above. The fastest way to stop this happening to your next order is to switch from PHP mail() to authenticated SMTP.

Diagnose It: Cause 1. PHP mail() Is Being Filtered or Dropped

By default, PrestaShop can send through PHP's built-in mail() function. That function hands your email to the local server with almost no reputation behind it. Gmail, Outlook, and Yahoo increasingly treat such unauthenticated mail as suspect.

Why it happens: mail() sends from your web server's IP and does not sign the message or prove your domain is authorised. The receiving provider sees an unverified sender and decides whether to inbox, spam, or reject it. Industry data shows a large share of legitimate email never reaches the inbox at all, and a shop's transactional mail is not immune.

How to identify it: test emails sometimes arrive, but transactional ones vanish, or deliverability varies from one provider to the next.