L'hébergeur a limité l'envoi d'emails : après, pas seulement pendant
L’hébergeur a limité l’envoi : gardez un plafond raisonnable après l’incident, pas seulement pendant. Un site « propre » avec mail() ouvert se fait reprendre. Passez par un SMTP authentifié avec quota, et laissez le limiteur comme filet.
Gardez un plafond raisonnable après l'incident. Un site propre avec mail() ouvert se fait reprendre. Passez par un SMTP authentifié avec quota.
Pourquoi la limite arrive (et revient)
Un pic (script, formulaire ouvert, compte SMTP volé) : l’hébergeur coupe ou bride pour protéger son IP. Vous recevez un mail « outbound limit » ou les devis cessent de partir. C’est une protection, pas une punition personnelle. Elle sauve parfois le voisinage (réputation IP).
Le ticket « remettez-nous 10 000 mails/heure, c’est nettoyé » le soir-même est le meilleur moyen de recuire l’IP. Ils refusent, ou ils acceptent et vous êtes listés chez Orange le lendemain. Un commercial qui promet un « Black Friday dans trois jours » n’est pas un argument technique : ce volume se prépare sur un ESP, avec une base propre, pas en débridant le mutualisé encore chaud.
La limite dit : quelqu’un a envoyé trop. Demandez le journal avant de négocier le chiffre.
Pendant : ce n’est pas le moment de « monter le quota »
Coupez la source, changez les mots de passe, passez les forms en SMTP propre ou en pause. Le quota bas est votre allié : un script oublié se voit tout de suite (ça ne part plus). Un quota remis à l’infini cache la récidive.
Les devis : un ESP transactionnel, pas le mail() relâché. Séparer les flux.
Si l’hébergeur a aussi suspendu le web : lisez le motif (compte suspendu). Mail et malware sont deux tickets parfois collés.
Après : le piège du mail() à nouveau libre
« Le site est propre, on a demandé de retirer la limite. » Trois semaines plus tard, un plugin, un voisin de compte, un employé : le même mail(). L’IP rebrûle. Nous voyons ce motif autant que les réinfections PHP.
Gardez un plafond un peu au-dessus du métier (ex. 100–300/j pour une vitrine, plus pour une boutique, jamais « illimité » sur du mutualisé). Alerte à 80 %. Notez le chiffre dans le même fichier que les mots de passe SMTP : le prochain prestataire qui « optimise » demandera l’illimité par habitude. Vous aurez de quoi dire non avec une date et un ticket d’abus.
Désactivez mail() si l’hébergeur le permet, forcez SMTP. WordPress : un plugin SMTP, plus de fallback silencieux. Testez un form : s’il « réussit » sans SMTP configuré, le fallback est encore là.
SMTP authentifié, quota, alertes
Brevo, Mailjet, Amazon SES, le SMTP du panel avec user/mot de passe : chaque envoi est imputable. Quota côté ESP + quota hébergeur. Deux filets.
Mots de passe SMTP dans le gestionnaire, pas dans le thème. Rotation après incident. Les clés : autre tiroir, même jour.
Alerte ESP (pic anormal) : un humain la lit. Une alerte dans un dossier spam, non.
Ce que le limiteur ne voit pas
Un envoi via un ESP externe (API) ne passe pas par le quota mail() de l’hébergeur. Bien pour le métier, aveugle pour eux. Surveillez l’ESP. Un compte Brevo volé n’a rien à voir avec o2switch.
Un second site sur le compte : son mail() mange le quota commun. Inventaire addon.
Les cron qui envoient des logs : inoffensifs à 10/j, bruyants à 10/min après un debug oublié. Relisez les crons.
o2switch, OVH, LWS, les tickets types
Factuel : référence d’abus, journal demandé, source coupée, SMTP désormais authentifié, plafond souhaité (raisonnable). Joignez deux chiffres : volume métier d’un mois calme, et le pic de l’incident. L’écart parle tout seul. Un hébergeur qui voit 80 mails/j habituels et une demande à 20 000 comprend que vous n’avez pas fini le diagnostic.
OVH mutualisé / Exchange / MX : plusieurs produits mail. Le limiteur n’est pas toujours celui que vous croyez. Lisez le produit dans le ticket.
Ils peuvent exiger un constat. C’est le même écrit que pour une suspension web. Utile, pas une insulte.
Applications et crons qui envoient
Sauvegardes qui s’emailent, monitoring, forums, tickets. Listez. Un cron « backup OK » toutes les 5 minutes après un plugin mal réglé brûle le quota et ressemble à du spam.
Presta / Woo : mails de commande en rafale après un rattrapage de file. Attendez, ou passez par l’ESP, plutôt que de demander 50 000/h.
Guide emails une fois le plafond tenu.
Vivre avec un plafond
C’est un état normal de mutualisé sain. Les gros volumes : ESP. Trente jours sans ticket mail = succès. Un nouveau limiteur : journal d’abord, pas le coup de fil « enlevez ».
Créer un espace si le script d’envoi n’est pas trouvé. On ne demande pas la levée du quota à l’inscription.
Documentez le chiffre (ex. 200/j) dans le runbook interne pour le prochain prestataire pressé.