Your store is sending the emails. The problem is that nothing tells your customers’ mail providers to trust them. Here is the mechanism, and what the benchmark found.
You have probably seen this one. A customer emails to ask whether their order went through, because they never received a confirmation. You check the admin, and the order is right there, processed fine. The confirmation was sent. It is sitting in their spam folder.
The instinct is that something in PrestaShop’s email is broken. It almost never is. The email sent perfectly well. The problem is that nothing on your side told the customer’s mail provider the message was genuinely from you, so the provider did the safe thing and treated it as suspicious.
Your store is sending. The provider isn’t trusting.
When PrestaShop sends an order confirmation, it travels to the customer’s mail provider, Gmail, Outlook, or wherever they read mail. Before showing it, the provider asks one question: can I verify this really came from this store, and not from someone impersonating it? Email is trivially easy to forge, so providers are strict about this, and they answer the question by checking a few records published on your domain.
If those records are missing, the provider cannot confirm the mail is legitimate. Faced with an unverified message claiming to be a store, its safest move is the spam folder. Your confirmation did everything right except prove who sent it.
The records that vouch for you: SPF, DKIM, and DMARC
Three records on your domain do the vouching. SPF lists which servers are allowed to send email in your name. DKIM adds a signature that proves the message was not altered on the way and really came from your domain. DMARC states what a provider should do when a message fails those checks, and ties the whole thing together.
PrestaShop, like any self-hosted platform, sends the mail but does not set these up for you. They live in your domain’s DNS, not in PrestaShop, so configuring them is a separate step, and it is a step many stores never take. The setup is well understood and covered in the email authentication guide; the point here is how often it is simply absent.
What the benchmark shows
Missing email authentication is not a PrestaShop quirk. It is the single most common failure of any kind across the whole study: 34,755 stores, on every platform, had no valid SPF record at all. It tops the list of the most common problems we found.
On PrestaShop specifically, the enforcement layer was missing even more often. 12,460 PrestaShop stores, more than 60% of the PrestaShop sample, had no DMARC policy, which means that even where some authentication existed, nothing told providers how to handle a message that failed the check. For a self-hosted platform where email authentication is left to the merchant, that is a large share sending every message without a complete authentication policy behind it. (Method and the full four-platform sample, about 20,000 stores each, are in the 2026 platform benchmark.)
Why it stays broken
It persists for the reason so many of these problems do: it is invisible from where you stand. The order shows up in your admin. You may well receive your own copy, because mail from your own domain to your own inbox often behaves differently. There is no error, and no bounce you would notice. The whole failure happens on the customer’s end, in a spam folder you never see.
So the store goes on sending confirmations that quietly go unread, and the only outward sign is the occasional “did my order go through?” message, which almost never gets traced back to its actual cause.
Why it is worth fixing
A customer who does not receive a confirmation is not reassured, they are worried. They open support tickets, they wonder whether the store is real, some ask for a refund or dispute the charge, and a good number do not come back. Transactional email is the only voice a store has with a customer in the minutes after they have paid, which is exactly when trust is most fragile. In the spam folder, that voice is silent.
What to actually check
The fix is narrow and entirely within reach. In practice that means checking:
- whether your domain has an SPF record, and whether it lists the servers your store actually sends from (your host’s mail servers, or any SMTP or email service you route through);
- whether DKIM signing is in place, so your mail carries a valid signature;
- whether a DMARC policy exists to tie the two together and tell providers what to do;
- whether your store sends through an authenticated path rather than raw server mail.
The how for all of this is in the email authentication guide, and it sits alongside the other self-hosted exposure problems that come with running your own server. The part specific to PrestaShop is that the platform sends the mail and leaves the proof of identity to you.
The same check that found those 12,460 PrestaShop stores with no DMARC policy is the one a scan runs on a single store, and it is the quickest way to see whether your order emails can prove they came from you, before they reach a spam filter that assumes they cannot.