Délivrabilité : ce que Gmail, Yahoo et Outlook exigent désormais des expéditeurs

Sommaire

Une newsletter part le mardi, comme chaque semaine. Les ouvertures s’effondrent, les demandes de démonstration aussi, et l’outil d’envoi ne signale rien : les messages ont bien été « délivrés ». Ils sont simplement arrivés dans le dossier des indésirables, ou ont été refusés par une partie des messageries.

Entre février 2024 et mai 2025, Gmail, Yahoo puis Outlook.com ont écrit noir sur blanc ce qu’ils attendent des expéditeurs. Ce n’est plus une affaire de bonnes pratiques : un domaine qui ne remplit pas les conditions voit ses messages filtrés ou rejetés. Voici ce qui est exigé, qui est concerné, et ce que cela change pour l’organisation.

Trois mécanismes, une seule question : qui envoie au nom de ce domaine

Les exigences reposent sur trois standards qui se complètent.

SPF, défini par la RFC 7208, permet au propriétaire d’un domaine de déclarer, dans son DNS, les serveurs autorisés à envoyer en son nom. DKIM, défini par la RFC 6376, signe chaque message ; le destinataire récupère la clé publique dans le DNS du domaine signataire pour vérifier la signature, et donc que ce domaine engage sa responsabilité sur le message.

DMARC, décrit dans la RFC 7489, relie les deux au domaine que le destinataire voit, celui de l’adresse « De ». Il ajoute la notion d’alignement : SPF ou DKIM ne comptent que s’ils authentifient le domaine affiché. En mode relâché, il suffit que les deux partagent le même domaine organisationnel ; en mode strict, il faut une correspondance exacte. L’enregistrement DMARC indique enfin quoi faire d’un message qui échoue : rien (p=none), le traiter comme suspect (quarantine) ou le rejeter (reject), et à quelle adresse envoyer les rapports agrégés (rua).

Ce que Gmail exige

Google distingue deux niveaux dans ses consignes pour les expéditeurs, en vigueur depuis le 1^er février 2024. Pour tous les expéditeurs : SPF ou DKIM, un enregistrement DNS inverse (PTR) valide, une transmission chiffrée, et un taux de spam mesuré dans Postmaster Tools inférieur à 0,3 %, avec un objectif d’environ 0,10 %.

Pour les expéditeurs en masse : SPF et DKIM, un enregistrement DMARC (dont la règle peut être none), l’alignement du domaine « De » avec le domaine SPF ou DKIM, et la désinscription en un clic pour les messages marketing et ceux envoyés à des abonnés.

La FAQ de Google précise ce qui fait un expéditeur en masse : environ 5 000 messages ou plus sur 24 heures vers des comptes Gmail personnels. Les messages envoyés depuis un même domaine principal sont comptés ensemble, sous-domaines compris. Le statut est définitif, même si les volumes baissent ensuite. Et depuis novembre 2025, Google renforce l’application : le trafic non conforme peut subir des rejets temporaires ou permanents.

Ce que Yahoo et Outlook ajoutent

Les règles de Yahoo recoupent largement celles de Google. Tous les expéditeurs doivent authentifier leurs messages au moins par SPF ou DKIM, garder un taux de plaintes sous 0,3 % et disposer d’un DNS direct et inverse valide. Les expéditeurs en masse doivent avoir SPF et DKIM, un DMARC d’au moins p=none qui passe, un domaine « From » aligné (l’alignement relâché est accepté), une désinscription en un clic fonctionnelle, et honorer les désinscriptions sous deux jours. Yahoo ne publie pas de seuil chiffré pour définir l’expéditeur en masse.

Côté Microsoft, la page Postmaster d’Outlook.com indique que, depuis le 5 mai 2025, les domaines qui envoient plus de 5 000 e-mails par jour vers des comptes Outlook.com doivent passer SPF et DKIM, et publier un DMARC au moins en p=none, aligné avec SPF ou DKIM ; Microsoft recommande p=reject. Les messages non conformes vont dans le courrier indésirable, puis peuvent être rejetés avec l’erreur 550; 5.7.515.

La lecture d’ensemble est simple : un expéditeur qui satisfait les exigences « en masse » de Gmail satisfait l’essentiel de celles des deux autres. Le plus sûr est de viser ce niveau sans se demander si l’on dépasse le seuil, puisque le comptage est fait par la messagerie et non par l’expéditeur.

La désinscription en un clic, concrètement

La désinscription « en un clic » n’est pas le lien en bas du message. C’est un mécanisme d’en-tête, défini par la RFC 8058, que la messagerie exploite pour proposer elle-même la désinscription.

