Configure and troubleshoot PrestaShop email delivery

What we would do

We would trace a real failed message before changing providers. The right route depends on your installed PrestaShop and PHP versions, mail modules, order and ERP integrations, theme overrides, customer languages and address data, markets, DNS access and the team available to monitor failures. Keep a working sending route when the evidence points to a trigger, template or recipient problem.

For a transport, sender or template change, use a private staging copy with controlled recipients and isolated integrations. Rehearse the affected messages, preserve the old configuration and plan the live switch with someone watching real sends. A mailbox migration, an outgoing SMTP change and a template repair have different scopes.

Choose the first check from the evidence

If you want an agreed email configuration task handled for you, the PrestaShop Full-Day Store Setup Service can include order-email work in a scoped setup backlog.

Understand the sending and delivery path

When an expected message is missing, first identify its trigger, recipient, shop, language and time. The failure can occur before rendering, during transport, after a local server accepts it, at the relay or at the receiving mailbox. Spam placement is one possible outcome, not the explanation for every missing email.

A local sendmail/MTA can authenticate and sign outgoing mail if it is correctly configured. A remote SMTP service can provide managed delivery and useful events, but changing transport alone does not guarantee authentication or inbox placement. Sender authorisation, DNS alignment, reputation, recipient policy and message content all matter.

Protect order confirmations, payment/status messages, password resets and account emails according to their purpose. Count actual messages and recipients across customer mail, staff notifications, order changes and other sends before choosing quotas. Orders per day is not a reliable sending-volume conversion.

Check the actual From address and shop contact details, commonly under Shop Parameters > Contact. Keep an address authorised for the shop’s sending domain in From. Use the customer’s address in Reply-To for a contact request, rather than impersonating the customer’s domain.

Check your version’s mailer and configuration

Use Advanced Parameters > E-mail or Email, depending on translation and release, to select the mail method, format, logging and SMTP settings. Check the current shop context in multistore.

Do not prescribe MAILER_DSN in .env.local as a core override. PrestaShop 9.1 Mail::Send() reads PS_MAIL_* values and constructs its own transport. A separate customisation may use a DSN, but you must identify it before applying Symfony application configuration recipes.

Modules that instantiate Swift classes or alter Swift-specific message objects need an implementation compatible with PrestaShop 9. Test order, contact, account and module messages after upgrading the platform or PHP.

Port and encryption are a pair

Use the provider’s documented secure submission settings. Port 587 commonly uses STARTTLS, while 465 uses TLS from connection start. Port 465 is a current standardised submission method, as described in RFC 8314. A UI label of “SSL” commonly refers to implicit TLS.

Verify the exact core build after an upgrade. In PrestaShop 9.1, any non-off encryption value is passed as a true TLS constructor argument to Symfony’s SMTP transport, which selects implicit TLS. That implementation must not be assumed to perform STARTTLS merely because the dropdown says TLS. If your provider requires STARTTLS on 587, check the transport behaviour and supported core fix; use a provider-supported implicit-TLS endpoint where appropriate. Keep certificate validation enabled.

Configure SMTP and prove the transport works

1. Obtain the SMTP hostname, port, encryption mode, authorised sender, username and credential type from the actual account. Map them to the SMTP server, port, encryption, username and password fields; the username is not necessarily the From address. Record whether the credential is for SMTP or for a separate API integration.
2. Confirm that the host can resolve and reach the service. Check outbound firewall rules and the provider’s allowed sending IPs where applicable.
3. Select your own SMTP parameters in the back office and enter those values. Use a dedicated credential where supported, with only the permissions needed.
4. Send the built-in test message. Inspect the immediate result and the relay’s events. Keep the recipient, timestamp and timezone, selected shop and exact error text so the host and provider can find the same attempt.
5. Check actual receipt, spam placement and full headers. Then place a test order and exercise password reset and the contact form.

A successful built-in test means the selected transport accepted the test message. A local MTA may still have it queued. A remote relay may accept it and receive a later bounce. None of those observations proves inbox placement.

If submission fails, separate DNS, TCP connection, TLS negotiation, authentication and sender-policy errors. A mailbox password, app password, SMTP-specific credential and API token are not interchangeable.

