# My site is sending emails I didn't write

> Customers report receiving a promotional message or a suspicious follow-up from your domain, or your host flags an unusual sending volume: your CMS's email function is being used without your knowledge.

- Source canonique : [https://allaux.fr/en/securite/mon-site-envoie-des-emails-que-je-n-ai-pas-ecrits](https://allaux.fr/en/securite/mon-site-envoie-des-emails-que-je-n-ai-pas-ecrits)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Ask your host for the account mail queue and send log: the X-PHP-Originating-Script header, where present, names the PHP script that produced each message and leads you to the injected file. Then flush the queue before it drains out. Changing the SMTP password fixes nothing if the sending comes from your own server.

## Signs of a hijacked mail function

- A customer forwards you a promotional or phishing email that appears to come from your contact or order address
- Your host warns you about a daily sending quota being exceeded, while your usual volume of order confirmations hasn't changed
- Password reset or order confirmation emails stop arriving, because your domain has been blacklisted by mail providers over the spam sent alongside them
- The CMS's mail log (where one exists) shows hundreds of messages over a short period, to addresses you don't recognise as customers
- "Unknown address" bounce replies flood a mailbox you rarely check

## Why the native mail function becomes a target

PrestaShop, like most e-commerce CMSs, has a built-in email function used constantly for order confirmations, password resets, and tracking notifications. It relies on the server configuration (often the native PHP mail() function or an SMTP server set up in the back office) and on the reputation of the site's domain name.

That reputation is exactly what makes the function worth hijacking. An established e-commerce domain with a history of legitimate sending passes spam filters more easily than a brand-new domain created for the purpose. Depending on the specific flaw involved, a poorly validated form on the public-facing site can be enough to inject extra recipients or content into an email sent by the CMS, without requiring any admin access at all: that's the general mechanism behind a good share of abuse of this kind, independent of the technical detail specific to each case.

In other cases, a compromised admin account is used directly, either through the CMS's own email templates or through a bulk-sending extension (newsletter, marketing) installed for a legitimate purpose, to distribute content with nothing to do with your business.

Either way, the common thread is the same: it isn't your personal mailbox that's compromised, it's the server sending on your behalf. Changing your mail password changes nothing.

## SPF, DKIM and DMARC don't block this kind of abuse

> These protections authenticate emails sent from your domain; they don't stop them being sent if it's your own server generating them. They do help against a third party spoofing your domain from elsewhere, which is a different problem.

## How to confirm where the sending is coming from

1. **Check the server's mail logs** — Most hosts keep an outgoing mail log (often named exim_mainlog or similar) showing sender, recipient and time for every send, independent of anything the CMS logs itself.
2. **Compare against actual order volume** — A clear gap between the number of orders placed and the number of outgoing emails over the same period confirms an extra sending source exists.
3. **Review the site's public forms** — Any form that triggers an email (contact, quote request, customer review) is worth checking first, especially if it was added by a third-party extension.
4. **Check the domain's reputation** — Free IP and domain reputation checkers show whether your domain has already been flagged as a spam source by mail providers.

## Related pages

- **E-commerce security and hacked site cleanup** — The full response method for when the mail function is just one symptom among others. ([/services/securite](/services/securite))
- **Securing your store after a hack** — The checklist in order: access cut, passwords changed, files and database cleaned. ([/securite/se-proteger-apres-un-nettoyage](/securite/se-proteger-apres-un-nettoyage))

## FAQ

### Should I change the password on my personal mailbox?

That's not enough if the emails originate from the site's server rather than your mailbox. Confirm the actual source first before acting on the wrong link in the chain.

### Could my domain get blacklisted because of this?

Yes, that's a common consequence. Spam volume detected from your domain can hurt the deliverability of all your legitimate emails, including order confirmations.

### Does this mean my admin account is compromised?

Not necessarily. Depending on the flaw involved, a poorly protected public form can be enough to generate these sends without any admin access being needed.

### How do I find out how many emails were actually sent?

The mail log kept by your host gives the exact figure, independent of what the CMS shows in its own history, which can be incomplete or have been altered.

### Once the flaw is fixed, does the domain's reputation recover automatically?

Not always immediately. Some mail providers apply an observation period before restoring normal deliverability, even after the flaw is closed.