Configurer automatiquement le DNS du mail : un clic ou un jeton pour vos domaines

La configuration DNS du courrier électronique demande six ou sept enregistrements. Plusieurs contiennent de longues chaînes où un seul caractère erroné provoque un échec difficile à rapprocher d'une faute de frappe. Une clé DKIM représente quelques centaines de caractères en base64. Un enregistrement SPF contient des mécanismes dont l'ordre compte et une terminaison qui modifie le sens de la politique. DMARC utilise un nom de sous-domaine facile à mal saisir.

Pour un seul domaine, vous avez de bonnes chances de réussir. Sur quarante domaines clients, le risque d'erreur augmente. Vous pourriez ne la découvrir qu'un mois plus tard, lorsqu'une facture arrive dans les indésirables.

La configuration automatique évite de recopier les valeurs. Deux parcours sont proposés : autoriser une modification chez le fournisseur pour un domaine, puis revenir dans TrekMail sans fournir de jeton, ou utiliser un jeton d'API aux permissions limitées pour gérer une centaine de domaines en plusieurs lots. Dans les deux cas, vous pouvez examiner les modifications avant de les appliquer.

Ce que le mail demande réellement dans le DNS

« Nécessaire dans de nombreux contextes » ne signifie pas que les RFC imposent DKIM et DMARC à tous les domaines. Google et Yahoo ont introduit des exigences pour les expéditeurs en masse en 2024 ; leur application dépend de la catégorie d'expéditeur et des règles en vigueur. Les destinataires professionnels peuvent aussi avoir leurs propres exigences. L'absence de ces enregistrements n'interdit pas automatiquement tout envoi, mais elle peut compliquer l'authentification et l'acceptation des messages.

Quatre erreurs fréquentes dans une configuration DNS manuelle

Publier deux enregistrements SPF. C'est une erreur fréquente, aux conséquences importantes. Le nom évalué ne doit publier qu'un seul enregistrement SPF. En ajouter un deuxième pour un nouveau service n'étend pas la politique : une évaluation conforme au protocole renvoie permerror. Il faut réunir les mécanismes dans un seul enregistrement. Consultez les exemples d'enregistrements SPF.

Abîmer une clé DKIM en la collant. La représentation d'une clé de 2048 bits dépasse la limite de 255 caractères par chaîne TXT. L'enregistrement doit donc contenir plusieurs chaînes, concaténées à la lecture. Certains panneaux DNS s'en chargent automatiquement ; d'autres demandent de préparer le découpage, et certains peuvent tronquer la valeur. Une clé incomplète empêche la vérification de la signature sans que la cause saute aux yeux.

Publier DMARC au mauvais endroit. Son nom est _dmarc.example.com. Si vous le placez à la racine, les destinataires ne le trouveront pas lors de la recherche de la politique DMARC du domaine.

Dépasser la limite de recherches SPF. SPF limite à dix les termes qui déclenchent des recherches DNS pendant l'évaluation. Chaque include: évalué compte, y compris dans les inclusions imbriquées. Un hébergeur mail, un CRM, un outil marketing et un service d'assistance peuvent vous faire dépasser cette limite, selon leurs politiques. Le résultat devient alors permerror. Le problème peut apparaître des mois après la mise en place, à l'ajout d'un outil supplémentaire. Voir la limite de recherches DNS de SPF.

L'automatisation réduit les erreurs de copie et repère les conflits, mais ne dispense pas de vérifier le résultat. Fusionner SPF évite d'ajouter un deuxième enregistrement ; cela ne prouve pas que la politique respecte la limite d'évaluation.

Parcours 1 : configurer le DNS en un clic, sans jeton

Pour un domaine dont Cloudflare héberge le DNS, c'est le parcours le plus direct. Vous ne transmettez ni jeton ni identifiants de compte à TrekMail.

1. Ouvrez l'onglet DNS et état du domaine.
2. Cliquez sur Configurer le DNS automatiquement.
3. Cloudflare affiche les enregistrements proposés avant que vous n'autorisiez l'opération.
4. Cliquez sur Autoriser.
5. Vous revenez dans TrekMail et une vérification est demandée. Ce retour ne prouve pas à lui seul que les enregistrements ont été correctement publiés.

Ce parcours utilise Domain Connect, un protocole ouvert conçu pour cet échange : le service décrit les enregistrements nécessaires, le fournisseur DNS présente les modifications au propriétaire et celui-ci les approuve. Aucun jeton d'API réutilisable n'est créé ni conservé. L'autorisation concerne l'opération proposée pour ce domaine.

