Mailgun : DMARCbis est mort

Mailgun : DMARCbis est mort. Longue vie à DMARC. 

La norme DMARC mise à jour est arrivée. Voici ce qui a changé, ce qui n’a pas changé, et ce que cela implique lorsque vous envoyez des e-mails via Mailgun. 

Juste au moment où vous vous habituiez aux nouvelles politiques DMARC…
En mai 2026, l’IETF a publié un nouvel ensemble de RFC DMARC qui remplace la RFC 7489 : RFC 9989 (DMARC de base), RFC 9990 (rapports agrégés) et RFC 9991 (rapports d’échec). DMARCbis, précédemment connu comme le brouillon de la « prochaine version de DMARC », est désormais la norme DMARC publiée. 

Pourquoi est-ce important ?
Ce changement est important car les fournisseurs de messagerie s’attendent de plus en plus à recevoir des emails authentifiés et alignés comme comportement de base de l’expéditeur. Les RFC DMARC mises à jour ne modifient pas radicalement ces attentes, mais elles clarifient et formalisent des pratiques que de nombreux expéditeurs et ESP appliquent déjà aujourd’hui. 

Pour les expéditeurs Mailgun, il est utile de le comprendre, mais ce n’est pas un moment du type « arrachez vos DNS d’ici vendredi ». Les principes fondamentaux restent les mêmes : authentifiez vos emails, gardez vos identifiants alignés, surveillez vos rapports et corrigez les flux qui ne s’alignent pas. 

La norme mise à jour est plus propre, plus explicite et mieux alignée sur la manière dont l’authentification des emails à grande échelle est opérée en production. Pour la plupart des expéditeurs qui utilisent déjà correctement des domaines authentifiés et des identifiants alignés, cette mise à jour des RFC est plus évolutive que perturbatrice.

Les RFC mises à jour remanient, clarifient et modernisent principalement la documentation DMARC ; elles ne modifient pas fondamentalement le modèle d’évaluation de base « SPF aligné ou DKIM aligné » de DMARC.

• Trois RFC au lieu d’une : la RFC 9989 couvre la politique et l’alignement, la RFC 9990 couvre les rapports globaux et la RFC 9991 couvre les rapports d’échec. 

• Parcours de l’arborescence DNS pour la découverte de la politique : Les destinataires peuvent remonter la hiérarchie DNS au lieu de s’appuyer sur une liste de suffixes publics statique. En pratique, cela affecte principalement les structures de domaine très vastes ou complexes (comme certains environnements .edu, .gov ou des suffixes publics) et nécessite des modifications d’implémentation du côté de la réception. La plupart des expéditeurs devraient toujours publier des enregistrements DMARC explicites sur les domaines qu’ils utilisent activement pour les emails, plutôt que de s’appuyer sur le comportement de repli du domaine organisationnel.

• Modifications des balises : De nouvelles balises comme np (politique de sous-domaine inexistant) et psd (domaine de suffixe public) sont ajoutées ; les balises obsolètes comme pct, rf, et ri sont supprimées ; une nouvelle balise t décrit mieux le comportement de test. 

Si vous gérez des enregistrements DMARC, vous pouvez éventuellement choisir de supprimer les balises retirées comme pct, rf, et ri pour des raisons de propreté et de lisibilité, bien que les destinataires soient censés ignorer les balises inconnues ou obsolètes. La plupart des expéditeurs n’auront probablement pas besoin de la nouvelle balise psd, tandis que np peut être pertinente pour les organisations gérant des structures de sous-domaine vastes ou complexes.

La partie que les clients Mailgun doivent garder à l’esprit : 

DMARC réussit toujours lorsque le domaine visible From s’aligne avec soit SPF, soit DKIM, et pas seulement lorsque les deux s’alignent. 

DMARC évalue toujours si le domaine de l’auteur (visible From) s’aligne avec un identifiant authentifié provenant de : 

• SPF (domaine MAIL FROM / Return‑Path) 

• DKIM (d= domaine de signature) 

L’alignement reste strict (correspondance exacte) ou assoupli (même domaine organisationnel, tel que mg.example.com et example.com). 

Il vaut également la peine de séparer l’alignement du domaine de la réputation de l’adresse IP. Les adresses IP partagées par rapport aux adresses IP dédiées affectent la gestion de la réputation, le préchauffage et la visibilité du dépannage, mais elles ne modifient pas fondamentalement le fonctionnement de l’alignement DMARC. Que vous envoyiez sur une infrastructure partagée ou dédiée, DMARC évalue toujours si votre domaine visible From s’aligne avec les identifiants authentifiés SPF ou DKIM. 

