Bulk email quelles règles Google Yahoo Microsoft en 2025 ?

Résumer ce contenu avec :

Perplexity ChatGPT Claude Grok Mistral

Il faut authentifier vos emails, garder un taux de spam très bas et rendre le désabonnement évident. Google, Yahoo et Microsoft ne laissent plus passer les envois bulk email approximatifs. Je vous montre ce qui change, qui est concerné, et quoi corriger en priorité.

Qui est concerné par le bulk email ?

Vous êtes concerné dès que vos volumes d’envoi ressemblent à de l’emailing industriel, même si vous ne vous voyez pas comme un spammeur.

Google considère qu’un expéditeur bulk, c’est un domaine qui envoie plus de 5 000 messages par jour vers des adresses Gmail. Ce n’est pas 5 000 emails au total dans votre outil. C’est 5 000 messages reçus par Gmail, sur une journée, depuis votre domaine d’envoi.

Ça touche vite beaucoup de monde. Les équipes marketing, CRM, e-commerce, SaaS, médias, associations, réseaux de franchises, acteurs B2B… Dès que vous envoyez des newsletters, des relances panier, des notifications produit, des campagnes commerciales ou des séquences automatisées, vous pouvez entrer dans cette zone.

Yahoo applique des règles proches sur son environnement. Microsoft aussi, avec Outlook.com, hotmail.com et live.com. Donc si votre base contient beaucoup d’adresses grand public, le sujet ne se limite pas à Gmail. En pratique, Gmail donne souvent le ton, mais les autres suivent la même logique : mieux identifier les bons expéditeurs et limiter les messages mal authentifiés, peu désirés ou trop agressifs.

Le point important, c’est que le volume ne suffit pas à expliquer vos problèmes de délivrabilité. La délivrabilité, c’est la capacité de vos emails à arriver en boîte de réception, pas en spam. Les messageries regardent aussi la réputation de votre domaine, la cohérence technique de vos réglages, et surtout la réaction des destinataires. Est-ce qu’ils ouvrent ? Est-ce qu’ils cliquent ? Est-ce qu’ils ignorent ? Est-ce qu’ils signalent en spam ?

J’ai vu un client accuser son outil emailing pendant des semaines. En réalité, l’outil faisait le job. Le domaine d’envoi était mal authentifié, avec un SPF et un DKIM bancals. SPF et DKIM, ce sont deux mécanismes qui prouvent que vos serveurs ont le droit d’envoyer pour votre domaine. En plus, la base contenait trop de contacts inactifs. Résultat : Gmail et Microsoft recevaient un mauvais signal, même avec des emails propres.

Quelles dates faut-il retenir ?

La bascule a commencé en 2024 avec Google et Yahoo, puis Microsoft a annoncé son durcissement pour 2025.

Le point de départ, c’est octobre 2023. Google et Yahoo annoncent qu’ils vont imposer de nouvelles règles aux expéditeurs de masse. Dans les faits, ça concerne surtout les domaines qui envoient beaucoup d’emails vers Gmail, Yahoo, AOL, Outlook et les autres grosses boîtes grand public.

À partir du 1er février 2024, Google et Yahoo commencent à appliquer leurs exigences. Pas avec un grand mur qui tombe d’un coup. Plutôt avec une montée en pression. D’abord, des erreurs temporaires sur une partie du trafic non conforme. Une erreur temporaire, c’est un refus provisoire. Le serveur dit en gros : “Là, je ne prends pas votre email, réessayez plus tard”. C’est désagréable, mais ça laisse encore une chance de corriger.

À partir d’avril 2024, Google passe un cran au-dessus. Il commence à rejeter progressivement un pourcentage du trafic non conforme. Là, on n’est plus dans le simple avertissement. Une partie des messages ne passe plus. J’ai vu des équipes découvrir à ce moment-là que leur SPF, DKIM ou DMARC était mal configuré depuis des années. Tant que ça livrait à peu près, personne ne regardait.

Microsoft rejoint ensuite le mouvement. En avril 2025, Microsoft annonce des restrictions similaires pour Outlook.com, hotmail.com et live.com. À partir du 5 mai 2025, les messages non conformes peuvent être rejetés.