Blocking port 587 does not rule out every transactional provider. Check documented alternative SMTP ports or a supported HTTPS API integration, or arrange the required firewall change. Do not change to an arbitrary port or disable TLS to bypass the problem.

Rehearse the change and plan the switch

1. Record the current transport, sender identities, DNS records, mail format and template sources. Keep credentials in an access-controlled store; a screenshot with a masked password is not enough to restore a working connection.
2. On the copy, stop scheduled campaigns, customer notifications and exports to ERP or fulfilment systems. Use test customers and addresses your team controls. Check modules with their own sending route, since changing core SMTP does not necessarily redirect their mail.
3. Use a provider-supported sandbox or recipient restriction where available. A test subject prefix alone does not prevent delivery to real customers. Do not bulk replay copied orders or password resets.
4. Exercise order creation, the intended order-state messages, tracking notification, account mail, password reset and contact reply. Include affected modules, active customer languages, shop contexts and attachments. Open reset and account links only for controlled test accounts and check that they use the intended shop domain.
5. For each case, record the trigger, resolved template, recipient, sender, provider event and received result. Compare the HTML and text parts, links, totals and any PDF with the source order. Confirm that the test did not create an unintended order or external fulfilment task.
6. Agree who changes the live settings, who can edit DNS and who watches the first real messages. Retain the previous sending authorisations while legitimate senders still need them. Restore the recorded configuration if acceptance checks fail, then investigate the failed attempt before retrying.

A staging shop using the production sending domain can still affect real DNS policy and shared quotas. Separate test credentials where supported and control recipients at every sending route. A provider account or sender identity verified on staging is not proof that the live shop has the same settings.

Changing outbound SMTP does not require changing inbound MX records. If you are also moving business mailboxes, plan mailbox contents, aliases, forwarding and access separately so customer replies remain accessible during the switch.

Gmail, Workspace and Microsoft 365

Gmail and Google Workspace

Google SMTP commonly uses smtp.gmail.com with the account’s supported secure port. For a password-based client without Google sign-in, an app password can be available after 2-Step Verification is enabled. Organisation policy, Advanced Protection and other account settings can prevent its use.

Use the full account address where required and verify which From addresses Google permits. Do not enter the normal account password as a universal solution. Check the account type and sending method’s current message, recipient and rate limits. Workspace SMTP relay and mailbox submission have different limits and policies.

Microsoft 365

Authenticated client submission commonly uses smtp.office365.com and STARTTLS on 587, provided the application actually implements that transport correctly. Review the tenant, mailbox and authentication policies. Enabling the mailbox SMTP AUTH toggle does not override an authentication policy that prohibits Basic authentication.

Microsoft’s published timeline keeps existing SMTP AUTH Basic authentication behaviour unchanged until December 2026 and introduces further default restrictions at the end of December. Review the current timeline before deployment.

Choose a supported OAuth-capable integration or an authorised relay route when password submission is not suitable. OAuth requires an integration that obtains and refreshes tokens; the core username/password fields do not implement that flow. Do not weaken tenant-wide security merely to copy an old setup recipe.

Set SPF, DKIM and DMARC correctly

SPF: authenticate the envelope sender

SPF checks the envelope sender domain, or HELO identity in the relevant case. Publish one SPF policy record for that name and authorise only the services that send for it. Multiple unrelated TXT records are fine; multiple SPF policies beginning with v=spf1 at the same name are a problem.

Use your providers’ documented mechanisms. SPF permits at most 10 evaluated DNS-lookup-causing mechanisms and modifiers, including those reached through nested includes. Exceeding this limit produces PermError. Validate the complete policy. A subdomain does not automatically inherit its parent’s SPF policy. Do not use +all to solve a rejection.

DKIM: authenticate a signing domain

DKIM signs message content and selected headers. Publish the public key or provider-directed CNAME at the specified selector. Keep the private key protected. The relay/MTA can sign; PrestaShop 9.1 also supports configured DKIM signing. Whether a message is signed depends on those settings, rather than on remote SMTP alone.

DMARC: align authentication with visible From

DMARC compares the visible From domain with an aligned, passing SPF envelope domain or DKIM signing domain. Either aligned passing mechanism can satisfy it. The SMTP login name and server hostname do not have to share the visible From domain. See the alignment model in RFC 7489.

