Comment surveiller vos records SPF, DKIM et DMARC

SPF, DKIM et DMARC sont des records TXT placés à trois emplacements précis de votre zone DNS. Les surveiller revient à surveiller ces trois emplacements et à recevoir une alerte quand leur contenu change. Pourquoi s'en donner la peine : un record cassé n'empêche pas vos emails de partir. Ils quittent toujours votre serveur, ils arrivent simplement en spam ou sont rejetés, et on s'en aperçoit des jours plus tard, quand un client signale une facture jamais reçue ou que les taux d'ouverture s'effondrent. Cet article cartographie l'emplacement de chaque record, passe en revue les opérations banales qui les cassent, puis montre comment poser une alerte sur les trois.

Où vivent SPF, DKIM et DMARC dans votre DNS

Mécanisme	Emplacement DNS	À quoi ressemble le record
SPF	TXT sur l'apex (example.com)	v=spf1 include:_spf.google.com ~all
DMARC	TXT sur _dmarc.example.com	v=DMARC1; p=quarantine; rua=mailto:reports@example.com
DKIM	TXT sur <selecteur>._domainkey.example.com	v=DKIM1; k=rsa; p=MIGfMA0GCSq...

Le sélecteur DKIM est choisi par votre fournisseur email, pas par vous. Google Workspace utilise google, Microsoft 365 utilise selector1 et selector2, et chaque outil d'envoi (Mailchimp, SendGrid, Brevo) apporte le sien. Un domaine qui envoie via trois outils publie donc souvent trois sélecteurs DKIM ou plus, et certains fournisseurs passent par une délégation CNAME plutôt que par un TXT direct. Pour une piqûre de rappel sur les records TXT en général, voir les types de records DNS expliqués.

Comment ces records se cassent en pratique

Aucun des scénarios ci-dessous n'implique un attaquant. Ce sont des opérations de routine, faites par des gens bien intentionnés.

L'écrasement du SPF

Un domaine n'a droit qu'à un seul record SPF. C'est la cause numéro un de casse : un collègue ajoute un CRM ou un outil de newsletter, suit le guide d'installation du fournisseur, et colle le record SPF du fournisseur dans le DNS, en nouvelle entrée ou à la place de l'existant. Dans les deux cas, la fusion qui aurait dû avoir lieu n'a pas eu lieu, et tous les autres expéditeurs du domaine échouent désormais au contrôle SPF.

Le second piège du SPF, c'est la limite des 10 lookups DNS. Chaque include: consomme des lookups, et les includes imbriqués comptent aussi. Ajoutez assez d'outils et le record dépasse la limite : les serveurs destinataires le traitent alors comme une erreur permanente, même si chaque entrée est légitime.

La rotation de clé DKIM

Les fournisseurs email font tourner leurs clés de signature. Quand cela arrive, un ancien sélecteur cesse de valider, ou un nouveau sélecteur apparaît sans que personne ne l'ait publié dans le DNS. La variante la plus douloureuse est le nettoyage de CNAME : beaucoup de fournisseurs délèguent le DKIM via des records CNAME pointant vers leur propre zone, et un passage bien intentionné de "suppression des records inutilisés" efface la délégation. La signature échoue à partir de ce moment, sans bruit.

La migration DNS qui perd les TXT

Quand un domaine change de fournisseur DNS, les records visibles voyagent bien. Les A, MX et CNAME sont recopiés, parce que le site et la boîte mail casseraient bruyamment sans eux. Les records préfixés d'un underscore, _dmarc et tout ce qui vit sous _domainkey, sont les plus souvent oubliés, justement parce que rien ne casse visiblement quand ils manquent.

Ce qu'une politique DMARC stricte amplifie

Un DMARC en p=none se contente d'observer. Avec p=quarantine ou p=reject, les destinataires agissent sur les échecs : vos propres emails légitimes partent en indésirable ou sont refusés dès que SPF et DKIM échouent tous les deux à l'alignement. C'est le but du mécanisme, puisque c'est ce qui bloque les emails de phishing envoyés en votre nom. Mais l'arme est à double tranchant : une politique durcie transforme un écrasement de SPF discret en panne de délivrabilité immédiate.

Depuis 2024, Gmail et Yahoo exigent un record DMARC des expéditeurs en volume. Si cette exigence vous a poussé à en publier un, l'ordre prudent est le suivant : surveillance d'abord, durcissement ensuite.

Mettre les trois sous surveillance avec Domain Sentinel

Voici le flux réel avec la surveillance DNS de Domain Sentinel. Ajoutez votre domaine à la watchlist et activez la surveillance DNS. Les contrôles par défaut couvrent les records TXT de l'apex : votre SPF est donc surveillé sans réglage supplémentaire. Pour les deux autres emplacements, ajoutez les hostnames dans Extra names : _dmarc, plus chaque sélecteur DKIM que vous utilisez, par exemple google._domainkey ou selector1._domainkey. Un domaine accepte dix noms supplémentaires, de quoi couvrir quelques outils d'envoi.

Une précision honnête : Domain Sentinel ne découvre pas vos sélecteurs DKIM à votre place. Il faut savoir quels sélecteurs vos fournisseurs utilisent, et la liste se trouve dans les réglages d'authentification de chacun. Prenez cinq minutes pour la constituer avant de poser la surveillance.

Les records sont contrôlés une fois par jour. Quand un TXT surveillé change, vous recevez un email avec la valeur d'avant et celle d'après : un écrasement de SPF ou un _dmarc disparu remonte le lendemain, pas des semaines plus tard. Domain Sentinel détecte les changements ; il n'évalue pas si votre syntaxe SPF ou votre politique DMARC est correcte. Pour cette validation ponctuelle, utilisez un vérificateur dédié, puis laissez la surveillance garder le résultat. La place de tout cela dans la surveillance d'un domaine au sens large est traitée dans qu'est-ce que la surveillance DNS.

Vérifier l'état actuel

Avant de configurer quoi que ce soit, regardez ce qui est publié aujourd'hui :

dig TXT example.com
dig TXT _dmarc.example.com
dig TXT google._domainkey.example.com

Remplacez par votre domaine et vos sélecteurs. Pas de terminal sous la main ? L'outil de lookup DNS accepte un nom d'hôte : vous pouvez lire _dmarc et chacun de vos sélecteurs DKIM depuis le navigateur.

Trois gestes concrets pour cette semaine : inventorier chaque outil qui envoie des emails pour votre domaine et noter son sélecteur DKIM, lancer les trois requêtes ci-dessus et corriger ce qui manque, puis placer les trois emplacements sous surveillance. Ce n'est qu'après cela qu'il faut envisager de passer DMARC de p=none à une politique plus stricte.