Ce n’est pas une mise à jour cosmétique. C’est une normalisation du marché. Les boîtes mail veulent savoir qui envoie quoi, limiter l’usurpation d’identité et réduire le bruit. Et franchement, vu le volume de spam, de phishing et de newsletters envoyées n’importe comment, c’était inévitable.

Quelle authentification faut-il mettre en place ?

Il faut mettre en place SPF, DKIM et DMARC, et vérifier qu’ils travaillent vraiment ensemble.

SPF, c’est le mécanisme qui indique quels serveurs ont le droit d’envoyer des emails pour votre domaine. Par exemple, votre outil d’emailing, votre CRM, votre solution de support client. Si un serveur non autorisé envoie avec votre domaine, SPF peut échouer.

DKIM, c’est une signature cryptographique ajoutée à chaque email. Elle permet de prouver que le message n’a pas été modifié entre l’envoi et la réception. En pratique, votre plateforme signe l’email avec une clé privée, et le serveur qui reçoit vérifie cette signature avec une clé publique publiée dans votre DNS.

DMARC, c’est la règle qui dit quoi faire quand SPF ou DKIM échoue. Au minimum, il faut une politique DMARC présente, même en p=none au départ. Le mode p=none ne bloque rien, mais il permet d’observer ce qui se passe. C’est souvent la bonne première étape avant de passer à quarantine ou reject.

Le point que je vois le plus souvent chez les clients, c’est l’alignement. SPF ou DKIM peuvent être techniquement valides, mais pas alignés avec le domaine visible dans le champ From. Et pour Google, Yahoo ou Microsoft, c’est ce domaine visible qui compte. Si vous envoyez depuis plusieurs plateformes emailing ou CRM, il faut vérifier que chaque outil signe correctement avec votre domaine, pas seulement avec un domaine technique fourni par l’outil.

Les bases DNS doivent aussi être propres. Des enregistrements SPF, DKIM et DMARC corrects, cohérents, sans doublons inutiles, sans anciennes plateformes oubliées. Un SPF avec trop de services empilés finit vite par casser.

Exemple simplifié de logique attendue :

SPF : Le domaine autorise les serveurs de vos outils d’envoi à envoyer des emails.

DKIM : Chaque plateforme d’envoi signe les messages avec une clé liée à votre domaine.

DMARC : Le domaine publie une règle qui indique quoi faire si l’authentification échoue.

SPF, DKIM et DMARC ne garantissent pas à eux seuls l’arrivée en boîte de réception. Votre réputation, vos plaintes spam, vos désabonnements et la qualité de vos listes comptent aussi. Mais en 2025, sans cette base, vous n’êtes même pas vraiment dans la course. C’est le ticket d’entrée.

Comment éviter les rejets et le spam ?

Il faut surveiller la plainte spam, nettoyer les listes et rendre le désabonnement simple, pas planqué.

Google demande aux expéditeurs en volume de garder un taux de signalement comme spam sous 0,10 %. Le seuil à ne surtout pas toucher, c’est 0,30 % ou plus. À ce niveau-là, vous envoyez un signal très clair aux boîtes mail : Les gens ne veulent pas de vos emails.

Ce taux ne dépend pas seulement de SPF, DKIM, DMARC ou de votre outil d’envoi. La technique ouvre la porte, mais la perception décide si vous restez dans la boîte de réception. Si la personne ne se souvient pas de vous, si vous envoyez trop souvent, si le contenu est faible ou trop commercial, elle clique sur spam. Et là, même une configuration parfaite ne vous sauve pas longtemps.

J’ai vu des clients améliorer leur délivrabilité sans changer d’outil, juste en arrêtant d’envoyer la même newsletter à toute la base. Les contacts froids recevaient moins. Les clients actifs recevaient plus ciblé. Les horaires ont été adaptés aux vrais moments de lecture. C’est moins spectaculaire qu’un nouveau logiciel, mais ça marche.

Les actions utiles sont assez simples :

