Email configuration in PrestaShop: SMTP, Gmail and transactional email

Last reviewed June 2026, reflects the Gmail/Yahoo bulk-sender authentication rules that took effect in 2024. Provider limits and pricing shift, so confirm current figures with each provider. Back-office paths verified against PrestaShop 1.7, 8.x and 9.x.

"My customers aren't receiving their order confirmation emails." It's one of the most common support tickets a PrestaShop store owner ever opens, and it's almost never a PrestaShop bug. Email looks like the simplest part of running a shop, the platform sends a confirmation the moment an order is placed, but the path that message takes from your server to a customer's inbox runs through hosting restrictions, authentication records, and spam filters that all fail silently. The order goes through, the money is taken, and the customer hears nothing. So they email you, or worse, they assume the purchase didn't work and dispute the charge. This guide is specifically about getting reliable email delivery out of PrestaShop: the exact back-office settings, the SMTP provider choices that matter, the DNS records that keep you out of the spam folder, and how to prove it's actually working before a real customer is the one who finds out it isn't.

The two email methods PrestaShop gives you, and why one of them lies to you

Open Advanced Parameters → Email in your back office and you'll see PrestaShop offers two ways to send mail: the built-in PHP mail() function, and "Set my own SMTP parameters". The PHP mail() option hands your message to whatever local mail agent (Sendmail or Postfix) lives on your web server. On paper it works. In practice, on the shared and managed hosting most PrestaShop stores run on, it's the single biggest cause of "my emails vanished":

• Hosts disable it. Many providers switch off mail() entirely to stop spam abuse from compromised sites. PrestaShop may only see a successful local handoff, final delivery failures often appear only in server/provider logs, not the back office.
• It often carries no proper authentication. PHP mail() itself doesn't authenticate, so unless your server/MTA and DNS are deliberately configured, a message sent this way often lacks proper SPF, DKIM or DMARC alignment, and modern Gmail, Outlook and Yahoo treat unauthenticated mail from a bulk sender as spam by default. (Gmail and Yahoo formally tightened this for bulk senders in 2024.)
• It gives you no delivery feedback. The function returns true or false on handoff, not on delivery. "True" tells you the server accepted the message, nothing about whether it reached an inbox, bounced, or was filtered.
• It inherits a shared IP's reputation. On shared hosting you send from an IP dozens of other sites also use; if one of them spams, your order confirmations pay for it.

The practical takeaway is short: use SMTP, always, pointed at a real email service. The rest of this guide is about doing that correctly.

SMTP configuration in PrestaShop, field by field

In Advanced Parameters → Email, choose "Set my own SMTP parameters" and you'll be asked for the following. Every provider below fills these same boxes, only the values change:

• SMTP server, the provider's hostname (for example smtp.gmail.com).
• SMTP username, usually the full sending address, though some services use a fixed literal (SendGrid wants the word apikey).
• SMTP password, the mailbox password, an app-specific password, or an API key, depending on the provider.
• Encryption, TLS (port 587) or SSL (port 465). Never pick "Off"; that sends your credentials in the clear across the internet.
• SMTP port, 587 for TLS (the modern default) or 465 for SSL.

So what does getting these right buy you? A connection that authenticates as a legitimate sender, which is the precondition for everything downstream, DKIM signing, inbox placement, and a provider dashboard that actually tells you what happened to each message. Below are the three provider tiers most PrestaShop stores land in.

Gmail SMTP, fine for a small store, with a hard ceiling

Gmail is the most common first choice because the store owner already has the account. The settings:

To generate the App Password: in your Google Account go to Security → 2-Step Verification → App passwords, create one for "Mail" / "Other (Custom name)" labelled "PrestaShop", and paste the 16-character string into PrestaShop's SMTP password field. 2-Step Verification must be enabled first, Google won't show the App Passwords option otherwise.

The catch is volume. A free Gmail account is capped at roughly 500 recipients per day; Google Workspace lifts that to around 2,000. Each PrestaShop order typically fires two or three emails, customer confirmation, your admin notification, and a later shipping notification, so a store doing 100+ orders a day can brush against the free-Gmail ceiling, and once you cross it, mail starts getting deferred or rejected with no obvious signal in the back office. Gmail is a starter, not a destination.

