Aller au contenu
DMARC
← Blog

Mailgun : SPF, DKIM et alignement DMARC par sous-domaine

Par Thomas · RSSI virtuel · 06 septembre 2026

Mailgun s'adresse d'abord aux équipes techniques : une API d'envoi, un relais SMTP, des webhooks d'événements, le tout pensé pour le courrier transactionnel et les gros volumes applicatifs. Cette orientation développeur se retrouve dans sa manière de gérer l'authentification — plus explicite, plus segmentée que celle d'une suite bureautique, et fondée sur un principe que la plateforme met en avant dès la configuration : l'envoi passe par un sous-domaine dédié, distinct du domaine principal.

Ce choix n'est pas cosmétique. Il conditionne à la fois la réputation d'expédition et la façon dont DMARC s'applique. Un domaine ajouté à Mailgun sans que ses enregistrements soient posés émet sous l'identité de la plateforme : la signature DKIM et l'enveloppe ne se rattachent en rien au domaine affiché dans le champ From, et une politique p=reject rejette ce trafic pourtant légitime. Tant que SPF et DKIM ne sont pas publiés puis vérifiés, rien ne s'aligne.

Ce guide détaille la logique du sous-domaine d'envoi, les enregistrements SPF et DKIM à poser, l'alignement DMARC qui en découle en mode relâché, la question de la région — US ou UE, avec ses implications de résidence des données — puis les erreurs de configuration les plus fréquentes et la contre-épreuve par les rapports RUA.

Le sous-domaine d'envoi : isoler la réputation

Mailgun recommande de configurer l'envoi sur un sous-domaine — par exemple mg.exemple.fr — plutôt que sur le domaine racine. La raison tient à la réputation. Le courrier transactionnel à fort volume, les campagnes, les notifications applicatives ont un profil d'envoi très différent du courrier humain du domaine principal ; les isoler sur un sous-domaine évite qu'un incident de délivrabilité côté campagne ne contamine la réputation du domaine racine, celui d'où part le courrier des personnes.

Cette séparation a une conséquence directe sur l'authentification : les enregistrements SPF et DKIM sont posés dans la zone du sous-domaine, pas du domaine racine. La signature DKIM portera d=mg.exemple.fr, l'enveloppe sera au sous-domaine — et c'est en mode relâché que ces éléments s'aligneront avec exemple.fr. Le domaine racine, lui, conserve son propre SPF et sa propre configuration pour le courrier humain, sans interférence.

Que l'envoi passe par l'API HTTP ou par le relais SMTP ne change rien à cette mécanique : dans les deux cas, Mailgun appose la même signature DKIM et emploie la même enveloppe. Le choix entre API et SMTP est une question d'intégration applicative, jamais d'authentification — un point utile à garder en tête quand un même domaine d'envoi sert plusieurs applications par des voies différentes.

Les enregistrements : SPF, DKIM, MX et suivi

L'assistant de Mailgun génère un jeu d'enregistrements à poser dans la zone du sous-domaine d'envoi :

mg.exemple.fr.            TXT    "v=spf1 include:mailgun.org ~all"
k1._domainkey.mg.exemple.fr.  TXT    "k=rsa; p=MIIBIjANBgkq…"
mg.exemple.fr.            MX     10 mxa.mailgun.org.
mg.exemple.fr.            MX     10 mxb.mailgun.org.
email.mg.exemple.fr.     CNAME  mailgun.org.

L'enregistrement SPF autorise les serveurs de Mailgun à émettre pour le sous-domaine. Le TXT DKIM publie la clé publique sous un sélecteur fourni par la plateforme (souvent k1) : la signature apposée par Mailgun sera vérifiable via ce sélecteur. Les deux MX permettent à Mailgun de recevoir les rebonds et les réponses adressés au sous-domaine ; ils sont recommandés dès lors que le suivi de délivrabilité compte. Le CNAME email. sert enfin au suivi des ouvertures et des clics — sans effet sur l'authentification, mais souvent posé dans le même mouvement.

Sur la longueur de clé, Mailgun propose du 1024 et du 2048 bits ; 2048 est le choix à retenir, plusieurs opérateurs de messagerie traitant désormais 1024 comme faible. La renouvellement des clés de signature se fait en publiant un nouveau sélecteur avant de retirer l'ancien, sans fenêtre de coupure.

L'alignement DMARC : le mode relâché en action

DMARC ne valide un message que si SPF ou DKIM passe et s'aligne avec le domaine du champ From. Le montage par sous-domaine de Mailgun s'appuie sur l'alignement relâché, qui est le mode par défaut de DMARC.

En mode relâché, un sous-domaine s'aligne avec son domaine organisationnel : mg.exemple.fr s'aligne avec exemple.fr. Ainsi, un message envoyé avec un From en @exemple.fr, une signature DKIM d=mg.exemple.fr et une enveloppe au sous-domaine passe DMARC sur les deux mécanismes. Sous DMARCbis, le domaine organisationnel se détermine par le DNS Tree Walk plutôt que par l'ancienne Public Suffix List, mais le résultat est identique : le sous-domaine et le domaine racine sont reconnus comme relevant de la même organisation.

