Passer DMARC ne garantit pas le placement en boîte de réception.

C’est l’une des réalités les plus importantes de la délivrabilité des emails modernes.

DMARC indique à un serveur de messagerie récepteur si un message est conforme à la politique d’authentification publiée de l’expéditeur. Il aide les destinataires à identifier si un message prétendant provenir d’un domaine est correctement authentifié via SPF ou DKIM.

Mais Gmail et Microsoft ne prennent pas leurs décisions de délivrabilité sur la seule base de DMARC.

Ils évaluent également la réputation de l’expéditeur, le comportement des destinataires, les taux de plaintes, les signaux de contenu, les indicateurs de phishing, le contexte de transfert, les règles au niveau du tenant et les systèmes internes anti-abus.

Cela signifie que deux messages peuvent tous deux passer DMARC et être néanmoins traités différemment par Gmail et Outlook. L’un peut atterrir en boîte de réception. L’autre peut être filtré, limité en débit, placé dans les spams ou rejeté en fonction d’autres signaux.

Pour les organisations qui envoient vers les écosystèmes Google et Microsoft, la leçon est claire :

DMARC est nécessaire, mais ce n’est pas toute l’histoire de la délivrabilité.

I. Pourquoi Gmail et Outlook Gèrent l’Authentification Différemment

Gmail et Microsoft prennent tous deux en charge SPF, DKIM et DMARC.

Tous deux attendent des expéditeurs sérieux qu’ils authentifient leurs emails.

Tous deux utilisent l’authentification dans le cadre d’une prévention plus large des abus.

Mais leurs écosystèmes, outils, politiques et couches de filtrage ne sont pas identiques.

Les exigences publiques de Google pour les expéditeurs sont plus prescriptives pour les expéditeurs en masse. Google exige que tous les expéditeurs authentifient leurs emails avec SPF ou DKIM, et les expéditeurs en masse doivent utiliser SPF, DKIM et DMARC. Google indique également que DMARC passe lorsque SPF ou DKIM authentifie et s’aligne avec le domaine From visible.

Microsoft s’est également orienté vers des exigences d’expéditeur plus strictes. En 2025, Microsoft a annoncé de nouvelles exigences pour les expéditeurs à volume élevé vers les adresses Outlook.com, Hotmail et Live.com, incluant SPF, DKIM et DMARC. Microsoft 365 utilise également ce qu’il appelle l’authentification email implicite, où les SPF, DKIM et DMARC traditionnels sont combinés avec des signaux tels que la réputation de l’expéditeur, l’historique de l’expéditeur, l’historique du destinataire, l’analyse comportementale et d’autres techniques.

La différence pratique n’est pas qu’un fournisseur « se soucie » de DMARC et l’autre non.

La différence est opérationnelle.

Les directives publiques de Gmail donnent aux expéditeurs une base de référence plus claire pour la conformité des emails en masse. L’environnement de filtrage de Microsoft inclut souvent plus de variation spécifique au tenant car Exchange Online Protection, Defender for Office 365, les politiques de boîtes aux lettres, les règles d’autorisation/blocage et les configurations d’entreprise peuvent influencer la façon dont un message est traité.

Pour les expéditeurs, cela crée une réalité simple :

Vous avez besoin d’une authentification qui satisfait les deux fournisseurs, et d’une réputation suffisamment solide pour survivre au filtrage au-delà de l’authentification.

II. Rappel sur DMARC : Ce Qui Doit Réellement Passer

DMARC est souvent mal compris.

Un message ne passe pas DMARC simplement parce que SPF passe.

Un message ne passe pas DMARC simplement parce que DKIM passe.

Un message passe DMARC uniquement lorsqu’au moins un identifiant authentifié s’aligne avec le domaine From visible.

Cela signifie :

• SPF doit passer et le domaine authentifié SPF doit s’aligner avec le domaine From visible.
• Ou DKIM doit passer et le domaine de signature DKIM doit s’aligner avec le domaine From visible.

Ceci est particulièrement important pour les plateformes tierces.

Un outil marketing, une plateforme de support, un CRM, un système de facturation ou un service d’email transactionnel peuvent passer SPF ou DKIM en utilisant leur propre domaine. C’est utile pour le fournisseur, mais cela peut ne pas aider votre résultat DMARC à moins que le domaine authentifié ne s’aligne avec votre domaine From visible.