Outlook / Microsoft 365 SMTP

Microsoft has been steadily restricting basic SMTP auth, so on many tenants you must explicitly enable Authenticated SMTP for the mailbox in the Exchange admin centre before PrestaShop can connect. If your connection test fails on Microsoft 365 with otherwise-correct credentials, that toggle is the usual reason.

Transactional email services. The answer once you have real volume

Past a few hundred messages a day, move to a service built for transactional sending: SendGrid, Mailgun, Brevo or Amazon SES. These give you dedicated sending reputation, automatic bounce and complaint handling, and a delivery dashboard, the things Gmail can't. SendGrid as an example:

Pricing and free-tier limits shift, so check the provider's current page rather than trusting a number in a blog post, but the structural advantage doesn't change: a sending IP whose reputation you (and the provider) actively manage, bounce data fed back to you, and per-message delivery status. For any store where a missed order confirmation costs you a support ticket or a chargeback, that visibility is the whole point.

Email authentication: SPF, DKIM and DMARC

Correct SMTP settings get the message out. Three DNS records decide whether the receiving server trusts it enough to put it in the inbox. Without them, even perfectly configured SMTP lands in spam. This is the second-most-common email complaint after "nothing sends at all," and unlike PrestaShop settings, these live in your domain's DNS, not the back office.

SPF, who's allowed to send as you

SPF (Sender Policy Framework) is a DNS TXT record listing the servers permitted to send mail for your domain. A receiving server checks it to confirm the message came from an authorised source. A typical record for a store sending through Google plus SendGrid:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Only include services you genuinely send from, each extra include slightly weakens the record, and SPF has a hard limit of 10 DNS lookups before it fails outright.

DKIM. A signature that proves nothing was tampered with

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every message, proving it came from your domain and wasn't altered in transit. Your provider generates the key; you publish it as a TXT or CNAME record. For Google Workspace on a custom domain, enable it under Apps → Google Workspace → Gmail → Authenticate email. For SendGrid, use Settings → Sender Authentication → Authenticate Your Domain, which hands you CNAME records to add to DNS.

DMARC. What to do with mail that fails the first two

DMARC ties SPF and DKIM together and tells receivers how to treat messages that fail. Start in monitoring mode so you break nothing:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

This reports failures to you without blocking anything. After a few weeks of clean reports, tighten to p=quarantine (route failures to spam) and eventually p=reject (block them). Moving straight to p=reject before you've confirmed your legitimate mail passes is how stores accidentally block their own order confirmations.

Getting the "From" address right (a quiet deliverability killer)

PrestaShop's sender address is set in Shop Parameters → Contact → Stores (and the per-shop contact email). A subtle but very common failure: that "From" address must align with the domain you've authenticated for SMTP. Sending as info@yourstore.com while authenticating through smtp.gmail.com as a @gmail.com identity creates an authentication mismatch that SPF/DMARC will flag, and your mail drops to spam even though every individual setting "looks" correct. Keep the sending domain, the SMTP identity and the authentication records all pointing at the same place.

Proving it works, before a customer proves it doesn't

Don't trust a settings screen that says "saved." Test the actual delivery path:

• PrestaShop's built-in test. On the Advanced Parameters → Email page there's a "Send a test email" field, send one to yourself and confirm it reaches the inbox, not spam.
• mail-tester.com. Send a message to the address it shows you; it scores SPF, DKIM, DMARC, content and blacklist status out of 10. Aim for 9+ before you call it done.
• Test across providers. Send to Gmail, Outlook/Hotmail and Yahoo separately. Their spam rules differ, and passing one doesn't mean passing all three.
• Read the headers. In a received Gmail message, three dots → Show original and look for SPF: PASS, DKIM: PASS and DMARC: PASS. If any says FAIL or NONE, fix the matching DNS record before going live.

Transactional vs marketing email. Keep them on separate rails

