Niveau de preuve : C — faits vérifiés à la source officielle. Aucun compte Mailgun n’a été ouvert ni payé pour écrire cette page. Tout ce qui suit est lu dans la documentation de Mailgun, dans la RFC 7489 et dans les exigences publiées par Google. Dernière vérification : 21 septembre 2026.
En bref. Des cinq enregistrements DNS du tableau, deux seulement sont obligatoires pour envoyer avec Mailgun : SPF et DKIM. Le CNAME de suivi est facultatif, et il réécrit les liens des courriels — ce qui en fait une collecte de renseignements au sens de la Loi 25. Sur les MX, deux pages officielles de Mailgun se contredisent : le tableau de vérification de domaine les marque requis, le centre d’aide dit de ne pas les pointer vers Mailgun quand le domaine reçoit déjà son courriel ailleurs — les deux sont citées plus bas, le point reste ouvert. Depuis le 1er février 2024, Google exige SPF ou DKIM de tout expéditeur, et SPF, DKIM et DMARC au-delà de 5 000 messages par jour vers des comptes Gmail, avec un taux de plainte sous 0,30 %. Mailgun n’offre que deux régions d’hébergement, les États-Unis et l’Union européenne ; aucune région canadienne, relevé le 21 septembre 2026.
À lire aussi
- Mes courriels arrivent dans les indésirables : la liste de vérification — pourquoi les courriels tombent dans les indésirables
- Combien coûte vraiment l’envoi de 50 000 courriels par mois : le coût mensuel relevé chez cinq services, dépassements compris — combien coûte l’envoi de 50 000 courriels par mois
Une application qui envoie des courriels — confirmations de commande, réinitialisations de mot de passe, avis de livraison — ne devrait pas passer par une boîte Gmail ordinaire. Elle passe par un service d’envoi transactionnel, et Mailgun en est un. Mais avant qu’un seul courriel parte, il faut publier des enregistrements dans la zone DNS du domaine. C’est l’étape où la moitié des implantations achoppent, parce que les quatre enregistrements demandés ne font pas la même chose et que deux d’entre eux sont souvent ajoutés à tort.
Cette page décrit les quatre enregistrements DNS que Mailgun demande, ce que chacun fait, lequel est facultatif, et les trois exigences que Google impose depuis le 1er février 2024 à qui envoie plus de 5 000 messages par jour vers des comptes Gmail.
Les quatre enregistrements, en un tableau
| Enregistrement | Type | Valeur | Obligatoire ? | Ce qu’il fait |
|---|---|---|---|---|
| SPF | TXT | v=spf1 include:mailgun.org ~all | oui, pour envoyer | Déclare que les serveurs de Mailgun ont le droit d’envoyer au nom du domaine |
| DKIM | TXT | clé affichée dans le tableau de bord Mailgun | oui, pour envoyer | Signe chaque message ; le serveur receveur vérifie la signature |
| Suivi | CNAME | mailgun.org | non | Ouvertures, clics, désabonnements |
| MX | MX | 10 mxa.mailgun.org et 10 mxb.mailgun.org | ⚠️ deux pages officielles se contredisent — voir plus bas | Fait arriver le courriel entrant chez Mailgun |
| DMARC | TXT | à composer soi-même | non chez Mailgun, oui chez Gmail en gros volume | Dit au serveur receveur quoi faire quand SPF et DKIM échouent |
Sources : documentation de Mailgun, section « Domains » et « Domain verification », consultée le 21 septembre 2026 ; exigences d’expéditeur de Google (support.google.com/a/answer/81126), consultées le 21 septembre 2026.
SPF — qui a le droit d’écrire en votre nom
SPF est une liste publique. Elle dit : voici les serveurs autorisés à envoyer du courriel portant ce nom de domaine. Quand un message arrive chez Gmail, Gmail lit cette liste et compare avec l’adresse du serveur qui vient de lui parler. Si le serveur n’y est pas, le message devient suspect.
L’enregistrement de Mailgun est v=spf1 include:mailgun.org ~all. Le mot include signifie « et aussi tous les serveurs que mailgun.org déclare » — c’est ce qui permet à Mailgun de changer ses propres serveurs sans que personne ait à toucher à sa zone DNS.
Le piège classique : un seul enregistrement SPF par domaine. Une entreprise qui a déjà Google Workspace a déjà un SPF. Si elle en ajoute un deuxième pour Mailgun, les deux se neutralisent et l’authentification échoue. Il faut fusionner les deux dans une seule ligne. Google le dit explicitement dans ses exigences : « The SPF record for your domain should include all email senders for your domain. If your third-party senders aren’t included in your SPF record, messages from these senders are more likely to be marked as spam. »
DKIM — la signature cryptographique
Là où SPF autorise un serveur, DKIM signe un message. Mailgun génère une paire de clés : la clé privée reste chez Mailgun et sert à signer chaque envoi, la clé publique est publiée dans le DNS sous forme d’enregistrement TXT. Le serveur receveur lit la clé publique, vérifie la signature, et sait que le message n’a pas été modifié en route et qu’il vient bien du domaine annoncé.
La valeur exacte à publier n’est pas générique : elle est affichée dans le tableau de bord Mailgun, section « Domain Verification & DNS ». La documentation prévient aussi que « Mailgun may display multiple DKIM keys for a domain, and some may appear in an Unverified state » — seule la clé qui correspond à la configuration du domaine doit être vérifiée, pas toutes.
Longueur de clé. Google exige au minimum 1 024 bits pour l’envoi vers des comptes Gmail personnels, et recommande 2 048 bits. C’est un point à vérifier chez le fournisseur DNS, parce que certains tronquent les enregistrements TXT longs.
L’enregistrement de suivi — facultatif, et pas anodin
Le CNAME de suivi pointe vers mailgun.org. Il sert à réécrire les liens contenus dans les courriels pour compter les ouvertures et les clics.
Il n’est pas obligatoire pour envoyer. Il change en revanche les messages : les liens ne pointent plus vers le site, mais vers un domaine de suivi. Une organisation soumise à la loi 25 devrait savoir que le suivi des ouvertures et des clics est une collecte de renseignements, et le traiter comme telle.
MX — l’erreur la plus fréquente
Les enregistrements MX disent au monde entier où livrer le courriel entrant d’un domaine. Ils n’ont rien à voir avec l’envoi.
La documentation de Mailgun marque les MX comme requis dans son tableau de vérification de domaine, avec la précision « Required for Mailgun to receive and route/store messages addressed to the domain ». Mais le centre d’aide de Mailgun est plus direct sur le cas de l’entreprise qui veut seulement envoyer : « If you’d like to register your domain at multiple servers for sending, but don’t want to receive email at Mailgun, this is simple — just don’t configure your MX records to point to Mailgun! »
Autrement dit : si le domaine reçoit déjà son courriel ailleurs — Google Workspace, Microsoft 365, un serveur maison — il ne faut surtout pas pointer les MX vers Mailgun. Mailgun le formule ainsi : « You can only use one email server to receive messages for a given domain name. » Ajouter les MX de Mailgun sur un domaine déjà servi par Google Workspace, c’est détourner le courriel entrant de toute l’entreprise.
Le sous-domaine d’envoi
Mailgun recommande d’utiliser le domaine principal sauf s’il sert déjà au courriel de l’entreprise. Sa page « What domain name should I use with Mailgun? » donne comme réponse « mycompany.com — unless you’re already using this name for your corporate email », et propose alors « mg.mycompany.com, or mail.mycompany.com ».
La même page va plus loin : « some companies will use a different domain or subdomains for bulk marketing mailings, versus those domains used for transactional or corporate mail ». La logique est celle de la réputation. Un domaine d’envoi accumule un historique auprès des fournisseurs de messagerie. Une campagne d’infolettre qui récolte des plaintes abîme cette réputation. Si les courriels de réinitialisation de mot de passe partent du même domaine, ils tombent avec elle.
Séparer par sous-domaine — mg.exemple.com pour le transactionnel, nouvelles.exemple.com pour l’infolettre — isole les réputations. C’est aussi ce qui permet de garder les MX du domaine principal chez son fournisseur habituel tout en donnant à Mailgun un sous-domaine où recevoir, si le service de routage entrant est utilisé.
DMARC — Mailgun ne le fournit pas, Gmail l’exige
DMARC est le troisième étage. SPF autorise, DKIM signe, DMARC dit au serveur receveur quoi faire quand ça rate : ne rien faire (p=none), mettre en quarantaine (p=quarantine), ou rejeter (p=reject). Il ajoute aussi une condition d’alignement : le domaine qui apparaît dans l’en-tête From: doit correspondre à celui qui a passé SPF ou DKIM.
Mailgun ne publie pas d’enregistrement DMARC à votre place. Il se compose et s’ajoute soi-même, par-dessus SPF et DKIM.
Google est explicite sur ce qu’il attend, dans ses exigences d’expéditeur :
- Tous les expéditeurs doivent avoir SPF ou DKIM.
- Les expéditeurs en gros volume doivent avoir SPF, DKIM et DMARC.
- Le seuil du gros volume est de 5 000 messages par jour vers des comptes
Gmail, depuis le 1er février 2024.
- La politique DMARC peut être réglée à
none: Google exige que
l’enregistrement existe, pas qu’il soit sévère.
- Le domaine de l’en-tête
From:doit être aligné avec le domaine SPF ou le
domaine DKIM.
Ce que fait chacune des trois valeurs, mot pour mot
La RFC 7489 décrit les trois politiques ainsi :
| Valeur | RFC 7489 | Effet concret |
|---|---|---|
p=none | « The Domain Owner requests no specific action be taken regarding delivery of messages. » | Rien ne change à la livraison. Seuls les rapports partent. |
p=quarantine | « […] be treated by Mail Receivers as suspicious. […] this can mean « place into spam folder », « scrutinize with additional intensity », and/or « flag as suspicious ». » | Les messages qui échouent aboutissent aux indésirables. Ils existent encore. |
p=reject | « […] reject email that fails the DMARC mechanism check. Rejection SHOULD occur during the SMTP transaction. » | Les messages qui échouent sont refusés pendant la transaction SMTP. Ils n’arrivent nulle part, pas même aux indésirables. |
Source : RFC 7489, section 6.3, consultée le 21 septembre 2026.
Pourquoi on ne saute pas d’étape
Une PME envoie du courriel depuis plus d’endroits qu’elle ne le croit : Mailgun, Google Workspace, un outil de facturation, une infolettre, un formulaire de site. Chacun doit passer SPF ou DKIM avec alignement sur le domaine du From:, et il suffit qu’un seul soit oublié pour que ses messages échouent au contrôle.
À p=none, cet oubli est invisible pour les destinataires et visible dans les rapports. À p=reject, il devient un refus SMTP : les factures ne partent plus, les réinitialisations de mot de passe non plus, et rien ne tombe dans les indésirables où on pourrait les retrouver. C’est la panne que déclenche le passage direct de « aucun DMARC » à p=reject.
La progression tient en trois temps.
1. p=none avec rapports. On publie v=DMARC1; p=none; rua=mailto:dmarc@exemple.com — l’étiquette rua désigne les « addresses to which aggregate feedback is to be sent ». Rien ne change pour les destinataires ; les rapports agrégés arrivent en XML, un par fournisseur et par jour.
2. On lit les rapports jusqu’à ce que l’inventaire soit stable. Ce qu’on y cherche : toutes les adresses IP qui envoient sous le domaine, et pour chacune si SPF passe, si DKIM passe, et si le résultat est aligné avec le From:. Trois cas en sortent : les expéditeurs légitimes conformes, ceux à corriger — l’outil oublié est là — et les envois non reconnus. On ne monte pas d’un cran tant que la deuxième catégorie n’est pas vide et que la liste ne bouge plus d’une semaine à l’autre. Les campagnes saisonnières valent d’attendre de les avoir vues passer une fois.
3. p=quarantine, puis p=reject. L’étiquette pct, « percentage of messages […] to which the DMARC policy is to be applied », n’applique la politique qu’à une fraction du flux : pct=10, puis 25, 50, 100. Un expéditeur oublié coûte alors un message sur dix, pas tous. La quarantaine laisse les messages récupérables dans les indésirables ; le rejet, non. On ne passe à p=reject qu’une fois la quarantaine tenue à 100 % sans échec légitime dans les rapports.
Hébergement : États-Unis et Union européenne, aucune région canadienne
Mailgun offre deux régions d’hébergement : les États-Unis et l’Union européenne. Sa documentation parle d’ajouter des « US or EU based domains ». Aucune région canadienne — relevé le 21 septembre 2026.
Ça compte au Québec. La Loi 25 n’interdit pas l’hébergement hors du Québec : elle exige une évaluation des facteurs relatifs à la vie privée avant la communication hors Québec, et une entente écrite avec le prestataire. Or un service d’envoi traite des renseignements personnels : adresses, noms, contenu des messages, et si le suivi est activé, horodatage des ouvertures et des clics.
Le choix de région se fait à la création du domaine d’envoi. Aucune des deux options ne garde les données au Canada, et les obligations documentaires s’appliquent dans les deux cas. L’EFVP et l’entente sont traitées sur la page hébergement des données et Loi 25.
Les prix : en dollars américains seulement
Le sélecteur de devise de Mailgun offre USD, EUR et GBP. Aucun dollar canadien. Relevé au navigateur le 21 septembre 2026 sur mailgun.com/pricing/.
| Forfait | Prix mensuel | Volume inclus | Rétention des journaux |
|---|---|---|---|
| Free | 0 $ US | 100 courriels/jour | 1 jour |
| Basic | 15 $ US | 10 000/mois | 1 jour |
| Foundation | 35 $ US | 50 000/mois | 5 jours |
| Scale | 90 $ US | 100 000/mois | 30 jours |
Une PME canadienne paie donc en devise étrangère, frais de conversion en sus, et le montant en dollars canadiens dépend du taux du jour comme de la marge de l’émetteur : aucune conversion n’est faite ici.
Un point touche au sujet de cette page : le nombre de domaines d’envoi est limité à 1 sur Free et Basic, et monte à 1 000 sur Foundation et Scale. La séparation par sous-domaine décrite plus haut demande donc au minimum Foundation, à 35 $ US par mois.
Les autres exigences de Google, qu’on oublie en parlant de DNS
Publier les trois enregistrements ne suffit pas. Les exigences pour 5 000 messages par jour et plus, telles que publiées par Google, comprennent aussi :
- Un DNS inversé valide : l’adresse IP d’envoi doit avoir un enregistrement
PTR qui résout vers un nom d’hôte, et ce nom d’hôte doit résoudre vers la même adresse IP. Chez Mailgun sur IP partagée, c’est Mailgun qui s’en occupe.
- Une connexion TLS pour la transmission.
- Un taux de plainte inférieur à 0,30 %, mesuré dans Postmaster Tools de
Google.
- Un format de message conforme à la RFC 5322.
- Pour les messages marketing et les abonnements, un désabonnement en un clic
et un lien de désabonnement visible dans le corps du message.
Le taux de plainte est celui qui surprend. 0,30 %, c’est trois plaintes pour mille messages livrés. Une liste bâtie sans consentement explicite le dépasse sans effort — et au Canada, elle contrevient déjà à la LCAP.
Ce qui reste à vérifier
- Le délai de propagation réel des enregistrements chez les fournisseurs DNS
canadiens courants : à vérifier.
- Le comportement exact de Mailgun quand la clé DKIM est tronquée par un
fournisseur DNS qui limite la longueur des TXT : à vérifier.
- Les exigences équivalentes de Yahoo et de Microsoft, annoncées dans la même
période que celles de Google : à vérifier à leurs sources officielles.
- Si Mailgun publie un enregistrement DMARC recommandé par défaut : **à
vérifier** — sa documentation de vérification de domaine n’en mentionne aucun.
- Si la région (États-Unis ou Union européenne) est modifiable après la création
d’un domaine d’envoi : à vérifier.
- Si Sinch, propriétaire de Mailgun, publie une entente de traitement adaptée à
la Loi 25 : à vérifier.
Méthode
Tout a été consulté le 21 septembre 2026. Les valeurs d’enregistrement et les régions viennent de la documentation de Mailgun (documentation.mailgun.com) et de son centre d’aide (help.mailgun.com). Les définitions des politiques DMARC et des étiquettes rua et pct sont citées de la RFC 7489 (rfc-editor.org/rfc/rfc7489.txt). Les exigences d’expéditeur viennent de « Email sender guidelines » de Google (support.google.com/a/answer/81126). Les prix et les devises offertes viennent de mailgun.com/pricing/, relevés au navigateur.
Aucun compte Mailgun n’a été créé pour écrire cette page. Elle décrit ce que les éditeurs publient, pas ce qu’une configuration réelle a donné. Elle ne remplace pas la lecture du tableau de bord Mailgun, qui affiche les valeurs exactes propres à chaque domaine — en particulier la clé DKIM, qui n’est pas générique. Elle n’est pas un avis juridique et ne remplace pas un avocat.
Divulgation d’affiliation
Ce site peut toucher une commission si vous vous abonnez à un outil à partir d’un lien présent dans cette page. Ça ne change rien au prix que vous payez, et ça ne change pas ce qui est écrit ici : les faits, les prix et les limites sont relevés aux sources officielles des éditeurs, qu’un programme d’affiliation existe ou non. Au 21 septembre 2026, aucun lien de cette page n’est un lien d’affiliation : Mailgun, propriété de Sinch, ne publie aucun programme d’affiliation ni aucun taux de commission.