GoDaddy : publier SPF, DKIM et DMARC dans la zone DNS

Type : TXT
Host : @
Valeur : v=spf1 include:_spf.google.com ~all

Publier les enregistrements DKIM

DKIM se publie sous un sélecteur fourni par le service d'envoi. La forme de l'enregistrement dépend du fournisseur : certains donnent un CNAME (délégation), d'autres une clé publique en TXT. Dans les deux cas, le champ Host reçoit le sélecteur sans le domaine :

Type : CNAME
Host : sel._domainkey
Valeur : sel.dkim.fournisseur.exemple.

Les valeurs DKIM en TXT sont longues (une clé 2048 bits). GoDaddy accepte ces valeurs longues dans son interface ; historiquement, certaines zones imposaient un découpage en segments de 255 caractères, mais la saisie via l'interface le gère aujourd'hui. Il faut coller la valeur exactement, sans espace ni retour à la ligne parasite — une clé DKIM tronquée ou altérée ne se vérifie pas, et le symptôme (DKIM absent des rapports) est le même qu'une clé non publiée.

Publier l'enregistrement DMARC

L'enregistrement DMARC est un TXT sous le sous-domaine _dmarc :

Type : TXT
Host : _dmarc
Valeur : v=DMARC1; p=none; rua=mailto:rapports@exemple.fr

GoDaddy ne propose pas d'assistant DMARC dédié : contrairement à certains enregistrements de messagerie qu'un menu peut pré-remplir, l'enregistrement _dmarc s'ajoute toujours à la main, comme un TXT ordinaire. Ce n'est pas un manque — un enregistrement DMARC se résume à sa valeur — mais cela explique qu'on ne le trouve pas sous un bouton « activer DMARC » : il faut le composer soi-même.

On commence toujours en p=none : la politique n'impose rien, mais l'adresse rua= déclenche l'envoi des rapports agrégés, qui vont servir à tout vérifier avant de durcir. Les enregistrements décortiqués ligne à ligne détaillent les balises disponibles (sp, adkim, aspf, pct supprimée sous DMARCbis) et les valeurs à retenir selon le contexte. Sous DMARCbis, le rattachement des sous-domaines se détermine par le DNS Tree Walk, sans changer la façon de publier l'enregistrement chez GoDaddy.

Le cas de l'e-mail vendu par GoDaddy

GoDaddy ne fait pas qu'héberger le DNS : il revend aussi des offres de messagerie, et c'est une source de confusion. Deux produits coexistent : l'ancien « Workspace Email » (héritage GoDaddy, dont l'include SPF est include:secureserver.net) et Microsoft 365 revendu par GoDaddy (dont l'include est include:spf.protection.outlook.com). Un domaine dont le courrier part de l'un de ces produits doit utiliser l'include correspondant — et non l'autre.

Le piège classique : un domaine migré de Workspace Email vers Microsoft 365 qui garde l'ancien include:secureserver.net dans son SPF. L'include ne correspond plus au service émetteur réel, et SPF échoue. Vérifier quel produit de messagerie est effectivement actif — et aligner l'include dessus — fait partie de la remise à plat d'un domaine hébergé chez GoDaddy.

Vérifier que la zone est bien gérée par GoDaddy

Avant de saisir quoi que ce soit, un contrôle évite l'erreur la plus frustrante : s'assurer que la zone DNS du domaine est réellement gérée par GoDaddy. Un domaine peut être enregistré chez GoDaddy mais avoir ses serveurs de noms (NS) délégués ailleurs — un autre hébergeur, un fournisseur d'infrastructure, un CDN. Dans ce cas, l'interface DNS de GoDaddy affiche bien une zone, mais ce n'est plus elle qui fait autorité : les enregistrements qu'on y ajoute ne sont jamais servis, et le domaine reste sans protection malgré des heures passées dans la bonne interface — au mauvais endroit.

Le contrôle est rapide : les serveurs de noms effectifs du domaine se lisent dans une requête NS. S'ils pointent vers GoDaddy (ns*.domaincontrol.com), la zone GoDaddy fait autorité et les enregistrements y comptent. S'ils pointent ailleurs, c'est dans cette autre interface qu'il faut publier SPF, DKIM et DMARC. Cette vérification préalable est le premier réflexe de tout diagnostic « j'ai publié DMARC mais rien n'arrive ».

Propagation et TTL

Une modification de zone chez GoDaddy n'est pas instantanée pour le reste du monde. Chaque enregistrement porte un TTL (durée de vie) qui indique combien de temps les résolveurs peuvent garder l'ancienne valeur en cache. GoDaddy applique par défaut un TTL d'une heure : après une modification, il faut donc parfois attendre jusqu'à ce délai avant que les serveurs destinataires voient la nouvelle valeur.

Deux conséquences pratiques. D'abord, ne pas conclure trop vite qu'un enregistrement « ne marche pas » quelques minutes après l'avoir posé : la propagation peut ne pas être achevée, et un premier contrôle négatif n'est pas un verdict. Ensuite, avant une modification sensible — une rotation de clé DKIM, un changement de politique —, abaisser le TTL à l'avance (par exemple à cinq minutes) réduit la fenêtre pendant laquelle l'ancienne et la nouvelle valeur coexistent dans les caches. Une fois le changement stabilisé et vérifié, on peut remonter le TTL à sa valeur habituelle.

Les erreurs de saisie courantes

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

Saisir le domaine complet dans le champ Host. Le piège numéro un, décrit plus haut : _dmarc.exemple.fr au lieu de _dmarc crée un enregistrement au nom décalé, introuvable.

Publier deux enregistrements SPF. GoDaddy laisse créer un second TXT v=spf1 ; deux enregistrements SPF invalident SPF entièrement. Il faut fusionner les include dans un seul.

Coller une clé DKIM tronquée. Une valeur incomplète ou avec un espace parasite ne se vérifie pas ; le symptôme trompe, car l'enregistrement existe mais est invalide.

Durcir la politique trop tôt. Passer à p=reject avant d'avoir confirmé par les rapports que tout le trafic légitime s'aligne revient à rejeter ses propres messages — l'ordre p=none puis observation puis durcissement n'a rien de spécifique à GoDaddy, mais reste la seule séquence sûre.

La contre-épreuve : les rapports RUA

La seule preuve qu'une configuration tient n'est pas l'écran GoDaddy, 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 d'abord que l'enregistrement est bien lu — s'il a été mal nommé (le piège du champ Host), aucun rapport n'arrive, ce qui est en soi un signal.

Une cadence simple suffit : une première lecture quelques jours après la publication, une fois que plusieurs destinataires ont rapporté, puis un coup d'œil hebdomadaire tant que la politique reste en p=none. On vérifie que chaque source légitime — la messagerie, l'ESP, les applications — s'aligne, puis seulement on durcit. Une fois cette couverture confirmée sur plusieurs jours, 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.