# My emails do not arrive, or land in spam

> An email sent by a website goes through five stages: the site composes it, a server dispatches it, the domain proves it really is the author, the recipient’s provider scores it, and the inbox picks a folder. The site is responsible only for the first. Yet it is the first to be blamed.

- Source canonique : [https://allaux.fr/en/problemes/emails-non-recus-ou-en-spam](https://allaux.fr/en/problemes/emails-non-recus-ou-en-spam)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Test sending before anything else: Advanced Parameters > E-mail on PrestaShop sends a test message and shows the raw SMTP error. On WordPress, a mail log tells you whether the message actually left. If messages leave but land in spam, the fault is in the domain DNS: check the SPF record, the DKIM key and the DMARC policy at your registrar.

## Three symptoms, three different stages

- Nothing is sent at all, not even to your own address: the failure is in composition or dispatch, on the site and server side.
- Messages reach some recipients and not others, often depending on the mail provider: the failure is in domain authentication.
- Messages arrive but land in junk: nothing is broken, it is sending reputation that is at fault.

## The most frequent breaking point: authentication

A mail provider receives a message claiming to come from your domain. To verify that, it consults three records published in the domain’s DNS zone. SPF lists the servers allowed to send on your behalf. DKIM lets it verify a cryptographic signature attached to the message. DMARC says what to do when the first two fail.

When the site sends directly from the hosting server while SPF only authorises the company mail server, verification fails. The message is not rejected — that would be easier to diagnose — it is simply downgraded, and ends up in junk with the stricter providers. That is exactly the pattern behind "it only works for some customers".

## Isolating the failing stage

1. **Send a test to two different providers** — One consumer mailbox and one business address. The difference in treatment is already a diagnosis.
2. **Read the full header of the received message** — It contains the SPF and DKIM verification results in plain text. That is proof, not a guess.
3. **Check the configured sender address** — A site sending on behalf of a domain it does not control — the owner’s personal address, for instance — is downgraded almost every time.
4. **Look at the server’s sending logs** — They say whether the message left, and with what answer from the receiving server. A rejection is explicit and often explanatory.
5. **Check the site is not sending anything else** — A compromised site sending junk destroys the domain’s reputation, and your order confirmations pay the price.

## A dedicated sending service fixes most cases

> Routing transactional messages through a specialised sending service rather than the hosting server’s mail function brings correct authentication, readable logs and managed reputation. That is a configuration change, not development.

## Carry on with the right page

- **Order emails not received on PrestaShop** — If the failure is inside PrestaShop: templates, hooks and sending settings. ([/prestashop/problemes/emails-confirmation-commande-non-recus](/prestashop/problemes/emails-confirmation-commande-non-recus))
- **Order emails not received on WooCommerce** — The WordPress equivalent, with its own causes. ([/wordpress-woocommerce/problemes/emails-commande-non-recus](/wordpress-woocommerce/problemes/emails-commande-non-recus))
- **My site is sending emails I did not write** — If the domain lost its reputation because of parasite sending. ([/securite/mon-site-envoie-des-emails-que-je-n-ai-pas-ecrits](/securite/mon-site-envoie-des-emails-que-je-n-ai-pas-ecrits))
- **DNS explained** — Where SPF, DKIM and DMARC are published, and why they belong to the domain. ([/glossaire/dns](/glossaire/dns))

## FAQ

### Why do customers at some providers get everything and others nothing?

Because providers do not apply the same severity to the same signals. A poorly authenticated message passes with one and is set aside by another. That is the most reliable sign of an SPF or DKIM problem.

### Can the problem come from my host?

Yes, in two ways: its sending function may be limited or disabled, and its sending address may be shared with sites that have damaged its reputation.

### Does fixing this need development?

Rarely. The fix is almost always configuration: DNS records, sending settings, sender address. Development only comes in when the site does not trigger the messages at all.

### How can I tell my messages go to junk without asking customers?

By sending tests to mailboxes you control at several providers, and by reading DMARC reports if the record is published with a reporting address.

### My messages used to arrive fine. What changed?

Usually the DNS zone was edited during a hosting or mail migration, or providers tightened their requirements. Sending that passed two years ago can be set aside today with nothing changed on your side.