Deliverability
Nouvelles exigences de Microsoft Outlook pour les expéditeurs : ce que vous devez faire d’ici le 5 mai
Si vous pensiez en avoir fini avec la conversation sur les exigences pour les expéditeurs après les changements imposés par Google et Yahoo l’année dernière, détrompez-vous. Microsoft passe à l’action. Dans son article de blog du 2 avril, Microsoft a annoncé de nouvelles exigences pour les expéditeurs de gros volumes ciblant les adresses Outlook.com, Hotmail.com et Live.com.
Si vous envoyez plus de 5 000 messages par jour vers des domaines grand public de Microsoft, lisez ce qui suit. Ces changements visent à protéger les destinataires, à lutter contre l’usurpation et à relever le niveau d’exigence en matière d’authentification des expéditeurs.
Examinons en détail ce qui change et les actions à mener.
Quelles sont les exigences de Microsoft pour les expéditeurs ?
À partir du 5 mai 2025, Microsoft commencera à filtrer, voire à rejeter, les messages qui ne respectent pas ses normes d’authentification. La bonne nouvelle, c’est que si vous respectez déjà les normes de Gmail et Yahoo, vous n’avez rien à faire. Voici ce que vous devez mettre en place :
- SPF (Sender Policy Framework) : Votre domaine doit passer les contrôles SPF. Cela signifie que vos enregistrements DNS doivent définir clairement qui est autorisé à envoyer des emails en votre nom.
- DKIM (DomainKeys Identified Mail) : DKIM est requis pour vérifier l’intégrité du message. Microsoft s’attendra à recevoir des messages signés qui confirment que l’expéditeur est bien celui qu’il prétend être.
- DMARC (Domain-based Message Authentication, Reporting, and Conformance) : Une politique DMARC valide est désormais indispensable. Vous avez besoin, au minimum, d’une politique de p=none, et elle doit être alignée avec SPF ou DKIM, idéalement les deux.
Les messages qui ne respectent pas ces exigences ? Ils seront d’abord dirigés vers le dossier Courrier indésirable, et si le problème n’est pas résolu, ils finiront par être purement et simplement bloqués.
Que doivent faire d’autre les expéditeurs ?
Microsoft demande également aux expéditeurs de suivre quelques bonnes pratiques essentielles pour garantir la « qualité et la confiance ». Ces directives favorisent la délivrabilité et aident à protéger les destinataires.
- Utilisez des adresses « From » ou « Reply-To » réelles et capables de recevoir des réponses.
- Incluez un lien de désabonnement visible et fonctionnel, particulièrement dans les envois d’emails en masse ou les emails de marketing.
- Gardez votre liste de contacts à jour. Supprimez régulièrement les contacts invalides et surveillez vos taux de rebond.
- Soyez transparent dans vos objets d’email et vos en-têtes. Le contenu trompeur ne profite à personne.
Microsoft a été clair : si vous ne suivez pas ces pratiques (Microsoft a spécifiquement mentionné l’authentification et l’hygiène de la liste) et que les problèmes de délivrabilité persistent, vos messages pourraient être filtrés ou bloqués, sans qu’aucune exigence formelle ne soit requise.
Qu’en est-il de la désinscription en un clic (RFC 8058) ?
Contrairement à Gmail et Yahoo, Microsoft n’a pas explicitement exigé le support de RFC 8058 ou la désinscription en un clic. Cela dit, il est obligatoire d’offrir une expérience d’opt-out simple avec des « liens de désabonnement fonctionnels » clairs et visibles.
Calendrier et application
Voici comment les choses vont se dérouler :
- Dès maintenant : auditez vos enregistrements SPF, DKIM et DMARC. Assurez-vous qu’ils sont alignés et qu’ils fonctionnent correctement.
- 5 mai 2025 Les messages qui ne respectent pas les exigences d’authentification détaillées ci-dessus (SPF, DKIM, DMARC) seront rejetés. Les messages rejetés seront signalés par le code d’erreur « 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level. » (Mise à jour du 1er mai 2025)
- Plus tard (date à déterminer) : attendez-vous à des rejets complets pour les expéditeurs qui ne sont toujours pas en conformité.
Pourquoi ces exigences du secteur sont-elles importantes ?
Gmail et Yahoo ont ouvert la voie, mais nous savions déjà que les normes des boîtes de réception allaient devenir universellement plus strictes. Et c’est en réalité une bonne chose pour les expéditeurs. Si votre configuration d’authentification n’est pas optimale, vos emails n’atteindront peut-être jamais la boîte de réception, même si votre contenu est de qualité et que votre public souhaite avoir de vos nouvelles.
« On peut se montrer très philosophe sur la question du « pourquoi maintenant ? ». Je me souviens avoir parlé de ces changements il y a dix ans avec un groupe, et nous nous disions « pas d’authentification, pas d’entrée ». C’est l’objectif vers lequel nous devrions tendre, car il est tout à fait logique de pouvoir identifier qui envoie un email. Cela nous aide à associer votre réputation à votre identité. Le volume d’emails ne cesse d’augmenter, il y a beaucoup de bruit et de nombreux acteurs malveillants qui profitent de la bonne réputation des expéditeurs. À un moment donné, du côté des fournisseurs de messagerie, nous avons dû dire stop. »
Quelles sont les différences entre les exigences pour les expéditeurs selon les fournisseurs ?
| Exigence | Gmail | Microsoft (Outlook.com) |
|---|---|---|
| Seuil de volume pour l’authentification | Plus de 5 000 messages/jour vers Gmail, Yahoo ne fixe pas de nombre strict mais se situe autour de 5 000. | Plus de 5 000 messages/jour vers Outlook.com, Hotmail.com, Live.com |
| SPF (Sender Policy Framework) | Requis | Requis |
| DKIM (DomainKeys Identified Mail) | Requis | Requis |
| Politique DMARC | Requis. Politique minimale : p=none. Doit être alignée avec SPF ou DKIM. | Requis. Politique minimale : p=none. Doit être alignée avec SPF ou DKIM. |
| Désinscription en un clic (RFC 8058) | Requis. Les expéditeurs d’envois d’emails en masse doivent inclure une désinscription conforme à la norme RFC 8058. | Lien de désabonnement requis. RFC 8058 non requise |
| En-tête List-Unsubscribe | Requis. Doit prendre en charge l’en-tête List-Unsubscribe avec mailto: et une URL. | Non explicitement requis. |
| Seuil du taux de spam | Requis. Doit rester inférieur au seuil de plaintes pour spam de 0,3 % de Gmail/Yahoo. | Aucun seuil défini, mais des listes propres et l’application des bonnes pratiques sont requises. Les expéditeurs non conformes peuvent subir des conséquences négatives. |
| TLS (Transport Layer Security) | Requis. Les emails doivent être envoyés via TLS. | Non mentionné dans les dernières mises à jour de la politique de Microsoft. |
| HELO/EHLO valide | Requis. Ne doit pas utiliser d’adresse IP dynamique ou de nom d’hôte malformé. | Non explicitement requis. |
| Détection de transfert/proxy | Gmail pénalise les comportements de transfert ou de proxy mal configurés. | Aucune directive explicite n’est fournie. |
| Alignement de l’en-tête From: | Doit être aligné avec le domaine DKIM/DMARC. | Recommandé |
| Gestion des utilisateurs inactifs/invalides | Indirectement imposée via le taux de spam et les seuils de plaintes. | Recommandé |
| Adresse Reply-To fonctionnelle | Recommandé | Recommandé |
| Transparence (objets d’email, en-têtes) | Recommandée pour éviter les informations trompeuses. | Recommandée pour éviter les informations trompeuses. |
| Calendrier d’application | L’application complète a débuté en février 2024. | L’application débute le 5 mai 2025 avec des rejets prévus à une date ultérieure à déterminer. |
Que faire ensuite
- Commencez par un audit de délivrabilité : confirmez que vos enregistrements SPF, DKIM et DMARC sont correctement implémentés et alignés.
- Nettoyez votre liste : assurez-vous que vos listes de contacts sont validées afin de ne pas contribuer à votre taux de plainte pour spam.
Chez Mailgun, nous sommes là pour vous aider à traverser ces changements et à garder vos messages dans la boîte de réception, là où ils doivent être.