Les serveurs de noms du domaine doivent pointer vers Cloudflare. Si le domaine est enregistré chez Cloudflare mais que son DNS est hébergé ailleurs, ce parcours n'est pas disponible : les modifications doivent être effectuées chez le fournisseur qui héberge réellement la zone.

Parcours 2 : configurer le DNS avec un jeton d'API limité

Pour plusieurs domaines, ou lorsque Domain Connect n'est pas disponible, un jeton permet de configurer les zones autorisées du compte.

Dans Cloudflare, créez le jeton à partir du modèle Edit zone DNS, avec la permission Zone → DNS → Edit. Dans les ressources de zone, choisissez All zones pour toutes les zones ou Specific zone pour limiter l'accès. Vérifiez que les restrictions d'adresse IP et la durée de validité permettent l'utilisation prévue ; il n'est pas nécessaire de les modifier sans raison. Copiez le jeton lorsqu'il est affiché, puis collez-le dans TrekMail.

L'essentiel est de comprendre ce que ces permissions autorisent et ce qu'elles excluent :

TrekMail conserve le jeton chiffré et évite d'en inscrire la valeur dans les journaux. Vous pouvez le déconnecter d'un domaine dans TrekMail ou le révoquer dans Cloudflare pour empêcher de nouvelles requêtes avec ce jeton. Déconnecter un domaine ne révoque pas nécessairement un jeton partagé avec d'autres, et une révocation n'annule pas les modifications déjà effectuées.

Une fois la connexion établie, les zones Cloudflare disponibles apparaissent avec l'action prévue : Configurer le DNS pour un domaine déjà présent dans votre compte TrekMail, ou Ajouter + DNS pour l'ajouter et le configurer dans le même parcours. Les domaines dont le DNS est ailleurs ne sont pas proposés comme zones configurables par cette intégration.

L'aperçu et ses cinq états

Avant d'appliquer la configuration, vous pouvez examiner chaque enregistrement. L'aperçu utilise cinq états :

Chaque enregistrement possède une case à cocher. Vous pouvez appliquer MX et SPF maintenant, puis revenir sur DKIM plus tard, ou exclure un enregistrement géré par un autre moyen. Les enregistrements décochés ne sont pas appliqués dans cette opération.

Prenez le temps de lire les conflits. Une politique DMARC p=none n'est pas incorrecte : elle peut correspondre à une phase d'observation volontaire. La remplacer par p=quarantine avant d'examiner les rapports peut pénaliser des messages légitimes qui ne s'authentifient pas encore correctement. Conservez-la si nécessaire, terminez le déploiement, puis renforcez la politique. Voir comment choisir une politique DMARC.

Pourquoi fusionner le SPF existant

SPF mérite une attention particulière : une seule politique peut autoriser plusieurs services. Remplacer l'enregistrement sans examiner ces services risque de retirer des autorisations encore nécessaires.

Si votre domaine publie déjà :

v=spf1 include:_spf.google.com ~all

la politique autorise l'infrastructure de Google, par exemple Workspace ou un outil qui envoie par son intermédiaire. La remplacer par un enregistrement qui n'inclut que TrekMail ne fait pas qu'ajouter un expéditeur : cela retire l'autorisation précédente. Les envois qui en dépendaient peuvent alors échouer à la vérification SPF.

Un enregistrement SPF existant et valide est donc normalement fusionné :

v=spf1 include:_spf.trekmail.net include:_spf.google.com ~all

Les deux services restent autorisés dans un seul enregistrement, avec le qualificatif final conservé. Cette transformation permet d'ajouter TrekMail sans retirer l'autorisation précédente. Ce n'est pas une règle de remplacement interdit : les SPF mal formés ou dupliqués peuvent nécessiter la résolution d'un conflit, et la politique finale doit être vérifiée.

Surveillez ensuite deux points. Le nouvel include: compte dans la limite de dix termes nécessitant des recherches DNS et peut entraîner des inclusions imbriquées : évaluez la politique complète. Si l'ancien fournisseur n'envoie réellement plus pour votre domaine, retirez son autorisation manuellement après l'avoir confirmé. Une période sans activité ne suffit pas à prouver qu'il n'est plus utilisé.

Configurer le DNS par lots

Avec un jeton autorisé pour toutes les zones, l'assistant peut parcourir les domaines compatibles, ajouter les nouveaux, configurer leurs enregistrements et présenter un résultat par domaine. Le maximum est de 50 domaines par lot. Les nouveaux domaines comptent dans la limite de l'offre : 10 pour Nano, 50 pour Starter, 100 pour Pro et 1,000 pour Agency, selon la configuration décrite dans l'article original. Vérifiez les limites actuelles de votre compte avant de commencer.

