IP serveur blacklistée : même si votre site est propre
Les filtres notent l'IP d'émission, pas seulement votre nom. Un voisin qui envoie du phishing suffit. Le nettoyage local ne blanchit pas l'adresse. Il faut une IP saine — parfois une migration, mais seulement après un site relu.
Les filtres notent l'IP. Un voisin qui envoie du phishing suffit. Le nettoyage local ne suffit pas : il faut une IP saine, parfois une migration après nettoyage.
IP web, IP MX, IP relais : laquelle est listée
Le site envoie via `mail()` : l'IP du serveur web apparaît. Le CMS parle SMTP à OVH mail : c'est l'IP du MX / du smarthost. Brevo : les IP de Brevo (rarement « votre » problème SBL, plutôt le domaine). Une SBL sur l'IP web alors que vous n'envoyez plus que via Brevo : vos devis peuvent passer, vos « forgotten » PHP non. Triez avant de « changer d'hébergeur ». Emails après piratage, php mail. Un header `Received` contient souvent les deux IP (web puis relais) : c'est la première qui authentifie `mail()`, la seconde le SMTP. Ne delistez pas la mauvaise.
Voisin de mutualisé vs votre propre script
Journaux : le user / le script est le vôtre, ou un autre compte sur la même IP. Si c'est vous : nettoyez, delist éventuel, SPF. Si c'est le voisin (autre abonné) : ticket hébergeur, isolation, parfois IP dédiée. Si c'est VOTRE autre site sur le même compte : inventaire — voisin WordPress, guide réputation IP.
Lookup et bounces : lire le bon identifiant
Headers d'un bounce (Received, X-Spam) nomment souvent l'IP. Spamhaus / Barracuda / SORBS lookup. Une IP « listed » sur une PBL (policy, plage dynamiques) n'est pas un malware : c'est une politique (ne pas envoyer en direct depuis cette plage). La solution est un smarthost authentifié, pas un delist rageur.
- IP extraite d'un bounce récent.
- Lookup officiel de cette IP.
- User / script dans le journal hébergeur.
Ce que l'hébergeur peut faire
Fournir les journaux, couper `mail()` le temps du ménage, parfois déplacer vers une IP propre, relancer leur propre delist s'ils sont le LIR. Ils ne le feront pas sur un « c'est nettoyé » sans preuve. Ticket factuel : référence d'abus, IP, dates, constat. Compte suspendu si l'envoi a fait tomber le compte.
Migrer : après, pas à la place
Copier un site sale sur une IP neuve noircit la suivante en 24 h et brûle un compte. Nettoyez, vérifiez les journaux plats, puis migrez si l'hébergeur ne peut pas isoler ou si l'IP reste collective et pourrie. Migration infectée.
RBL, FAI, et le délai qui reste
Un delist RBL n'est pas Orange. Attendez, envoyez du transactionnel propre, surveillez. Multi-RBL : chaque formulaire. Ne payez pas un « blanchiment IP » douteux.
SPF trop large qui autorise encore l'ancienne IP
Après migration, un SPF `ip4:ancienne` ou un `include` trop large laisse un attaquant (ou un vieux cron) authentifier depuis l'ex-IP. Serrez. SPF include trop large, SPF après hack.
Surveiller l'ancienne adresse
Les bots continuent de frapper l'ancienne IP. Éteignez l'ancien vhost. Un cron là-bas relance le spam. Créer un compte si l'hébergeur refuse les logs et que l'IP est collective.
- IP listée = celle des bounces.
- Script à vous vs voisin, tranché par les logs.
- Migration seulement site propre.
- SPF sans ancienne IP orpheline.
IP dédiée, rDNS, et ce qui ne se vend pas
Une IP dédiée n'est utile que si vous envoyez encore depuis le serveur web. Si tout passe par Brevo, l'IP web listée gêne surtout `mail()` résiduel et parfois des filtres qui notent l'IP du site dans les liens. Le rDNS (PTR) qui ne matche pas le HELO est un signal secondaire : à recoller chez l'hébergeur après le ménage, pas à 23 h à la place du script. Un PTR « trop beau » sur une IP encore sale n'aide pas.
Méfiez-vous des vendeurs de « blanchiment d'IP en 2 h ». Les RBL sérieux ont un formulaire. Payer un intermédiaire pour Spamhaus, c'est souvent de l'argent perdu et parfois un compte déjà flaggé. Faites le lookup, le constat, le formulaire. Spamhaus domaine si c'est le nom, pas l'IP.
Après une IP neuve : surveillez SNDS / les bounces une semaine. Les bots tapent encore l'ancienne ; l'ancienne doit être éteinte. Un A record oublié (www en v4 neuve, apex en ancienne) mélange les signaux. Alignez DNS et SPF le jour de la bascule, pas « quand on aura le temps ».