This guide is about transactional email: order confirmations, shipping notices, password resets, the messages PrestaShop fires automatically as a direct result of a customer action. Treat these as a different stream from marketing newsletters and promotions, because mixing them costs you:

• Reputation contamination. If your newsletter gets spam complaints and rides the same IP/domain as your order confirmations, it drags the order confirmations down with it.
• Different legal rules. Transactional mail doesn't require an unsubscribe link (it's necessary to complete the purchase); marketing mail legally does. Keeping them separate keeps the compliance line clean.
• Volume spikes. A 50,000-recipient newsletter blast can saturate a shared SMTP connection and delay the time-sensitive order confirmation a customer is waiting on.

Best practice: send PrestaShop's transactional mail through your SMTP service, and run newsletters from a dedicated platform (Mailchimp, Brevo, Klaviyo). If you want those two worlds connected, say, pushing a new PrestaShop customer into your newsletter list automatically, wire them together with an automation layer rather than mixing sending streams; we cover the no-code way to do that in Zapier and Make for PrestaShop and, specifically for workflow triggers, PrestaShop and Zapier without writing code.

The "email not sending" troubleshooting list

These are the cases that come up most when merchants ask us to look at broken PrestaShop email, in roughly the order worth checking them.

Nothing sends at all

• Read the email log first. When logging is enabled, Advanced Parameters → Email lists the messages PrestaShop attempted to send (recipient, template, subject, time). If messages are logged but not arriving, PrestaShop is generating and handing them off but they're failing downstream (authentication or spam). If nothing is logged at all, the send is failing before that point, re-check SMTP host, port and credentials, and confirm logging itself is turned on.
• Re-test the credentials directly. Log into the mailbox or provider console with the exact username and password you pasted into PrestaShop. If you can't, neither can PrestaShop.
• Check the port isn't firewalled. Some hosts block outbound 587/465. If the connection test times out, ask your host to confirm those ports are open for outgoing traffic.

Mail sends but lands in spam

• Missing or failing SPF/DKIM. Verify with mxtoolbox.com that both records exist and pass for your domain.
• From-address mismatch. See the "From" section above. This is the most overlooked spam cause.
• Spammy template content. Heavy "free / discount / act now" language and a poor text-to-image ratio in custom templates trip content filters.

Intermittent failures

• Rate limiting. You're crossing the provider's daily send cap; check your real volume against the plan's limit and upgrade the provider if you've outgrown it.
• Connection timeouts. A slow SMTP server can exceed PrestaShop's default connection timeout, raising it (for example from 5 to 20 seconds) often clears flaky sends.

Sent successfully, but the customer says nothing arrived

Check the customer's address for a typo, check your provider's bounce log, and ask them to look in spam and whitelist your sending address. "Sent" in PrestaShop only means the message was accepted by the SMTP server. The provider dashboard is where you see whether it bounced. Once you've confirmed the address is right and the deliverability cause is fixed, you'll want to re-send that specific confirmation rather than leave the customer empty-handed: our Resend Order Confirmation module re-fires the order confirmation straight from the order page, so a one-off delivery miss doesn't turn into a manual rebuild of the email.

Customizing PrestaShop's email templates

PrestaShop's email templates can live in several mails/<language_code>/ locations, core, theme and module mail directories, depending on your version, theme and installed modules, each type as an HTML file plus a TXT plain-text fallback. Newer versions (1.7/8/9) also let you edit the look in Design → Email Theme. A few rules that keep customized templates rendering everywhere:

• Use inline CSS, many email clients strip <style> blocks.
• Lay out with tables; email HTML rendering is effectively stuck in 2005.
• Keep the width under 600px for mobile.
• Test in several clients (Gmail web, Outlook desktop, Apple Mail, mobile).
• Never delete the placeholders like {firstname}, {lastname} or {order_name}, PrestaShop swaps in real data at send time, and removing them breaks the merge.

Logging and real delivery monitoring