L’utilisateur voit votre domaine.

DMARC vérifie si le résultat d’authentification se connecte à ce domaine.

III. Ce Que Gmail Exige Que les Expéditeurs Fassent Correctement

Les directives pour expéditeurs de Google font de l’authentification une exigence de base.

Pour les expéditeurs, cela signifie que Gmail attend :

• SPF ou DKIM pour tous les expéditeurs.
• SPF, DKIM et DMARC pour les expéditeurs en masse.
• L’alignement DMARC avec le domaine From visible.
• De faibles taux de plaintes pour spam.
• Une gestion appropriée des abonnements et des exigences de désabonnement pour les emails marketing.

Google fournit également une visibilité via Postmaster Tools. Son tableau de bord d’authentification montre le pourcentage d’emails qui passent SPF, DKIM et DMARC pour les messages utilisant le domaine From de l’expéditeur. Google note que les expéditeurs obtiennent généralement des taux de réussite élevés pour DKIM et DMARC lorsque ces méthodes sont correctement configurées, tandis que le succès SPF peut être inférieur lorsque des expéditeurs tiers sont impliqués.

Cela compte car Gmail donne aux expéditeurs un moyen plus clair d’observer la santé de l’authentification.

Cependant, Gmail Postmaster Tools n’explique pas chaque décision de filtrage individuelle. Un message peut passer l’authentification et être quand même filtré si d’autres signaux indiquent un risque.

Les problèmes courants de délivrabilité Gmail incluent :

• Mauvaise réputation de domaine ou d’IP.
• Taux de plaintes pour spam élevés.
• Pics soudains de volume d’envoi.
• Contenu suspect ou modèles ressemblant à du phishing.
• Expéditeurs tiers mal configurés.
• Échecs DKIM après des changements de clés.
• Échecs d’alignement SPF causés par des domaines Return-Path tiers.

Pour Gmail, l’authentification est la base. Elle vous fait entrer dans la conversation de confiance. Elle ne garantit pas le placement en boîte de réception.

IV. Ce Que Microsoft Exige Que les Expéditeurs Fassent Correctement

L’écosystème de Microsoft inclut Outlook.com, Hotmail, Live.com, Microsoft 365, Exchange Online Protection et Microsoft Defender for Office 365.

Cela crée plus de variation dans la façon dont les messages sont évalués.

Microsoft a publiquement annoncé des exigences pour les expéditeurs à volume élevé vers les adresses Outlook.com, Hotmail et Live.com qui incluent SPF, DKIM et DMARC. Pour Microsoft 365, l’authentification entrante est évaluée via SPF, DKIM, DMARC et des signaux d’authentification implicite supplémentaires tels que la réputation de l’expéditeur, l’historique de l’expéditeur, l’historique du destinataire, l’analyse comportementale et d’autres techniques avancées.

Cela signifie que l’authentification compte, mais qu’elle fait partie d’un système de décision plus large.

Un message envoyé à un environnement Microsoft peut être affecté par :

• Les résultats SPF, DKIM et DMARC.
• La réputation de l’expéditeur.
• L’historique du destinataire ou du tenant.
• Les politiques Defender for Office 365.
• Les règles de transport Exchange.
• Les listes d’autorisation ou de blocage spécifiques au tenant.
• L’intelligence anti-usurpation.
• Les signalements des utilisateurs.
• L’analyse du contenu et des pièces jointes.
• La détection d’URL et de phishing.

C’est pourquoi les expéditeurs voient parfois des différences entre les tenants Microsoft.

Un message peut être accepté par une organisation et filtré par une autre car le tenant récepteur a des politiques différentes, des paramètres de sécurité, des listes d’autorisation ou une relation historique avec l’expéditeur.

Cela ne signifie pas que Microsoft ignore DMARC.

Cela signifie que l’environnement de filtrage de Microsoft a plus de couches que DMARC seul.

V. Gmail vs Outlook : Différences Pratiques pour les Expéditeurs

La comparaison la plus sûre n’est pas « quel fournisseur applique DMARC le plus ».

