Mon état DNS ne devient jamais vert

La validation DNS contrôle les registres nécessaires à la configuration choisie. Un domaine qui reçoit du courrier par TrekMail a normalement besoin de MX, SPF, DKIM et DMARC. Les registres recommandés comme MTA-STS et TLS-RPT peuvent apparaître séparément. Ce guide vous aide à comparer le Tableau de bord à votre fournisseur DNS sans deviner.

Commencez par la table des registres du Tableau de bord

Ouvrez Domaines, choisissez le domaine concerné et son état DNS. Copiez dans cette table le type, l’hôte, la valeur et, pour MX, la priorité. Cette table fait foi, car les valeurs DKIM et certains registres de politique sont propres au domaine.

Avant de modifier un registre, vérifiez si un autre service a encore besoin de sa valeur. En particulier, conservez un seul SPF et tout include valide utilisé par un autre service d’envoi.

Combien de temps prend la propagation ?

Le délai d’une mise à jour DNS dépend du fournisseur, du TTL précédent et des caches des résolveurs. Un résultat en attente ne prouve pas que la valeur est fausse, et le temps écoulé ne prouve pas qu’elle est correcte.

Procédez plutôt ainsi :

1. Enregistrez le registre chez le fournisseur de la zone DNS faisant autorité.
2. Comparez-le à la table du Tableau de bord, notamment la priorité MX et toute la valeur DKIM.
3. Utilisez Vérifier le DNS une fois pour demander un nouveau contrôle TrekMail.
4. S’il reste en attente, consultez les conflits et une recherche indépendante pour voir la valeur publique actuelle.

Registres requis

Pour un hébergement de courrier normal, voici les registres essentiels. Copiez ceux de votre Tableau de bord, sans reprendre la valeur d’un autre domaine :

Les registres recommandés renforcent la sécurité de livraison, mais ne remplacent pas les registres essentiels :

Les CNAME facultatifs de configuration client (autoconfig, autodiscover) accélèrent la configuration des applications, mais n’affectent pas la livraison.

Vérification 1 : fusionnez les registres SPF en double

Un seul TXT à la racine doit commencer par v=spf1. Avec deux, les serveurs destinataires ne savent pas quelle politique utiliser et TrekMail ne peut pas valider correctement.

Symptôme : les deux registres apparaissent dans votre DNS, mais TrekMail signale toujours que SPF n’est pas configuré.

Solution : fusionnez les règles dans un seul registre. Si vous avez :

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

Remplacez-les par :

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

Quelle terminaison utiliser : -all ou ~all

N’en utilisez qu’une. -all et ~all passent tous deux le contrôle si include:spf.trekmail.net les précède. Ce choix affecte le courrier envoyé par d’autres services.

Une note de conseil sur la terminaison n’est pas un échec. Le domaine peut être validé avec l’une ou l’autre.

N’utilisez pas :

• ?all, qui ne fournit pas de politique d’autorisation utile.
• +all, qui autorise tous les expéditeurs sur Internet.

Un SPF peut effectuer au maximum dix recherches DNS. Avec de nombreux expéditeurs tiers, réduisez les include ou demandez au fournisseur concerné une consolidation prise en charge.

Vérification 2 : un CNAME de courrier Cloudflare est sous proxy

Cloudflare peut relayer le trafic web, mais un CNAME de courrier doit être en mode DNS uniquement. Cela peut concerner mta-sts, autoconfig, autodiscover ou un autre hôte demandé par le Tableau de bord.

Symptôme : le registre apparaît bloqué ou impossible à valider alors qu’il figure dans la liste DNS Cloudflare.

Solution : dans Cloudflare, ouvrez DNS, trouvez l’hôte et remplacez le nuage orange par l’état gris DNS uniquement. Utilisez ensuite Vérifier le DNS dans TrekMail.

Le registre A ou le CNAME web principal peut rester sous proxy. Ne modifiez que l’hôte de courrier désigné par le Tableau de bord.

Vérification 3 : DMARC est placé sur le mauvais hôte

DMARC doit être à _dmarc.yourdomain.com, pas à la racine. Certains formulaires préremplissent @, ce qui facilite une erreur d’emplacement.

Symptôme : le registre DMARC existe dans votre DNS, mais TrekMail ne le trouve pas.

Solution : ajoutez-le à _dmarc. Certaines interfaces attendent _dmarc, d’autres _dmarc.yourdomain.com. Consultez l’indication du formulaire. Ne supprimez un registre incorrect à @ qu’après avoir confirmé qu’il n’a pas d’autre usage.

Vérification 4 : DKIM a été mal collé ou découpé

Les valeurs DKIM sont longues. Un fournisseur peut enregistrer un TXT long en plusieurs segments liés, mais le résultat public doit toujours correspondre à toute la valeur du Tableau de bord.

"p=MIIBIjANBgkqhki..." "...continues here" "...and ends here"

La plupart le font automatiquement. Un mauvais collage peut ajouter ou retirer caractères, espaces ou guillemets.

Symptôme : DKIM est visible dans le DNS, mais TrekMail indique "DKIM key invalid" ou "p= does not match".

Solution :