• Segmenter les audiences selon l’engagement, l’achat, l’intérêt ou la récence.
• Réduire le volume sur les contacts froids, surtout ceux qui n’ouvrent plus depuis plusieurs mois.
• Tester les horaires d’envoi, parce qu’un bon email au mauvais moment finit ignoré.
• Proposer un centre de préférences, avec le choix des sujets et de la fréquence.
• Arrêter le tout ou rien, parce que forcer quelqu’un à tout recevoir pousse souvent vers le bouton spam.

Le désabonnement est un gros levier rapide. Pour les emails commerciaux ou abonnés, il faut un désabonnement clair, visible, et idéalement en un clic. Côté technique, ça passe par les en-têtes List-Unsubscribe et List-Unsubscribe-Post, dans l’esprit de la RFC 8058, qui standardise le désabonnement en un clic.

List-Unsubscribe: <https://exemple.com/unsubscribe?id=123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Les demandes doivent être traitées vite. Pas dans 15 jours. Pas après trois écrans de confirmation. C’est souvent là que les entreprises gagnent le plus vite en délivrabilité, parce qu’elles réduisent les frustrations avant qu’elles se transforment en plaintes spam.

• À faire maintenant : Suivre le taux de plainte spam par domaine.
• À faire maintenant : Mettre en pause les contacts inactifs.
• À faire maintenant : Ajouter le désabonnement en un clic.
• À faire maintenant : Créer un centre de préférences simple.
• À faire maintenant : Ajuster fréquence, ciblage et horaires d’envoi.

Et maintenant on sécurise vos envois ?

Le message est assez clair. Le bulk email ne se pilote plus à l’instinct. Google, Yahoo et Microsoft demandent des bases propres avec SPF, DKIM, DMARC, des taux de plainte très bas et un désabonnement simple. Si vous envoyez beaucoup, surtout au-delà de 5 000 emails par jour vers Gmail, vous devez traiter ça comme un vrai sujet data, CRM et délivrabilité. Pas juste comme un réglage dans votre outil emailing. Mon conseil simple, c’est de vérifier la technique, puis de regarder la qualité réelle de vos listes. Le bénéfice pour vous, c’est moins de rejets, plus de messages délivrés et une réputation domaine qui tient dans le temps.

FAQ

• Qu’est-ce qu’un expéditeur bulk email pour Google ?
  Google considère comme expéditeur bulk un domaine qui envoie plus de 5 000 messages par jour vers des adresses Gmail. Ce seuil peut être atteint assez vite avec des newsletters, relances CRM, notifications ou campagnes commerciales.
• Quels réglages techniques sont obligatoires ?
  Les envois en masse doivent être authentifiés avec SPF, DKIM et DMARC. SPF autorise les serveurs d’envoi, DKIM signe le message, DMARC définit la politique si l’authentification échoue. Il faut aussi vérifier l’alignement avec le domaine visible dans l’expéditeur.
• Quel taux de spam faut-il respecter ?
  Google recommande de rester sous 0,10 % de signalements comme spam et d’éviter d’atteindre 0,30 % ou plus. En pratique, ça oblige à envoyer à des contacts engagés, à réduire la pression marketing et à proposer des contenus vraiment attendus.
• Pourquoi le désabonnement devient-il si important ?
  Parce qu’un utilisateur qui ne trouve pas comment se désabonner clique souvent sur spam. Les grands fournisseurs attendent un mécanisme clair, notamment le désabonnement en un clic pour les messages commerciaux ou abonnés, avec un traitement rapide des demandes.
• Microsoft applique-t-il les mêmes règles que Google et Yahoo ?
  Microsoft a annoncé des restrictions similaires en 2025 pour Outlook.com, hotmail.com et live.com. Les messages non conformes peuvent être rejetés à partir du 5 mai 2025, ce qui rend SPF, DKIM, DMARC et la gestion de réputation indispensables.

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes marketing, data et business sur des sujets où la donnée, les outils et la performance doivent vraiment fonctionner ensemble. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez fiabiliser vos envois, vos données ou vos automatisations, contactez-moi.

Franck Scandolera

⭐ Expert et formateur en Tracking avancé, Analytics Engineering et Automatisation IA (n8n, Make) ⭐

Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

Data & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.