La meilleure comparaison est la façon dont les expéditeurs expérimentent les deux écosystèmes.

La conclusion opérationnelle est simple :

Si vos emails s’authentifient proprement, s’alignent correctement, maintiennent peu de plaintes et utilisent des modèles d’envoi stables, vous êtes mieux positionné sur Gmail et Microsoft.

Si vos emails échouent l’alignement, utilisent des expéditeurs tiers mal configurés ou ont une faible réputation, les problèmes d’authentification peuvent apparaître différemment dans les deux écosystèmes.

VI. Les Expéditeurs Tiers Sont le Point de Défaillance Commun

La plupart des organisations n’envoient pas tous leurs emails depuis un seul système.

Elles utilisent :

• Des plateformes d’automatisation marketing.
• Des systèmes CRM.
• Des outils de support.
• Des plateformes de ticketing.
• Des services d’email transactionnel.
• Des systèmes de facturation.
• Des plateformes événementielles.
• Des outils RH.
• Des plateformes régionales ou par unité commerciale.

Chaque expéditeur doit être authentifié et aligné.

C’est là que les programmes DMARC échouent souvent.

Une plateforme tierce peut être incluse dans SPF, mais SPF peut ne pas s’aligner car le domaine Return-Path appartient au fournisseur.

Une autre plateforme peut signer le message avec DKIM, mais le domaine DKIM d= peut appartenir au fournisseur plutôt qu’à votre domaine.

Dans les deux cas, le message peut avoir une authentification, mais échouer quand même l’alignement DMARC.

Cela peut affecter Gmail et Microsoft différemment car chaque fournisseur combine l’authentification avec d’autres signaux de filtrage. Mais la solution est la même :

Configurez chaque expéditeur tiers pour passer SPF aligné ou DKIM aligné.

Dans de nombreux cas, DKIM aligné est le chemin le plus fiable car SPF peut se casser dans les scénarios de transfert et d’infrastructure d’envoi partagée.

VII. Quand DMARC Passe mais la Délivrabilité Échoue Quand Même

Passer DMARC n’est pas la même chose que le placement en boîte de réception.

Un message peut passer DMARC et être quand même filtré en raison de :

• Taux de plaintes élevés.
• Faible engagement.
• Mauvaise réputation de domaine.
• Mauvaise réputation d’IP.
• Contenu suspect.
• Indicateurs de phishing.
• URL dangereuses.
• Pics soudains de volume.
• Mauvaise hygiène de liste.
• Filtrage au niveau du destinataire.
• Règles au niveau du tenant.

Ceci est vrai pour Gmail et Microsoft.

L’authentification prouve que le message est autorisé à utiliser le domaine.

Elle ne prouve pas que le message est voulu, sûr ou de haute qualité.

Cette distinction compte.

Un expéditeur peut avoir des SPF, DKIM et DMARC parfaits et avoir quand même de mauvaises performances si les destinataires marquent les messages comme spam, ignorent les emails ou si le contenu déclenche les systèmes de filtrage.

VIII. Quand DMARC Échoue mais l’Email Semble Quand Même Être Délivré

L’inverse peut également se produire.

Un message peut échouer DMARC et sembler quand même être délivré.

Les raisons possibles incluent :

• Le fournisseur récepteur applique un contexte supplémentaire.
• Le message est transféré et évalué avec des signaux d’authentification supplémentaires.
• Le destinataire ou le tenant a mis l’expéditeur sur liste blanche.
• Le message est placé dans le spam plutôt que rejeté.
• Le destinataire traite la politique publiée du domaine différemment dans des scénarios spécifiques.
• Le message est jugé à faible risque par d’autres systèmes de filtrage.

Cela ne signifie pas que DMARC est non pertinent.

Cela signifie que DMARC est un signal dans une décision côté réception plus large.

Les expéditeurs ne devraient pas utiliser la délivrabilité occasionnelle d’emails échouants comme preuve que l’authentification est saine.

Si les rapports DMARC montrent des échecs, ces échecs devraient être investigués même lorsque les utilisateurs ne signalent pas de problèmes de délivrabilité.

IX. Modes de Défaillance Silencieux à Surveiller