# Illustrative monitoring record for _dmarc.example.com.
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Inventory every legitimate sender and read the reports before moving to p=quarantine or p=reject. Advance based on actual authenticated traffic rather than a fixed number of weeks. Configure a real reporting address and any required authorisation for external reports.

Putting a customer in From does not itself determine SPF, but it can break DMARC alignment with the shop’s authenticated sender. Keep From authorised and Reply-To useful. MX records route inbound mail; correct MX alone does not authenticate outgoing shop mail.

For example, a contact request has buyer@example.net in From and a passing DKIM signature for example.com. That signature alone does not align with the visible From domain. Use an authorised shop address such as contact@example.com in From and the buyer’s address in Reply-To, then inspect the receiving provider’s authentication results. Changing only the displayed sender name does not change the From domain.

Choose a transactional service and separate streams

Consider a managed service when you need different quotas, provider events, bounce/complaint handling or an operational model you can maintain. Compare the exact plan, region, support, retention, authentication and shared/dedicated IP arrangements. A paid plan does not automatically supply a dedicated IP or the best inbox rate.

Mailgun, Postmark, Amazon SES, SendGrid and Brevo are examples to assess using their current account documentation. Connect SMTP through core where supported, or use a supported API integration. A dashboard’s SMTP credential can differ from its API key, and some accounts begin with sender or recipient restrictions.

For a current plan example, SendGrid advertises a 60-day trial with up to 100 Email API messages daily. It is not an indefinite free tier; suitable plan selection is needed to continue sending. Do not budget from old provider price tables.

Separate transactional and marketing streams, identities, quotas and complaint handling. One provider can support both when its architecture and policies give suitable separation. A large campaign must not exhaust the route used for password resets and confirmations.

Keep necessary service messages and promotional material distinct. Review applicable marketing consent and opt-out requirements for the actual jurisdiction and content. A message is not exempt from those rules merely because its subject says “order confirmation.”

Evaluate shared hosting and self-hosted mail

For hosting SMTP, obtain the account’s actual endpoint and quotas rather than copying generic cPanel, OVH, Hostinger or other host settings. Shared sending pools can expose you to other senders’ reputation. Check DNS access, authenticated sending, logs, TLS and outbound-port policy.

A VPS gives you control over some settings, but hosting providers can still impose port, rate or acceptable-use limits. A new IP does not arrive with a proven sending reputation. Assess reverse DNS/PTR, hostname consistency, outbound connectivity, TLS, patches, monitoring and backup/recovery capacity.

Self-hosting keeps the sending infrastructure under your control; external delivery still sends messages and recipient data to the recipient’s providers. Other processors, logs and backups also matter. Review privacy and regulatory duties for the complete delivery and storage process.

Mailcow’s documented default minimum is 6 GiB RAM plus 1 GiB swap, with additional sizing for users and enabled services. Compare its full operational requirements before deployment. If you consider Mail-in-a-Box or iRedMail, compare their current system and operating requirements too.

Budget sysadmin time as well as infrastructure. Set any reputation ramp-up from observed sending behaviour and provider feedback, rather than promising a fixed two-week warm-up or automatic savings above a message threshold.

Find and customise the template actually used

Core templates commonly live under mails/<iso>/. The PrestaShop 9.1 resolver checks the active theme, its parent and core for the relevant mail path. Module mail can use modules/<module>/mails/<iso>/, including the corresponding theme override path. Inspect the sending call and resolver before deciding which file to edit.

mails/en/order_conf.html
mails/en/order_conf.txt
themes/your-theme/mails/en/order_conf.html
themes/your-theme/mails/en/order_conf.txt
themes/your-theme/modules/module-name/mails/en/template.html

The Email Theme generation system was introduced in 1.7.6. It uses Twig-based layouts to generate localised mail files. Sending generated HTML/TXT uses placeholder replacement, which is different from compiling a Smarty template. Modules may have their own rendering pipelines.

A missing TXT file can block modes requiring it. It is not simply a spam signal. Check every enabled customer language and any custom theme override: an incomplete override can take precedence over complete core files.