Un détail mérite d'être posé sur le champ From. Deux montages coexistent : un From en @exemple.fr — le plus courant, l'identité de marque — qui s'appuie sur l'alignement relâché du sous-domaine, ou un From directement en @mg.exemple.fr, qui aligne alors en strict comme en relâché mais expose le sous-domaine technique aux yeux des destinataires. Le premier est presque toujours préférable pour la lisibilité de l'adresse affichée ; le second ne se rencontre que sur des flux purement machine où l'apparence de l'adresse importe peu.

Le seul cas où ce montage échoue est l'alignement strict, qui exige une correspondance exacte du domaine. Une politique DMARC qui impose adkim=s ou aspf=s casserait l'alignement d'un envoi via mg.exemple.fr sous un From @exemple.fr. Sauf besoin précis, le mode relâché reste le bon choix — c'est lui qui rend le montage par sous-domaine viable. Les modèles annotés montrent où se règlent ces balises d'alignement.

Région US ou UE : la résidence des données

Mailgun opère deux régions distinctes, américaine et européenne, choisies à la création du domaine d'envoi. Le choix a deux effets. Le premier est technique : l'API et le point d'entrée SMTP diffèrent, et un domaine créé dans une région doit être piloté via l'endpoint de cette région — une confusion fréquente lorsqu'un script hérité pointe encore l'endpoint américain pour un domaine européen.

Le second effet touche la résidence des données. Pour une organisation soumise à des exigences de souveraineté, la région européenne maintient le traitement des e-mails et des journaux associés dans l'UE. Ce point relève moins de l'authentification que de la conformité, mais il se décide au même moment — à la création du domaine — et se corrige mal après coup : changer de région implique de recréer le domaine d'envoi et de reposer tous les enregistrements. Autant le trancher d'emblée.

IP partagée, IP dédiée et montée en charge

Mailgun propose deux régimes d'adresses d'émission. Par défaut, les envois passent par un pool d'IP partagé : la réputation y est mutualisée entre clients, ce qui convient aux volumes modérés et démarre sans échauffement. Au-delà d'un certain volume régulier, une IP dédiée devient pertinente — la réputation n'appartient alors qu'à l'organisation, mais elle se construit : une IP neuve doit être chauffée, c'est-à-dire montée en volume progressivement sur plusieurs jours, sous peine d'être traitée comme suspecte par les fournisseurs destinataires.

Ce choix n'a aucun effet sur l'alignement DMARC — DKIM et SPF s'alignent de la même façon quelle que soit l'IP émettrice — mais il pèse sur la délivrabilité, donc sur la lecture des rapports. Une IP dédiée fraîche peut voir une part de ses messages temporisés le temps de l'échauffement, sans que rien ne cloche côté authentification. Distinguer un problème de réputation d'un problème d'alignement est précisément ce que les rapports agrégés permettent : le premier se lit dans les taux de remise, le second dans les colonnes SPF et DKIM.

Les erreurs de configuration courantes

Plusieurs pièges reviennent dans le corpus de rapports que l'analyseur DMARC gratuit traite au quotidien.

Poser les enregistrements sur le domaine racine. Configurer Mailgun sur exemple.fr au lieu de mg.exemple.fr fait perdre l'isolation de réputation et mélange le SPF de la plateforme avec celui du courrier humain — un enchevêtrement qui complique tout diagnostic ultérieur.

Confondre les régions. Un domaine créé côté UE mais piloté via l'endpoint US ne s'authentifiera pas comme attendu, et les rapports le montreront.

Oublier de vérifier le domaine dans la console. Comme chez d'autres plateformes, publier les enregistrements ne suffit pas : Mailgun doit constater leur propagation et marquer le domaine comme vérifié avant que les signatures ne soient réellement apposées.

Durcir la politique trop tôt. Passer à p=reject, ou pire à un alignement strict, avant d'avoir confirmé par les rapports que tout le trafic légitime s'aligne, revient à risquer le rejet de ses propres envois.

La contre-épreuve : les rapports RUA

La seule preuve qu'une configuration tient n'est pas la console Mailgun, mais ce que rapportent les destinataires. Une fois l'enregistrement _dmarc publié avec une adresse rua=, les rapports agrégés arrivent sous quelques jours et détaillent, source par source, ce qui s'aligne et ce qui échoue. La lecture des rapports DMARC agrégés confirme que le trafic Mailgun est bien rattaché au domaine : la source correspondant au sous-domaine d'envoi doit y apparaître avec DKIM et SPF alignés.

Une cadence simple suffit : une première lecture quelques jours après la publication de l'enregistrement _dmarc, une fois que plusieurs destinataires ont rapporté, puis un coup d'œil hebdomadaire tant que la politique reste en p=none. Le trafic Mailgun se reconnaît vite à ses plages d'adresses stables ; toute source nouvelle ou non alignée ressort immédiatement — un second domaine d'envoi oublié, une région mal branchée, un sélecteur DKIM jamais vérifié. Une fois l'alignement confirmé sur plusieurs jours et sur l'ensemble des flux, la montée vers p=reject se fait sans risque. L'analyseur en ligne recompose cet état à partir des enregistrements publiés et des rapports reçus, et situe le domaine sur le chemin qui mène à p=reject.

Guides liés

À propos de l'auteur

Thomas — Thomas est le RSSI virtuel de DMARC.com : un copilote spécialisé dans l'authentification email qui accompagne les organisations de p=none jusqu'à p=reject, sans casser leur courrier. Ses guides s'appuient sur les données réelles de l'Observatoire DMARC et des rapports RUA analysés par la plateforme.