Les problèmes les plus dangereux sont ceux qui ne créent pas de tickets de support immédiats.

1. Dérive d’Authentification

Un fournisseur change d’infrastructure. Un sélecteur DKIM est mal tourné. Les includes SPF changent. Une équipe commerciale ajoute un nouveau type d’envoi.

Les emails peuvent continuer à être délivrés pendant un certain temps, mais les rapports DMARC commencent à montrer des échecs.

Sans surveillance, le problème reste caché jusqu’à ce que la délivrabilité chute ou que le risque d’usurpation augmente.

2. Masquage de Réputation

Un expéditeur avec une forte réputation peut ne pas voir d’impact immédiat sur la délivrabilité de certains problèmes d’authentification.

Cela peut créer une fausse confiance.

L’écart d’authentification existe toujours, et il peut devenir visible plus tard lorsque la réputation change, le volume augmente ou les seuils de filtrage du fournisseur évoluent.

3. Différences de Délivrabilité Spécifiques au Tenant

Les environnements Microsoft peuvent varier selon la configuration du tenant.

Un client peut recevoir le message. Un autre peut le mettre en quarantaine. Un autre peut le bloquer en raison de règles locales ou d’une politique Defender.

Cela rend le dépannage plus difficile car les résultats d’authentification seuls n’expliquent pas chaque résultat de délivrabilité.

4. Transfert et Listes de Diffusion

Le transfert peut casser SPF car le serveur de transfert n’est pas autorisé dans l’enregistrement SPF de l’expéditeur original.

DKIM peut survivre au transfert si le message n’est pas modifié. Si DKIM échoue également, DMARC peut échouer.

ARC peut aider les destinataires à évaluer le contexte des emails transférés, mais les expéditeurs devraient quand même viser un alignement DKIM fort pour réduire la dépendance au comportement de transfert.

X. Guide de Mise en Œuvre pour Gmail et Microsoft

Un programme d’authentification solide ne devrait pas être conçu pour un seul fournisseur.

Il devrait fonctionner dans les deux écosystèmes.

1. Publier DMARC et Surveiller les Rapports

Commencez par la surveillance pour identifier les expéditeurs légitimes et les échecs.

Un enregistrement statique de base peut ressembler à :

v=DMARC1; p=none; rua=mailto:[email protected]

Une meilleure approche consiste à utiliser un enregistrement de surveillance DMARC géré via Skysnag afin que les rapports soient collectés, analysés et transformés en intelligence d’expéditeur exploitable.

Commencez la surveillance DMARC avec Skysnag et obtenez votre enregistrement DMARC gratuit.

2. Authentifier Chaque Expéditeur Légitime

Pour chaque expéditeur, confirmez :

• SPF est autorisé si nécessaire.
• DKIM est activé.
• Au moins une méthode s’aligne avec le domaine From visible.
• L’expéditeur est documenté.
• Le propriétaire commercial est connu.
• L’authentification est surveillée dans le temps.

3. Préférer DKIM Aligné pour les Plateformes Tierces

Dans la mesure du possible, configurez les plateformes tierces pour signer DKIM en utilisant votre domaine.

Cela réduit la dépendance à l’alignement SPF, qui peut être fragile lorsque les emails passent par une infrastructure partagée ou des chemins de transfert.

4. Séparer les Flux d’Emails

Utilisez des domaines ou sous-domaines appropriés pour différentes catégories d’emails.

Par exemple :

• Emails transactionnels.
• Emails marketing.
• Emails de support.
• Notifications de sécurité.
• Systèmes internes.

Cela facilite la gestion de l’authentification et la protection de la réputation.

5. Passer à l’Application avec Prudence

Ne restez pas à p=none indéfiniment.

Après la découverte et la remédiation, passez les domaines matures vers quarantine puis reject.

Une approche par étapes devrait être basée sur :

• La maturité du domaine.
• La maturité du sous-domaine.
• La stabilité du groupe d’expéditeurs.
• La criticité commerciale.
• Les taux de passage d’authentification.
• Le statut de remédiation.

Évitez le déploiement basé sur le pourcentage comme stratégie principale. Les programmes DMARC actuels devraient échelonner l’application par domaine, sous-domaine, groupe d’expéditeurs et unité commerciale plutôt que de s’appuyer sur pct.