1. Back up the current template and work in a suitable theme override or maintained mail theme.
2. Preserve the information needed for the email’s purpose. Inspect the actual sending PHP to find supported placeholders.
3. Use conservative email HTML and tables where needed. Keep essential styling inline for email clients that discard embedded styles. A layout around 600 pixels can be a starting point, but test responsive behaviour rather than forcing every client to a fixed width.
4. Use absolute HTTPS URLs for external images and links. Check rendering with remote images blocked.
5. Test the HTML and plain-text output in the mail clients your customers use. Regeneration can overwrite generated files, so keep source changes and overrides under control.

Removing a placeholder removes its value from that output; it does not inherently break all substitutions. Avoid inventing placeholders such as a universal {items}: the order-confirmation sender defines the actual product-list variables for that release.

Worked example: English succeeds, French fails

Suppose the built-in SMTP test and English confirmations arrive, but French order confirmations fail after a theme change. In a mail mode requiring both files, the active French override contains order_conf.html but lacks order_conf.txt. Trace the resolver and error for that order to confirm the missing file before editing DNS or replacing the relay.

Restore a complete, translated pair in the maintained template source, check the placeholders against the actual sender, then repeat a French test order and inspect both received parts. Check the English case again and document whether email-theme regeneration replaces either file. A preview of the HTML alone would not expose the missing text template.

Check order states and message triggers

order_conf is sent during core order creation. Order-state notifications use the selected state’s configured send_email flag and language-specific template. There is no universal core order_changed template for all transitions.

The core tracking-number notification uses in_transit. Payment, account and password-recovery messages have their own triggers and templates. Do not rename a file to “shipping” or “payment” without checking which sender actually calls it.

If the built-in test works but a real order message does not, inspect the trigger first. Check state settings, customer language, available template files, required attachments and custom module hooks. Measure rendering/PDF time separately from SMTP connection and read timeouts.

Do not expect a failed synchronous send to be queued and retried automatically. Identify the queue/retry implementation, if any, and its processing/alerting. Once the cause is fixed, resend only the intended message through a supported shop workflow. Resend Order Confirmation adds a confirmation resend action to the order page and orders list, using the customer’s current email address and the order’s language and original shop without changing its status, totals or dates. Check the displayed recipient before confirming the resend.

Use logs, headers and provider events

With email logging enabled, the core mail table records successful transport handoffs. It does not record every failed attempt or maintain a delivered/bounced/spam status. Local handoff success may precede remote SMTP acceptance.

1. Check whether the correct event ran and whether email/logging is enabled for that shop.
2. Inspect PrestaShopLogger and application, PHP and mail-server errors around the same time. Verify actual log locations rather than assuming one filename exists.
3. Check relay events for accepted, deferred, rejected, bounced or complained messages. Correlate recipient, time and message/provider IDs.
4. Inspect the received message’s original headers for SPF, DKIM and DMARC results and the domains they authenticate. In Gmail, use Show original in the message menu. Keep the original message rather than a normal forwarded copy, which can hide or change the evidence.
5. Check the address for typos, recipient mailbox rules, spam placement and any suppression record. A message placed in Promotions is not necessarily undelivered.

Use DNS diagnostics and a controlled test message to investigate. Mail-tester can highlight authentication, content and blocklist issues; a high score is not proof of delivery. MailSenpai’s current checker gives immediate domain results without requiring an email address, with an optional emailed report.

Test independent recipient providers relevant to your customers, such as Gmail, Outlook and Yahoo. A mailbox on your own domain may use the same backend as another test account. Do not call that a fixed percentage of customer coverage.

Use Google Postmaster Tools where sufficient Gmail volume and authorised domain access make its data available. Review DMARC reports, provider rejects, bounces and complaints. Recheck after DNS, sender, hosting or core changes. Do not monitor the mail table for failure statuses it does not contain.

Intermittent failures need a timeline

Compare a failed attempt with a successful one from the same shop and sending route. Look for campaign overlap, account throttling, network delays, scheduled jobs or a change in message type. Include recipients and staff copies when comparing traffic with the provider’s limits; a quiet order count can hide a busy mail stream.

• Temporary deferral: inspect who retained the message and who will retry it. If the relay has queued it, repeated manual sends can produce late duplicates.
• Permanent rejection: read the diagnostic and correct the address, sender policy or other stated cause before attempting the same message again.
• Slow order response: time rendering, attachment creation and transport separately. A longer connection timeout cannot repair a missing template or a slow PDF generator.

If you need a console command, inspect the exact installation’s command list first. Do not apply a guessed timeout setting or disable certificate checks as a generic repair.

