Une plateforme d’e-mailing demande d’ajouter plusieurs lignes dans les DNS. Le logiciel de facturation fournit une autre consigne, et votre messagerie possède déjà un enregistrement SPF. Recopier chaque recommandation séparément peut produire une configuration incohérente. Avant de modifier le domaine, il faut identifier tous les services qui envoient des messages en son nom.
SPF, DKIM et DMARC remplissent des fonctions complémentaires. Ils contribuent à l’authentification des messages et à la lutte contre certaines usurpations de domaine. Ils ne garantissent ni qu’un message est bienveillant, ni son arrivée en boîte de réception. Un compte autorisé mais compromis peut encore envoyer un message dangereux.
Trois contrôles, trois objets différents
SPF permet à un domaine de déclarer quels serveurs sont autorisés à émettre en utilisant certaines identités SMTP. DKIM associe une signature cryptographique au message, sous la responsabilité d’un domaine signataire. DMARC relie les résultats d’authentification au domaine de l’adresse d’expéditeur visible dans l’en-tête From.
| Mécanisme | Ce qui est vérifié | Limite importante |
|---|---|---|
| SPF | Autorisation de l’adresse IP pour le domaine SMTP évalué | Ne valide pas à lui seul l’adresse From affichée |
| DKIM | Signature et intégrité des parties signées du message | Le domaine signataire peut différer de celui du From |
| DMARC | Réussite et alignement SPF ou DKIM avec le domaine auteur | N’établit pas que le contenu est honnête |
En octobre 2026, la référence DMARC récente est la RFC 9989, publiée en mai 2026, qui remplace les RFC 7489 et 9091. Beaucoup de documentations et configurations évoquent encore l’ancien texte. Cette transition impose de vérifier la compatibilité des outils utilisés, particulièrement pour les options avancées, sans supposer qu’un paramètre historique est interprété partout de façon identique.
SPF examine l’enveloppe, pas simplement le nom affiché
Un message possède une enveloppe SMTP utilisée pour son acheminement et des en-têtes présentés au lecteur. SPF évalue notamment le domaine du MAIL FROM, souvent visible après livraison à travers le Return-Path. Le domaine HELO intervient aussi selon le contrôle effectué, notamment lorsque l’expéditeur d’enveloppe est vide.
Le destinataire consulte le DNS du domaine concerné et compare l’adresse IP qui lui parle aux règles publiées. Un résultat SPF réussi indique que cette IP est autorisée pour cette identité. Il ne prouve pas que le domaine du From visible est le même. C’est précisément l’un des problèmes auxquels répond l’alignement DMARC.
Pour un même nom de domaine évalué, on ne crée pas plusieurs enregistrements SPF concurrents commençant par v=spf1. La RFC 7208 prévoit une erreur permanente lorsqu’il en existe plusieurs applicables. Les autorisations des différents services doivent être intégrées dans une politique cohérente, par une personne qui connaît l’existant.
SPF limite également à dix les termes provoquant certaines recherches DNS pendant l’évaluation, y compris leurs dépendances. Il ne s’agit pas simplement de compter les include visibles au premier niveau. Empiler des fournisseurs peut dépasser cette limite. Remplacer les mécanismes par une liste d’IP copiée à la main peut, de son côté, devenir faux dès que le prestataire modifie son infrastructure.
DKIM dépend d’une clé et des parties réellement signées
Le serveur émetteur signe le message avec une clé privée. Le destinataire récupère la clé publique à l’emplacement DNS indiqué par un sélecteur et un domaine signataire. Dans l’en-tête DKIM-Signature, les paramètres s= et d= permettent notamment de retrouver ces éléments.
Plusieurs sélecteurs peuvent coexister pour un même domaine : c’est utile pour différents services ou une rotation de clés. Le fournisseur peut demander un enregistrement TXT ou une délégation au moyen d’un CNAME selon son fonctionnement. La valeur doit provenir de son administration officielle ; une ancienne consigne destinée à un autre compte ne suffit pas.
DKIM ne chiffre pas le courrier.
La signature permet de vérifier les éléments couverts, selon les règles de canonicalisation et la configuration. Elle n’atteste pas l’identité civile de l’auteur. Une modification de parties signées peut la casser ; une partie non couverte n’offre pas la même garantie.
Conservez les anciennes clés publiques assez longtemps lors d’une rotation pour permettre la vérification des messages déjà émis, suivant la procédure du fournisseur. La suppression immédiate d’un sélecteur peut rendre invérifiables des messages encore en transit. La clé privée, elle, doit rester protégée et n’a rien à faire dans une zone DNS publique.
DMARC exige au moins une réussite alignée
Pour passer DMARC, un message doit disposer d’au moins un mécanisme réussi et aligné : SPF ou DKIM. Il n’est pas nécessaire que les deux réussissent pour ce verdict, même si leur bonne configuration conjointe apporte de la robustesse et peut être requise par certains destinataires.
Exemple fictif : le From utilise exemple.fr. La plateforme signe avec son propre domaine fournisseur.invalid et obtient DKIM pass. Si SPF réussit également pour un domaine d’enveloppe sans relation avec exemple.fr, ces deux réussites peuvent néanmoins ne pas suffire à DMARC : aucune identité authentifiée n’est alignée avec le domaine auteur.
En mode strict, l’alignement demande une correspondance exacte des domaines concernés. En mode relâché, il s’appuie sur leur domaine organisationnel, selon la découverte définie par la norme applicable. Un sous-domaine peut donc être aligné sans être textuellement identique. Les structures complexes et les domaines délégués justifient une vérification attentive par l’administrateur.
Le domaine publie aussi une préférence de traitement des messages qui échouent : surveillance avec none, mise en quarantaine ou rejet. Le destinataire conserve ses propres politiques et décisions. p=none n’interdit pas le filtrage, et une politique de rejet n’est pas une garantie absolue que tous les destinataires bloqueront chaque message concerné.
L’inventaire évite de bloquer ses propres courriers
Recensez la messagerie habituelle, l’e-mailing, la facturation, le CRM, le support, les formulaires du site, les scanners et les applications métiers. Pour chaque flux, notez le domaine From, le domaine d’enveloppe, le domaine DKIM, le responsable et le fournisseur.
Un prestataire peut envoyer avec son domaine par défaut et proposer une authentification personnalisée en option. Un site peut utiliser un ancien serveur local. Un équipement peut envoyer rarement, mais produire une alerte indispensable. Ces cas doivent être testés avant une politique restrictive.
Un sous-domaine dédié aux campagnes peut clarifier la gestion et les responsabilités, sans constituer une immunité contre les problèmes de réputation.
Il faut vérifier ses propres réglages et l’éventuelle politique héritée. Ne modifiez pas les enregistrements MX ou les serveurs de noms pour satisfaire une simple demande d’authentification sans comprendre le besoin exact.
Observer avant de durcir
Préparez une copie de la zone existante, les accès nécessaires, un responsable de changement et un retour arrière documenté. Vérifiez les noms complets : certaines interfaces DNS ajoutent automatiquement le domaine, d’autres demandent le nom complet. Une erreur peut placer l’enregistrement au mauvais endroit tout en donnant l’impression qu’il a été créé.
Après configuration des sources légitimes, une phase de surveillance DMARC permet d’observer les résultats sans demander immédiatement le rejet. Les rapports agrégés aident à repérer les infrastructures émettrices et les défauts d’alignement. Ils ne recensent pas tous les messages de façon exhaustive : leur disponibilité dépend des destinataires et du circuit de collecte.
Le service qui reçoit les rapports doit être prévu, sécurisé et autorisé. Un destinataire de rapport situé sur un autre domaine peut nécessiter une autorisation DNS spécifique. Évaluez aussi le traitement des données et la durée de conservation avant de déléguer cette analyse à un prestataire.
Le durcissement doit suivre la correction des flux et une observation couvrant les envois rares. Évitez d’appliquer un modèle trouvé sur Internet sans vérifier son statut dans la norme et sa prise en charge réelle. Le paramètre historique pct, autrefois utilisé pour demander une application partielle de la politique, a été retiré de la RFC 9989. Il ne constitue donc pas une recette universelle de déploiement progressif. Le passage à une politique restrictive doit être un changement contrôlé, avec suivi des erreurs et possibilité de revenir à la configuration précédente.
Tester les parcours qui déforment le message
Un transfert peut casser SPF : l’IP du serveur qui retransmet n’est pas nécessairement autorisée pour l’expéditeur initial. DKIM peut continuer à réussir si les parties signées restent intactes. Une liste de diffusion modifiant l’objet ou ajoutant un pied de page peut à son tour invalider la signature. Ces parcours expliquent certains échecs légitimes.
ARC peut transmettre des informations sur des contrôles réalisés en amont et aider certains destinataires à prendre leur décision. Ce mécanisme ne transforme pas automatiquement un échec DMARC en réussite et dépend de la confiance accordée aux intermédiaires.
Enfin, contrôlez les en-têtes de messages reçus dans plusieurs environnements et les journaux de vos services. Les exigences des grands destinataires peuvent aller au-delà du verdict DMARC : Google demande notamment SPF et DKIM ainsi que DMARC aux expéditeurs de gros volumes vers les comptes Gmail personnels, avec d’autres conditions. Une PME gagne à conserver un registre des flux et des sélecteurs : le prochain logiciel ajouté pourra ainsi être intégré sans réapprendre son domaine dans l’urgence.