6. Surveiller la Réputation Séparément de l’Authentification

Les rapports DMARC montrent les résultats d’authentification.

Ils n’expliquent pas complètement le placement en boîte de réception.

Utilisez les outils des fournisseurs et les métriques opérationnelles lorsque disponibles, incluant :

• Google Postmaster Tools.
• Traçage des messages Microsoft 365 et rapports de sécurité le cas échéant.
• Données de rebonds.
• Tendances des plaintes.
• Métriques d’engagement.
• Surveillance des listes noires et de la réputation.
• Tests de délivrabilité sur les fournisseurs de messagerie.

L’authentification et la réputation doivent être surveillées ensemble.

XI. Implications en Matière de Conformité

L’authentification des emails soutient de nombreux programmes de conformité et de gouvernance, mais elle doit être décrite avec précision.

DMARC peut soutenir les objectifs anti-phishing, de protection de domaine, de supervision des fournisseurs et d’intégrité des communications. Il peut également fournir des preuves que l’organisation surveille les envois non autorisés et les échecs d’authentification.

Cependant, DMARC ne satisfait pas automatiquement le RGPD, PCI DSS, HIPAA, SOC 2, NIS2 ou tout autre cadre par lui-même.

Meilleur cadrage :

• DMARC soutient les contrôles anti-phishing et d’intégrité des communications.
• SPF et DKIM soutiennent l’authentification de l’expéditeur.
• Les rapports DMARC soutiennent la surveillance et la collecte de preuves.
• L’application soutient la protection contre l’usurpation de domaine exact.
• MTA-STS et TLS-RPT soutiennent la visibilité du transport sécurisé des emails.

Skysnag Comply aide les organisations à maintenir la visibilité, les rapports et les preuves autour de la posture d’authentification des emails à travers les sources d’envoi et les domaines.

XII. Modèle Opérationnel Pratique

Pour les organisations qui envoient vers Gmail et Microsoft, le modèle opérationnel devrait être simple :

1. Connaître chaque expéditeur.
2. Authentifier chaque expéditeur.
3. Aligner au moins une méthode d’authentification avec le domaine From visible.
4. Surveiller les rapports DMARC en continu.
5. Suivre la réputation du fournisseur et les signaux de plaintes.
6. Séparer les flux d’emails par fonction et risque.
7. Passer de la surveillance à l’application lorsque prêt.
8. Traiter les problèmes de délivrabilité comme des problèmes d’authentification et de réputation.
9. Examiner régulièrement les expéditeurs tiers.
10. Maintenir la documentation pour l’audit et la gouvernance.

Ce modèle fonctionne car il ne dépend pas de deviner exactement comment Gmail ou Microsoft pondère chaque signal en interne.

Il se concentre sur les contrôles que les expéditeurs peuvent réellement gérer.

XIII. Points Clés

Gmail et Microsoft exigent tous deux une authentification email robuste pour les expéditeurs sérieux, en particulier les expéditeurs à volume élevé.

Les exigences publiques de Gmail pour les expéditeurs sont plus prescriptives pour les expéditeurs en masse, tandis que Microsoft combine l’authentification traditionnelle avec des signaux d’authentification implicites tels que la réputation, l’historique de l’expéditeur, l’historique du destinataire, l’analyse comportementale et les contrôles spécifiques au tenant.

La conformité DMARC ne garantit pas le placement en boîte de réception.

L’échec DMARC n’entraîne pas toujours un rejet immédiat.

L’authentification doit être gérée parallèlement à la réputation, aux taux de plaintes, à la qualité du contenu, aux modèles d’envoi et à la visibilité spécifique au fournisseur.

Le plus grand risque opérationnel est le désalignement des expéditeurs tiers. Chaque plateforme envoyant au nom du domaine doit être configurée pour réussir le SPF aligné ou le DKIM aligné.

La stratégie la plus sûre n’est pas d’optimiser séparément pour Gmail ou Microsoft. Il s’agit de construire un programme d’authentification discipliné qui fonctionne pour les deux.

Commencez la surveillance DMARC avec Skysnag et obtenez votre enregistrement DMARC gratuit.