Your store's emails are not arriving: SMTP, SPF, DKIM and DMARC explained

"I haven't received the order confirmation." If you hear this often, the problem is not the customer. Email providers (Gmail, Outlook, Yahoo and the rest) are increasingly strict about the messages they receive, and an email that does not properly prove where it comes from ends up in spam or is rejected outright. For a store, that means anxious customers, calls to customer service and passwords nobody can recover.

Let us look at how PrestaShop sends emails and what needs configuring so they arrive.

How PrestaShop sends emails

In Advanced Parameters → E-mail you choose how email goes out:

• The server's PHP mail function. It is the default and the most convenient, but the email leaves from the web server, which is often not authorised to send on behalf of your domain. It is the most frequent cause of emails landing in spam.
• An SMTP server. The store connects with a username and password to a real mailbox (your email provider's or a transactional email service's) and sends through it. This is the recommended option.

On that same screen you can send a test email. Use it after every change, and send it to mailboxes at several providers.

The three checks the recipient makes

SPF: who may send on behalf of your domain

It is a TXT record in your domain's DNS that lists the servers authorised to send email with your domain as the sender. When an email arrives, the recipient checks which server it comes from and whether it is on that list.

Typical mistakes:

• Having two SPF records on the same domain. There can only be one; if there are two, the check fails. When you add a new service, you extend the existing record rather than creating another.
• Not including everyone who sends: the store's server, the email provider, the newsletter tool, the ERP that sends invoices.
• Exceeding the lookup limit. SPF allows at most ten DNS lookups during evaluation, and every include counts (along with any nested inside it). With many services, it is exceeded without anyone noticing.

DKIM: the message signature

The sending server signs each email with a private key and publishes the public key in your domain's DNS. The recipient checks the signature: if it matches, the message comes from who it claims and has not been altered on the way.

It is enabled by the provider that sends (your email service or transactional email service), which gives you the record to add to the DNS. If you use the web server's PHP mail function, there is normally no DKIM signature, or there is one with the hosting provider's domain, not yours.

DMARC: what to do if it fails, and to be told about it

It is another TXT record, at _dmarc.tudominio, that tells recipients what to do with an email claiming to come from your domain that does not pass SPF or DKIM in an aligned way (that is, with the same domain as the visible sender). It has three policies:

• p=none: do nothing special, just report to me.
• p=quarantine: treat it as suspicious (usually, send it to spam).
• p=reject: reject it.

It can also request reports to an address of yours, in which providers tell you which emails with your domain they have received and whether they passed the checks. It is the way to discover services sending on your behalf that you had forgotten about, or someone spoofing your domain.

The prudent approach is to start with p=none, review the reports for a few weeks until everything legitimate passes, and tighten it afterwards.

Why it matters more now

The big email providers have been tightening their requirements. Since 2024, Gmail and Yahoo require bulk senders to have SPF, DKIM and DMARC, and everyone else to have at least correct authentication. Even if your store does not send thousands of emails a day, if your newsletter tool does so with your domain, the whole domain is affected. And without authentication, it is increasingly likely that an order email will not reach the inbox.

Other reasons they do not arrive

• Server or IP reputation: if it shares an IP with others who send spam, everyone pays.
• Content: emails consisting of a single image, shortened links, lots of text in capitals or aggressive subject lines. Order emails should be plain and have a plain-text version.
• Mixing order emails and promotions in the same sending and with the same sender. If newsletters generate complaints, they drag the transactional emails down with them.
• The customer's mailbox is full or the address is misspelt. Validating the email at registration and reviewing bounces helps here.
• SMTP limits: many ordinary mailboxes limit how many emails can be sent per hour or per day. During big campaigns, the store may hit that ceiling.

How to check it

1. Send a test email from the store to a Gmail mailbox and open the original message: you will see whether SPF, DKIM and DMARC show as PASS and with which domain.
2. Look up your domain's TXT records with any DNS tool and check that there is a single SPF and a DMARC.
3. List everything that sends email with your domain and check that each one signs with DKIM and is included in the SPF.
4. Review the DMARC reports for a few weeks before moving to quarantine or reject.

How to solve it in PrestaShop

Delivery depends on the DNS and the mail server; content, on the templates. RKR Mail Editor includes a visual editor for PrestaShop's emails with which you edit the subject, HTML and plain-text version of each template in each language, and it adds to order emails recommended products, a unique coupon for the next purchase and campaign banners, with an unsubscribe link in every email that carries commercial blocks. If what you need is to configure the store's SMTP, review your SPF, enable DKIM with your provider or get DMARC up and running without losing emails, with a Rekire support hours package we review it and leave it working.