Ordre prudent pour configurer SPF, DKIM et DMARC

L'authentification des emails avec SPF, DKIM et DMARC peut faire la différence entre un message accepté et une facture introuvable. Si le domaine ne peut pas prouver son identité, les fournisseurs ont moins d'indices pour lui faire confiance. Cette tâche fait désormais partie de l'exploitation quotidienne.

Les équipes n'oublient pas toujours les trois protocoles. Elles les configurent parfois dans un ordre risqué, publient une politique stricte trop tôt et bloquent leur propre courrier. Si vous réglez encore les choix fondamentaux de messagerie professionnelle, commencez par là, puis sécurisez l'authentification.

Ce guide propose une séquence prudente : inventaire, SPF, DKIM, DMARC avec p=none, correction de l'alignement et application progressive. Ce n'est pas la seule séquence possible dans tous les environnements, mais elle limite le risque de perturber transferts, marketing et assistance légitimes.

Si vous utilisez TrekMail, la plateforme fournit des contrôles DNS et, selon l'offre et la configuration, domaines personnalisés, IMAP, catch-all, transfert, migration et SMTP personnel ou géré. Pour ajouter un domaine, consultez le guide de configuration. Pour partir de zéro, lisez créer une adresse email avec un domaine.

Ce que font réellement SPF, DKIM et DMARC

Ces trois mécanismes sont liés. SPF autorise des IP pour le domaine MAIL FROM réel, DKIM valide la signature et les données signées, et DMARC demande un traitement lorsque les contrôles échouent ou ne sont pas alignés avec le champ From visible.

SPF ressemble à une liste d'accès, DKIM à un sceau et DMARC à un règlement. Les règles actuelles peuvent imposer les trois, mais il est prudent de les déployer par étapes après avoir identifié les parcours réels.

Un ordre de configuration prudent

Une séquence habituelle consiste à inventorier les expéditeurs, publier SPF, activer DKIM, publier DMARC sans restriction, corriger l'alignement, puis renforcer progressivement la politique. Elle réduit le risque de rejeter du courrier légitime avant de connaître toutes les sources.

1. Inventoriez chaque système qui envoie au nom du domaine.
2. Publiez un SPF qui comprend les expéditeurs légitimes.
3. Activez DKIM chez chaque prestataire compatible.
4. Publiez DMARC avec p=none et recueillez plusieurs périodes de rapports.
5. Corrigez les échecs d'alignement.
6. Passez à p=quarantine, puis p=reject si les preuves le justifient.

La difficulté ne vient pas tant de la longueur des enregistrements que de la complexité réelle des sources d'envoi.

Phase 1 : inventaire et SPF

SPF constitue souvent un premier changement utile, car il indique quelles IP peuvent envoyer pour le domaine MAIL FROM. Il ne résout pas tout, mais donne un point de départ et révèle d'anciens prestataires encore autorisés.

Avant de toucher au DNS, recensez messagerie interne, facturation, CRM, assistance, marketing, formulaires, imprimantes et tout système utilisant @yourdomain.com. Vérifiez aussi son domaine d'enveloppe dans de vrais messages.

Publiez un seul SPF, pas un pour Google et un pour le marketing. Plusieurs TXT SPF pour le même domaine provoquent une erreur. La documentation TrekMail le précise dans ses exemples DNS.

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net include:amazonses.com ~all

Choisissez ~all ou -all en fonction d'une politique étudiée et de parcours vérifiés ; aucune de ces valeurs ne remplace un inventaire complet.

Le grand piège de SPF est la limite de recherches. Selon la RFC 7208, l'évaluation est limitée à 10 recherches DNS issues des mécanismes et modificateurs concernés, y compris leur évaluation imbriquée. Accumuler include:, a ou mx peut produire permerror et empêcher une évaluation complète.

Vous ajoutez Google, HubSpot, Zendesk, QuickBooks, Mailchimp et un ancien outil oublié. SPF paraît complet, mais un destinataire atteint la limite pendant l'évaluation et obtient une erreur.

Avec de nombreux domaines, la gestion devient vite opérationnelle. Auditez les prestataires, retirez un include uniquement après avoir confirmé son inutilité et séparez sur des sous-domaines seulement si les routes MAIL FROM sont configurées et testées. Pour plusieurs clients, un hébergement de messagerie multidomaine peut centraliser certains contrôles.

Phase 2 : DKIM et alignement

DKIM vient ensuite parce que SPF est fragile. Le transfert peut changer l'IP et casser SPF, alors que DKIM peut rester valide si la signature alignée survit et si les données signées respectent la canonicalisation. Ce n'est pas le cas sur tous les parcours.

Activez DKIM dans chaque service compatible : boîtes, plateforme transactionnelle, marketing et assistance. Si un service ne peut pas signer avec votre domaine, évaluez le risque et les solutions possibles sans supposer qu'une authentification personnalisée existe.

Un DNS DKIM type est :

Type: TXT
Host: trek._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...

Certains prestataires utilisent un CNAME pour DKIM lorsqu'ils le prennent en charge. La méthode change, mais il faut toujours activer la fonction et tester de vrais messages.

Utilisez des sélecteurs séparés lorsque le prestataire le permet. Cela facilite le retrait d'une plateforme sans toucher à la signature du serveur principal.

L'alignement est une source d'échec discrète. L'authentification ne suffit pas : DMARC vérifie que le domaine authentifié correspond au champ From visible. Les consignes actuelles de Google pour le trafic concerné exigent un alignement SPF ou DKIM avec le domaine organisationnel de From et peuvent exiger la publication des deux protocoles. Voir la FAQ destinée aux expéditeurs.