Work through a missing confirmation without repeating the purchase

A customer reports a charge but no confirmation. First match the payment reference to the existing order and check the recorded email address. If the order is missing or the payment state is unresolved, follow the payment integration’s reconciliation process before creating or validating anything. An email problem alone is not a reason to ask the customer to pay again.

Suppose the order exists and the provider event for its confirmation reports suppression following an earlier hard bounce. A new SMTP password will not clear that recipient-specific cause. Check the address with the customer through an established support route, inspect why it was suppressed and use the provider’s supported process only when the cause is resolved. Do not bypass a complaint or unsubscribe policy to force delivery.

If an address correction is needed, use the supported customer workflow after appropriate identity checks. Send the intended confirmation to the verified current address, record the action and inspect its provider event. Avoid a blanket resend to everyone who ordered during the incident: some messages may already have arrived or remain queued, and account or reset messages have different purposes.

Diagnose duplicate confirmations without creating more orders

Compare message bodies, subjects, full Message-IDs, timestamps and recipients. Then inspect actual order IDs and transaction references. The same order reference does not prove there is only one order row: core can create multiple orders from one cart’s packages and send a confirmation for each.

• One order, separate sends: inspect custom mail calls, order-state templates, Mail Alerts and other notification modules, overrides and hooks.
• Multiple order rows: distinguish legitimate package splitting from duplicate order creation for a payment. Inspect cart, provider transaction and package mapping.
• One application send, repeated delivery: inspect the MTA/relay retry and recipient-provider records.
• Return plus webhook: verify idempotent order/payment processing. Core rejects a normal second validation for an already ordered cart, but concurrent or custom paths still require investigation.

This read-only query lists candidate hook registrations for shop 1 using the ps_ table prefix. Replace that prefix and the hm.id_shop = 1 condition with your installation’s prefix and intended shop ID before running it. It does not prove that a module sends mail or that a registration executes twice.

SELECT h.name AS hook_name, m.name AS module_name,
       hm.id_shop, hm.position
FROM ps_hook_module hm
JOIN ps_hook h ON h.id_hook = hm.id_hook
JOIN ps_module m ON m.id_module = hm.id_module
WHERE hm.id_shop = 1
  AND h.name IN ('actionValidateOrder', 'actionValidateOrderAfter',
                 'displayOrderConfirmation', 'displayPaymentReturn')
ORDER BY h.name, hm.position;

Use staging or a controlled diagnostic window when disabling a suspected sender. Do not change order states repeatedly or call order validation again just to resend an email. Correct the duplicate path, then test one order and one repeated callback.

What to ask your developer or agency

• Which component sends each core and module message, and does any route bypass the configured transport?
• Which exact shop release, PHP version, theme override and customer languages were tested? Can you provide the resolved template paths and received test messages?
• Who controls DNS, provider access, credentials and bounce reports, and how can the shop owner recover that access when a supplier changes?
• What retries a failed message, how are unresolved failures surfaced to staff, and how do we avoid resending a message already queued at the relay?
• What are the live acceptance checks and rollback steps, and who monitors delivery after the change?

Ask for a short record linking the observed fault, the change and the resulting test. Share redacted error text, relevant references and headers through an appropriate support channel; SMTP credentials, reset links and unnecessary customer details do not belong in a general ticket.

Questions owners ask

Will replies and delivery failures reach the same address?

Not necessarily. Replies use Reply-To where present, otherwise From; delivery failures normally follow the envelope return path. Check both routes with the provider and give staff access to the relevant mailbox or event dashboard.

Why do tests disagree after a DNS change?

Resolvers can retain earlier answers until their cache expires. Check the authoritative record, the domain and selector used by a newly sent message, and the receiving provider’s result. Do not keep changing the record because an old message still shows the earlier authentication outcome.

Can I resend an old password-reset email once delivery works?

Use the supported recovery flow for a fresh customer request. An earlier link may be expired, used or affected by a later account change. Do not replay archived reset messages or copy recovery links into a general support ticket.

Who should read bounce and DMARC reports?

Assign someone with access to the provider account and DNS maintainer, plus a backup contact. They should distinguish invalid recipients from authentication or policy failures and escalate a pattern affecting service mail. A reporting mailbox nobody reads does not provide an operational response.