Gmail rejette les emails du domaine après un incident

Ce qu'un test vers soi-même ne dit pas

Gmail connaît votre adresse, votre historique d'ouvertures, parfois votre téléphone. Un message de test vers cette boîte emprunte un chemin trop favorable. Le client qui n'a jamais écrit avec vous, lui, arrive dans une file froide, après une nuit de spam parti de votre domaine.

Demandez à trois destinataires Gmail distincts, hors de votre entreprise, de transférer « Afficher l'original ». Comparez. Un seul « ça passe chez moi » n'est pas un feu vert de reprise d'activité.

Le même domaine peut passer en interne (relais d'entreprise) et échouer vers @gmail.com. Ce n'est pas un bug de votre Outlook : ce sont deux politiques. Le cadre général reste domaine blacklisté email.

Lire le rejet, pas le ressenti

Un 550, 421 ou 454 dans la file d'envoi (hébergeur, ESP, journal SMTP du CMS) contient une phrase. « Spamhaus », « policy violation », « unauthenticated », « rate exceeded » : ce ne sont pas synonymes. Copiez le bloc entier, horodaté. C'est la pièce que Google et l'hébergeur comprennent.

Un message accepté puis classé en spam n'est pas un rejet. C'est une réputation. Un rejet à la porte, c'est une politique. Les soigner dans le désordre (réchauffer pendant que le script tourne encore) aggrave les deux.

Si le rejet mentionne une URL de votre site, Gmail a peut-être vu un kit d'hameçonnage ou un domaine déjà listé. Coupez l'URL avant tout recours Postmaster.

• Code et texte complet du DSN.
• Heure et destinataire (anonymisé si besoin).
• IP et hostname de sortie.

En-têtes : authentification et chemin

Dans « Afficher l'original », SPF, DKIM et DMARC sont notés. Un fail SPF alors que vous envoyez depuis le bon hébergeur signifie souvent une IP de sortie absente de l'enregistrement, ou un envoi pirate depuis ailleurs. Un pass SPF avec un fail DKIM oriente vers une configuration cassée pendant l'incident, pas seulement vers « Google est méchant ».

La chaîne Received doit coller à votre prestataire. Une IP de datacenter inconnu avec votre From, c'est de l'usurpation, pas un caprice Gmail. Serrez le DNS après avoir inventorié les vrais relais.

ARC et « mailed-by / signed-by » visibles dans Gmail aident le client à voir qui a vraiment signé. Si signed-by n'est pas vous, expliquez-le simplement : le message n'est pas parti de votre serveur.

Listes, volume et réputation Postmaster

Google Postmaster Tools, si le domaine y est validé, montre spam rate, IP reputation, erreurs. Sans validation préalable, vous n'aurez pas l'historique du pic. Créez-la après l'incident pour la suite, pas comme baguette du jour J.

Un volume soudain (milliers de destinataires inconnus) suffit à faire tomber un petit domaine, même authentifié. Le script a écrit à des listes mortes : les bounces sont un second signal anti-spam. Videz la file, ne renvoyez pas.

Les listes publiques (Spamhaus DBL, etc.) et le rejet Gmail ne sont pas la même file. On les traite toutes, avec la même preuve : source coupée à telle date.

Couper avant de supplier Google

Tant qu'un PHP, un cron ou une clé SMTP envoie, un formulaire Postmaster ou un ticket « please unlist » est du théâtre. Coupez, changez les secrets du panel et du CMS, cherchez une porte dérobée, puis seulement documentez.

Gmail n'a pas besoin du roman de l'attaque. Il a besoin que le prochain message soit légitime, authentifié, à bas volume. Une newsletter « on reprend contact » le lendemain est le geste qui recimente la réputation basse.

Si l'hébergeur a déjà rate-limité le compte, c'est une protection. Ne demandez pas la levée du quota pour « rattraper les devis » tant que la cause n'est pas écrite dans un constat.

Ce qu'il ne faut pas improviser

Changer le From toutes les heures (`devis2@`, `contact-pro@`, un autre domaine). Gmail relie souvent au racine. Vous multipliez les identités brûlées. Un nouveau sous-domaine « pour passer » empire parfois le parent : même leçon côté Microsoft.

Acheter un « tool de warmup » le jour de l'incident, ou louer une IP « clean » en y collant le même script. Vous déplacez la tache. Migrer l'hébergement mail à chaud sans zone DNS maîtrisée crée des bounces légitimes en plus des bounces pirates.

Mentir dans un recours (« never sent spam ») alors que les journaux montrent 80 000 messages. Les équipes abus croisent. Un constat factuel — date, coupure, correctif — passe mieux.

• Un seul From métier, stable.
• Volume progressif de vrais fils, pas une campagne de rattrapage.
• Recours après coupure, avec horodatage.

Recours et délais réels

Les formulaires Google (Postmaster, parfois un lien dans le DSN) mettent des jours, pas une après-midi. Relancer toutes les heures n'accélère pas. Un second recours identique le lendemain peut figer le dossier.

La délivrabilité transactionnelle (reset, commande) revient souvent avant le marketing. Acceptez cet ordre. C'est aussi l'ordre du réchauffement.

Si Safe Browsing classe encore le site, les liens dans vos mails aggravent. Site propre d'abord, mails ensuite. Les deux horloges ne sont pas liées par un bouton unique.

Quand Outlook et Orange disent autre chose

Gmail accepte et Outlook jette, ou l'inverse. Ce n'est pas incohérent : listes et seuils diffèrent. Traitez le rejet que vous avez en main, pas « les emails en général ». Gardez un tableau : destinataire, FAI, code, date.

Orange, SFR, Free ont leurs propres délais et parfois un trop-plein après un pic. Un message qui passe Gmail et meurt chez un FAI français oriente vers le volume récent ou une liste locale, pas vers un certificat HTTPS.

Vous pouvez déclarer le dossier pour le site ; la délivrabilité reste un suivi à part, avec les DSN. Joignez-les, pas une capture de boîte de réception.