DMARC continue de s’appuyer sur « SPF ou DKIM avec alignement », et non sur « SPF et DKIM et DMARC réussissant tous de manière indépendante ». Le succès de DMARC ne garantit toujours pas le placement en boîte de réception ; il prouve l’utilisation autorisée du domaine, tandis que la réputation, l’engagement et le contenu décident toujours de l’endroit où le message atterrit. 

C’est ici que la spécification rencontre ce que vous faites dans le panneau de contrôle Mailgun. 

Comment Mailgun utilise vos domaines authentifiés 

Lorsque vous ajoutez un domaine d’envoi (souvent un sous-domaine comme mg.example.com) dans Mailgun : 

• Mailgun vous fournit des enregistrements TXT SPF et DKIM à publier sur ce domaine, ainsi que des enregistrements MX et CNAME de suivi optionnels. 

• Le domaine doit être vérifié avant que vous ne puissiez envoyer ; le flux standard de domaine authentifié de Mailgun attend une clé DKIM valide dans le DNS avant que le domaine ne soit traité comme pleinement authentifié. 

Une fois que cela est fait : 

• Mailgun signe les emails sortants avec DKIM en utilisant votre domaine d’envoi dans la valeur d=, par exemple d=mg.example.com. 

• Le MAIL FROM / Return-Path est généralement basé sur votre domaine d’envoi Mailgun 

Mailgun est capable d’envoyer des emails totalement alignés sur SPF en utilisant vos sous-domaines authentifiés, et pas seulement des MAIL-FROM sur un domaine appartenant au fournisseur par défaut. 

En d’autres termes, dans le flux standard de domaine authentifié, Mailgun authentifie les emails sur vos domaines, de sorte que l’alignement réside de votre côté. 

Si vous utilisez le modèle classique de Mailgun consistant à avoir des sous-domaines d’envoi dédiés, du SPF et DKIM fournis par Mailgun sur ces domaines, et un domaine From correspondant, alors l’alignement SPF et l’alignement DKIM sont tous deux réalisables sans contournements particuliers. 

L’Automatic Sender Security (ASS) ne change pas cette situation : elle automatise la génération et la rotation des clés pour les sélecteurs de votre domaine, mais la signature utilise toujours votre domaine dans d=. 

Vous pouvez conserver votre architecture actuelle. Cependant, vous devez vous assurer qu’elle correspond à ce que DMARC décrit désormais plus clairement. 

1. Inventory Mailgun domains and usage 
   • Répertoriez tous les domaines vérifiés par Mailgun et quels flux (transactionnel, marketing, notifications d’application) utilisent chacun d’eux. 
   • Retirez ou renforcez DMARC sur les domaines qui ne sont plus activement utilisés, en particulier s’ils ont encore des enregistrements permissifs. 
2. Verify aligned SPF and DKIM, not just “pass” 
   • Confirmez que le SPF est correctement publié sur chaque domaine d’envoi Mailgun et que ces domaines partagent un domaine organisationnel avec le domaine From visible. 
   • Utilisez un analyseur d’en-tête pour confirmer que le d= dans la signature DKIM correspond à votre domaine d’envoi Mailgun (ou à un sous-domaine de votre organisation), et non à un nom d’hôte non lié. 
3. Clean up your DMARC records 
   • Supprimez les balises pct, rf, et ri, que la nouvelle spécification abandonne. 
   • Évaluez si np et psd sont pertinentes pour la structure de votre domaine. 
   • Confirmez que votre comportement sp= pour les sous-domaines est intentionnel. 

4. Treat aggregate reports as an early‑warning system 
   • Utilisez les rapports globaux DMARC pour repérer les nouveaux domaines Mailgun, les flux hérités oubliés ou les expéditeurs tiers mal alignés qui utilisent votre domaine. 
   • Si vous êtes à p=none, traitez cela comme une surveillance active, et non comme un « nous regarderons un jour ». 

5. Keep DMARC and DKIM2 mentally separate 
   • Vous entendrez davantage parler de DKIM2, mais il s’agit d’un effort de protocole distinct axé sur les modèles de signature et les protections contre la relecture. 
   • La mise à jour des RFC DMARC ne fait pas de DKIM2 une exigence, et les évaluations DMARC actuelles s’appuient toujours sur SPF et DKIM exactement comme auparavant. Il y a une discussion en cours au sein de l’IETF sur la question de savoir si DKIM2 pourrait éventuellement jouer un rôle dans les futures évaluations de type DMARC, mais ces travaux restent séparés et non réglés pour le moment.

DMARCbis est mort. Longue vie à DMARC. Pour la plupart des clients Mailgun qui utilisent déjà correctement des domaines authentifiés et des identifiants alignés, les nouvelles RFC devraient davantage ressembler à une clarification des bonnes pratiques existantes qu’à un changement opérationnel majeur. 

Author: Alison Gootee