• Collez exactement la valeur du Tableau de bord.
• Si le fournisseur découpe automatiquement les TXT longs, collez toute la valeur et laissez-le faire.
• S’il demande des segments, suivez ses instructions et conservez chaque caractère de la valeur.
• Utilisez une recherche DNS indépendante pour confirmer que le TXT public contient la clé complète.

Vérification 5 : MTA-STS exige votre attention

MTA-STS est une fonction recommandée de sécurité pour les domaines qui reçoivent du courrier par TrekMail. Si le Tableau de bord l’affiche, il faut le TXT et le CNAME mta-sts indiqués. Ne les ajoutez pas à un domaine réservé à l’envoi sauf demande explicite du Tableau de bord.

Bloqué par DNS. Le CNAME mta-sts manque ou pointe ailleurs. Ajoutez-le ou corrigez-le avec la cible actuelle du Tableau de bord.

Bloqué par Cloudflare. Le CNAME existe, mais est sous proxy. Mettez cet hôte en DNS uniquement, comme à la Vérification 2.

Dégradé après avoir fonctionné. Comparez TXT et CNAME au Tableau de bord. Un registre modifié ou supprimé est généralement en cause. Restaurez la valeur, exécutez Vérifier le DNS et consultez le nouvel état.

Vérification 6 : comparez une recherche publique au Tableau de bord

Votre réseau local et TrekMail peuvent voir des résultats différents pendant la propagation. Une recherche publique montre ce que voient d’autres réseaux.

Pour comparer :

1. Ouvrez dnschecker.org ou whatsmydns.net.
2. Saisissez l’hôte complet et le type. Par exemple, _dmarc.yourdomain.com et TXT pour DMARC.
3. Comparez l’hôte, la valeur et la priorité MX renvoyés à la table du Tableau de bord.
4. Si la recherche est correcte mais TrekMail signale toujours une différence, joignez ce résultat au ticket.

Vérification 7 : une ancienne valeur DNS est encore en cache

Après une modification, l’ancienne valeur peut rester dans les résolveurs intermédiaires jusqu’à son TTL (Time To Live, en secondes). Un TTL de 24 heures (86400 secondes) est courant pour les anciens registres.

Symptôme : vous avez modifié un registre il y a une heure, mais les outils voient toujours l’ancienne valeur partout.

Solution : évitez les modifications répétées pendant la propagation du même changement. Pour une migration prévue, réduisez le TTL à l’avance si le fournisseur le permet. Une fois stable, choisissez un TTL adapté à votre gestion habituelle.

Dépannage pas à pas

1. Ouvrez la page Domaines et cliquez sur votre domaine.
2. Si Voir les conflits est disponible, ouvrez-le. Il sépare les registres à corriger des éléments recommandés et informatifs.
3. Comparez chaque hôte, valeur et priorité MX attendus au registre enregistré chez le fournisseur.
4. Effectuez le changement minimal nécessaire et conservez les registres requis par d’autres services.
5. Cliquez sur Vérifier le DNS dans TrekMail.
6. Lisez le nouvel état. Le domaine est actif lorsque les registres requis pour sa configuration sont valides; les registres recommandés peuvent être indiqués séparément.

Pour vérifier vous-même depuis un terminal (Mac/Linux/WSL), utilisez :

dig +short MX yourdomain.com
dig +short TXT yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short TXT dkim._domainkey.yourdomain.com
dig +short CNAME mta-sts.yourdomain.com

Comparez la sortie aux valeurs de votre propre domaine dans le Tableau de bord. Ne copiez jamais depuis un exemple une clé DKIM, un ID de politique MTA-STS ou une autre valeur propre au domaine.

Pièges courants des fournisseurs DNS

• Cloudflare : les CNAME de courrier doivent être en DNS uniquement. Le fournisseur peut masquer le point final d’une cible; comparez la cible résolue au lieu d’ajouter des points en double.
• GoDaddy : utilisez @ pour la racine et _dmarc pour l’hôte DMARC. GoDaddy ajoute lui-même le nom du domaine.
• Namecheap : ajoutez les registres dans Advanced DNS uniquement si Namecheap est le DNS faisant autorité. Utilisez @ pour la racine.
• Route 53 : sélectionnez la zone hébergée réellement reliée au domaine, puis collez toute la valeur du Tableau de bord.
• Créateurs de sites et bureaux d’enregistrement : le vendeur du domaine ne contrôle pas forcément son DNS. Vérifiez les serveurs de noms et modifiez les registres chez le fournisseur qui les contrôle.

Quand tout concorde mais reste rouge

Si le Tableau de bord et une recherche publique indépendante montrent les mêmes registres requis, mais TrekMail signale toujours une différence, ouvrez un ticket avec :

• Le nom de votre domaine.
• Le résultat public du registre concerné.
• Une capture du panneau Voir les conflits, s’il est disponible.

N’incluez ni mots de passe de compte ou de boîte, ni codes de récupération, ni jetons d’accès.

Articles connexes

• Registres DNS requis (MX, SPF, DKIM, DMARC)
• Vérifier l’état DNS et valider un domaine
• Configuration DNS avec les fournisseurs courants
• Vous ne recevez pas d’e-mails ?
• Configuration DNS automatique Cloudflare