Pour une agence qui accueille un client avec une douzaine de domaines, le traitement par lots peut éviter beaucoup de travail manuel. Il rend aussi l'aperçu plus important. Imaginez douze domaines, dont deux avec une politique DMARC en conflit et un avec un CNAME autodiscover pointant encore vers un fournisseur quitté en 2023. C'est un exemple de situation à rechercher, pas une fréquence garantie.

Le périmètre des modifications

C'est une question légitime avant de donner à une application le droit de modifier votre DNS.

L'intégration est conçue pour gérer les enregistrements de messagerie : MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT et les CNAME d'autoconfiguration. Elle n'est pas censée modifier les enregistrements A, les CNAME du site web ni les TXT d'autres services. Toutefois, la permission DNS du jeton autorise l'édition des enregistrements des zones sélectionnées, pas seulement ceux du mail. La préservation des autres enregistrements dépend donc aussi du comportement de l'application. Cette permission ne permet pas de changer les serveurs de noms.

Remplacer un enregistrement en conflit peut supprimer une configuration antérieure, d'où la demande de confirmation. Examinez également les modifications et les éventuels doublons supprimés dans le cadre d'une action : les autres opérations ne sont pas nécessairement sans conséquences. Gardez une copie des valeurs précédentes si vous devez pouvoir les restaurer.

Un état en attente peut venir des caches DNS, mais aussi d'une valeur incorrecte ou d'une opération inachevée. L'article original évoque jusqu'à 48 heures ; ce n'est pas un délai universel, car le TTL et les conditions du fournisseur comptent. La vérification est relancée automatiquement et Vérifier le DNS demande un nouveau contrôle. Si l'échec persiste le lendemain, examinez les valeurs publiées et consultez le dépannage DKIM lorsque le problème concerne cette signature.

Questions fréquentes

Faut-il un compte Cloudflare pour configurer le DNS en un clic ?

Cloudflare doit héberger le DNS de votre domaine, et vous devez pouvoir accéder au compte correspondant pour autoriser le changement. Vous n'avez pas à fournir un jeton d'API à TrekMail : vous approuvez l'opération dans l'interface de Cloudflare et aucun jeton réutilisable n'est conservé.

Et si mon DNS n'est pas chez Cloudflare ?

Cette intégration automatique ne configure pas cet autre fournisseur. Il faut créer les enregistrements manuellement. La page DNS du domaine affiche les valeurs avec des boutons de copie ; des procédures par fournisseur sont disponibles dans la configuration DNS chez les fournisseurs courants.

La configuration automatique peut-elle affecter mon site web ?

L'intégration est conçue pour modifier les enregistrements mail et préserver les enregistrements A, les CNAME du site et les TXT sans rapport avec la messagerie. Cela ne signifie pas que le jeton est incapable de les modifier : ses permissions couvrent les enregistrements DNS des zones autorisées. Examinez les changements proposés. La permission décrite n'autorise pas la modification des serveurs de noms.

Que devient mon enregistrement SPF existant ?

Il est normalement fusionné : l'include de TrekMail est ajouté et le qualificatif est conservé. Les autres services autorisés ne sont donc pas retirés par inadvertance. Des SPF dupliqués ou mal formés peuvent exiger un remplacement confirmé ; vérifiez aussi la limite de recherches de la politique finale.

Puis-je appliquer seulement certains enregistrements ?

Oui. Chaque enregistrement a une case à cocher dans l'aperçu. Décochez ceux que vous gérez par un autre moyen pour les exclure de cette opération.

Combien de domaines une exécution peut-elle traiter ?

Jusqu'à 50 par lot, dans la limite totale de domaines de votre offre. Les nouveaux domaines ajoutés par l'assistant comptent dans cette limite.

Mon jeton d'API est-il protégé ?

TrekMail le conserve chiffré et évite de journaliser sa valeur. Avec les permissions décrites, il peut modifier le DNS des zones sélectionnées, mais pas la facturation, le WAF, les serveurs de noms ni les transferts de domaines. Révoquez-le dans Cloudflare pour empêcher de nouvelles requêtes ; cela n'annule pas les modifications précédentes. Limitez les zones autorisées à celles dont vous avez besoin.

Pourquoi un enregistrement que je n'ai jamais créé est-il « déjà configuré » ?

Un fournisseur précédent a pu le créer, ou une configuration autorisée a déjà été effectuée. Comparez la valeur publiée à celle proposée. Si elles correspondent, il n'est pas nécessaire de remplacer l'enregistrement, mais vérifiez qu'il reste adapté à votre configuration.