Le message porte deux en-têtes : List-Unsubscribe, contenant une URI HTTPS, et List-Unsubscribe-Post: List-Unsubscribe=One-Click. Les deux doivent être couverts par la signature DKIM. Quand l’internaute clique, la messagerie envoie une requête POST à l’URI ; le serveur de l’expéditeur traite la désinscription et ne doit pas répondre par une redirection.

Google exige ce mécanisme pour les messages marketing et promotionnels, pas pour les messages transactionnels, et recommande de traiter les demandes sous 48 heures ; Yahoo impose deux jours. Que l’envoi passe par un outil d’emailing, un CRM ou un développement maison, la présence et la signature de ces en-têtes se vérifient sur un message réel.

Une désinscription doit aussi sortir le contact des scénarios automatisés en cours, pas seulement des campagnes ponctuelles : c’est une des conditions de sortie à prévoir dès la conception. La question du consentement relève, elle, du droit des données personnelles, traitée dans l’article sur le RGPD et la conformité des données.

Contrôler sa conformité

Trois vérifications suffisent à savoir où l’on en est.

Lire un message reçu. Envoyer une campagne réelle à une boîte Gmail de test, ouvrir le message, puis, dans le menu « Plus », choisir « Afficher l’original ». L’en-tête complet s’affiche ; on peut le coller dans l’outil d’analyse d’en-tête de la Google Admin Toolbox. On y vérifie l’authentification du message et la présence des en-têtes List-Unsubscribe.

Ouvrir Postmaster Tools. Une fois le domaine validé, le tableau de bord « État de conformité » affiche, exigence par exigence, un statut « Conforme », « Améliorations nécessaires » ou « Aucune donnée trouvée ». Les exigences propres aux expéditeurs en masse (DMARC, désinscription en un clic, prise en compte des désinscriptions) y figurent à part. Le statut repose sur une moyenne glissante : après une correction, il faut compter jusqu’à sept jours. Le tableau « Taux de spam » mesure la part des messages authentifiés par DKIM que des destinataires ont marqués manuellement comme spam.

Lire les rapports DMARC. Les rapports agrégés reçus à l’adresse rua listent les sources d’envoi et leur résultat. Une source inconnue qui échoue est soit un usurpateur, soit, bien plus souvent, un outil interne que personne n’a déclaré.

Ce que cela change pour l’organisation

Le sujet n’est pas technique au sens où un seul réglage le règle. Il est organisationnel : il faut savoir qui envoie au nom du domaine.

Prenons un exemple hypothétique. Une PME envoie ses newsletters depuis un outil d’emailing correctement configuré. Mais son CRM envoie les relances commerciales, son outil de webinaire les invitations, son logiciel de facturation les factures, et tous utilisent une adresse du domaine de l’entreprise. Deux de ces outils n’ont jamais été déclarés dans SPF ni signés en DKIM. Le jour où DMARC passe en quarantine, les factures partent en indésirables.

D’où quelques décisions à prendre explicitement :

• Tenir l’inventaire des plateformes tierces qui envoient au nom du domaine, et configurer pour chacune DKIM avec le domaine de l’entreprise plutôt que celui de l’éditeur, pour que l’alignement passe.
• Séparer les flux par sous-domaine quand cela a un sens (marketing d’un côté, transactionnel de l’autre) pour isoler les réputations. Le comptage de Google se faisant par domaine principal, cette séparation ne permet pas de rester sous le seuil. La balise sp de DMARC applique une règle distincte aux sous-domaines.
• Faire progresser DMARC de none vers quarantine puis reject, à mesure que les rapports montrent que toutes les sources légitimes sont alignées.
• Désigner un responsable de ces enregistrements DNS, parce que chaque nouvel outil marketing ou d’automatisation ajouté hors du service informatique peut casser l’alignement.

Le choix entre adresse IP mutualisée et IP dédiée est une question voisine mais distincte : la réputation de l’IP compte, elle ne remplace pas l’authentification du domaine. Il est traité dans l’article IP mutualisée ou IP dédiée.

Ce qui reste du ressort de l’expéditeur

L’authentification ouvre la porte ; elle n’assure pas la boîte de réception. Les seuils de taux de spam rappellent que les destinataires décident en dernier ressort : une liste ancienne, des contacts qui n’ont jamais demandé à recevoir les messages ou une fréquence trop élevée produisent des signalements, quelle que soit la qualité des enregistrements DNS.

La conformité technique est donc un prérequis, pas une stratégie. Ce qui fait la différence ensuite relève de la construction des campagnes (ciblage, pertinence, rythme), abordée dans l’article sur la réalisation d’une campagne d’emailing. Un programme d’email marketing solide combine les deux : un domaine dont chaque source est authentifiée, et des envois que les destinataires ne signalent pas.