Si Mailchimp signe avec son domaine et utilise son propre Return-Path, SPF et DKIM peuvent réussir tandis que DMARC échoue pour votre champ From. Si le prestataire le permet, activez son authentification de domaine personnalisée et vérifiez le résultat réel. Il n'existe pas de correction universelle en dehors des fonctions prises en charge.

Le transfert est un cas classique. Si votre équipe y recourt souvent, consultez la configuration et la correction du transfert. Le résultat dépend du parcours, de la signature et des modifications intermédiaires.

Phase 3 : DMARC sans restriction demandée

DMARC commence souvent avec p=none, qui ne demande aucune restriction DMARC pendant la collecte de données partielles. Cette valeur ne place pas l'analyseur dans un mode spécial et ne désactive pas le filtrage local.

Voici un enregistrement initial :

Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s

Vous pouvez choisir l'alignement souple par défaut ou le mode strict selon vos domaines et parcours testés. Le strict n'est pas toujours meilleur. Ne passez pas immédiatement au rejet sans connaître chaque expéditeur légitime et son alignement.

Les rapports DMARC sont utiles mais incomplets ; un analyseur facilite leur lecture. SPF fail avec une signature DKIM valide et alignée peut encore donner DMARC pass, notamment après certains transferts. Si les deux échouent, enquêtez : il peut s'agir d'une usurpation ou d'une source légitime oubliée. Pour TrekMail, consultez le guide des problèmes de spam.

Cette phase révèle systèmes oubliés, scanners mal configurés, anciennes newsletters et éventuelles tentatives d'usurpation. Vérifiez chaque classement avec l'inventaire, les journaux et des messages réels avant de décider.

Phase 4 : corriger ce que montrent les rapports

Les rapports fournissent des indices sur l'alignement et l'authentification, mais ne déterminent pas à eux seuls quelle source est fausse. Distinguez les erreurs légitimes des abus possibles et validez le trafic réel sur plusieurs périodes représentatives.

Les échecs appartiennent souvent à ces catégories :

• Un expéditeur réel manque dans SPF.
• Un prestataire signe avec DKIM, mais pas avec votre domaine.
• Le marketing utilise un domaine bounce par défaut et SPF n'est pas aligné.
• Un appareil envoie directement au lieu de passer par un relais authentifié.
• Une IP inconnue tente d'usurper le domaine From.

Imprimantes et scanners envoient souvent directement. Un relais SMTP bien configuré peut être plus contrôlable. Les offres payantes TrekMail comprennent le SMTP géré selon les conditions actuelles ; Nano est proposé avec un SMTP personnel selon ces conditions. Le guide des paramètres IMAP et SMTP documente les hôtes et ports actuels. TrekMail est présenté comme un service IMAP et non POP3.

Lorsque rapports, journaux, tests réels et parcours critiques rares ont été validés sur plusieurs périodes représentatives, avancez avec prudence et préparez un retour arrière.

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

Commencez par quarantine si cela correspond au risque, puis envisagez reject lorsque l'inventaire et l'alignement sont fiables. Ce sont des politiques demandées ; le destinataire conserve son appréciation.

Vérifier les enregistrements en ligne de commande

La vérification est importante, car les tableaux peuvent présenter des données anciennes, les caches persistent et les fournisseurs tardent à se mettre à jour. Interrogez directement le DNS et envoyez des messages de test depuis chaque système.

Vérifiez SPF :

dig txt example.com +short

Vérifiez DKIM pour un sélecteur :

dig txt trek._domainkey.example.com +short

Vérifiez DMARC :

dig txt _dmarc.example.com +short

Recherchez un seul SPF, une clé DKIM valide et la politique DMARC voulue. Si un changement n'apparaît pas, tenez compte du TTL et interrogez un résolveur externe sans supposer qu'une vue représente tous les destinataires.

Contrôlez aussi DNS inverse, TLS et taux de plaintes. L'authentification est un socle, pas une solution magique ; elle ne compense pas une liste médiocre ou des envois imprudents.

Ancienne méthode et approche actuelle

Une méthode traditionnelle facture chaque boîte dans une suite étendue ou impose de gérer soi-même serveur, DNS, TLS, sélecteurs et réputation. Une autre permet de contrôler domaine, parcours SMTP et authentification via une plateforme dont le modèle n'est pas lié au nombre de boîtes, selon ses conditions.

Selon la source et sous réserve d'évolution, Starter commence à $3.50 par mois, Nano est proposé à $0 avec un SMTP personnel et les offres payantes comprennent le SMTP géré. Les fonctions peuvent inclure domaines personnalisés, IMAP, catch-all, transfert, migration IMAP côté serveur et API aux niveaux supérieurs. Vérifiez toujours l'offre, la configuration, le tarif et les limites actuels ; la migration IMAP copie les messages, pas le DNS ou les applications.

Voilà l'approche opérationnelle : configurez l'authentification, entretenez-la et comparez le modèle économique sans supposer d'économies automatiques. Pour comprendre l'offre, lisez configurer la messagerie sur mon domaine, puis consultez les tarifs TrekMail.

Conclusion

SPF, DKIM et DMARC forment un système lié. SPF autorise une IP pour MAIL FROM, DKIM valide la signature et DMARC évalue l'alignement tout en publiant une politique demandée. Un déploiement progressif réduit le risque d'interruptions provoquées par sa propre configuration.

En bref : inventoriez, publiez un SPF, activez DKIM lorsqu'il est pris en charge, utilisez DMARC avec p=none, corrigez l'alignement et avancez après les tests. C'est une voie opérationnelle prudente pour 2025 et 2026, pas une garantie universelle. Pour consulter les conditions actuelles, rendez-vous sur TrekMail.