When email logging is enabled, PrestaShop records every send attempt to its database, viewable at Advanced Parameters → Email, with the recipient, the template used, the language, the subject and the time of sending. But remember what an entry in that list means: PrestaShop handed the message to the SMTP server. It is not proof of inbox delivery, and the log carries no per-message delivered/bounced status. For that truth you need your provider's dashboard, SendGrid, Mailgun and Amazon SES all report delivered, bounced, deferred and complaint rates per message. Glance at those weekly; a creeping bounce rate is the early warning that a deliverability problem is forming before customers start noticing.

Frequently asked questions

Why aren't my PrestaShop order confirmation emails being delivered?

The most common cause is using PHP mail() on hosting that disables it or sends it unauthenticated, modern Gmail, Outlook and Yahoo bin unauthenticated bulk mail. Switch to "Set my own SMTP parameters" under Advanced Parameters → Email, point it at a real email service, and publish SPF, DKIM and DMARC records. Then prove the path with a test before trusting it with live orders.

Which SMTP port and encryption should I use?

Port 587 with TLS is the modern default and what most providers recommend; port 465 with SSL is the older alternative and still works. Never choose "Off", that sends your credentials unencrypted. If a connection test times out on either port, your host may be blocking outbound SMTP and you'll need to ask them to open it.

Can I just use my Gmail account to send store emails?

For a small store, yes, use smtp.gmail.com on port 587/TLS with a 16-character App Password (not your login password, and 2-Step Verification must be on first). But a free Gmail account caps at roughly 500 recipients/day and Workspace at around 2,000. Since each order fires two or three emails, a store past ~100 orders/day will hit that ceiling and mail starts silently deferring. Gmail is a starter, not a destination, move to SendGrid, Mailgun, Brevo or Amazon SES at volume.

My email sends but lands in spam, what's wrong?

Almost always missing or failing authentication, or a From-address mismatch. Verify SPF and DKIM exist and pass (mxtoolbox.com), and make sure your "From" address domain matches the domain you authenticate SMTP through, sending as info@yourstore.com while authenticating as a @gmail.com identity is flagged by SPF/DMARC and dropped to spam even when every setting "looks" correct.

A customer says they never got their confirmation, what now?

First confirm it's a real miss: check the address for a typo and your provider's bounce log ("Sent" in PrestaShop only means the SMTP server accepted it, not that it was delivered). Fix the underlying deliverability cause, then re-send that specific confirmation rather than leaving them empty-handed, Resend Order Confirmation re-fires it from the order page in a click.

Should order confirmations and my newsletter go through the same service?

No. Keep them on separate rails. If your newsletter draws spam complaints and shares an IP/domain with your transactional mail, it drags your order confirmations down with it. Send transactional mail through your SMTP service and run newsletters from a dedicated platform (Mailchimp, Brevo, Klaviyo). Connect the two with an automation layer if you need to, rather than mixing sending streams.

Where email fits in a store that's outgrowing manual work

Reliable transactional email is the foundation, but it's rarely the only place a growing store leaks time and information. The same order event that triggers a confirmation email usually also needs to reach your accounting system and, eventually, your ERP, and copying that data by hand is exactly the kind of manual work that breaks at volume. If you're at the point where order emails are sorted but the rest of your back office still runs on copy-paste, those are the next dominoes:

• Accounting. Getting each order's invoice data into Xero or QuickBooks automatically, rather than re-keying it, see connecting PrestaShop to your accounting software.
• ERP. When stock, orders and customers need to stay in sync with a back-office system, the integration patterns that actually hold up are covered in PrestaShop-to-ERP integration patterns, and the signals that it's time in when your store outgrows manual work.
• No-code glue. For the lighter connections, pushing a new customer into a list, posting an order to a tool. See Zapier and Make for PrestaShop.

Email deliverability is unglamorous, and that's exactly why it gets neglected until a customer who never got their confirmation opens a dispute. Get SMTP onto a real provider, publish your SPF, DKIM and DMARC records, align your "From" address, and prove the whole path with a test before you trust it with live orders. For modules that extend PrestaShop's store-management and integration capabilities, built to survive PrestaShop and PHP version upgrades rather than break at the next one, browse the catalogue at mypresta.rocks.