Configurer SPF, DKIM et DMARC sans interrompre les e-mails du site

Authentifiez chaque service qui envoie des courriels pour votre site avant de durcir la politique de rejet du domaine. Cela comprend les reçus, réinitialisations de mot de passe, réponses d'assistance et tout autre système d'envoi légitime. Un seul expéditeur oublié peut transformer une amélioration de sécurité en panne apparemment inexplicable de messages importants.

SPF, DKIM et DMARC sont des contrôles liés, pas trois badges interchangeables. Abordez d'abord ce chantier comme un exercice d'inventaire et de vérification. Copier un enregistrement d'un autre site est particulièrement risqué, car votre domaine peut utiliser d'autres fournisseurs, d'autres sous-domaines d'envoi et un autre circuit pour les messages retournés.

Inventoriez les vrais expéditeurs avant de modifier le DNS

Listez chaque type de message, le service qui l'envoie, l'adresse From visible et la personne responsable du compte. Envoyez un test autorisé par chaque circuit et conservez ses en-têtes de façon privée. Un message envoyé manuellement depuis votre boîte ne teste pas le service de reçus ou de réinitialisation de mot de passe de l'application.

SPF autorise des systèmes d'envoi pour le domaine d'expéditeur d'enveloppe utilisé durant l'acheminement. DKIM ajoute à un message la signature cryptographique d'un domaine. DMARC évalue ensuite si un domaine authentifié est aligné sur celui que le destinataire voit dans From. Ces distinctions sont décrites dans la spécification DMARC.

Un site hypothétique pourrait envoyer les réponses d'assistance via son fournisseur de messagerie et les reçus d'achat via un service commercial distinct. Les deux messages peuvent afficher la même marque tout en suivant des circuits techniques différents. Vérifiez les deux au lieu de supposer que les instructions DNS du fournisseur de messagerie couvrent tous les envois de l'entreprise.

Consignez les valeurs DNS actuelles et la personne capable de les restaurer avant tout changement. Lorsque les fournisseurs exigent des enregistrements de vérification, utilisez les valeurs exactes fournies pour votre domaine. N'écrasez pas des enregistrements de routage sans rapport en cherchant à réparer l'authentification sortante : courrier entrant et authentification de l'expéditeur sont deux sujets distincts.

Ajoutez l'authentification sans casser un expéditeur existant

La spécification SPF n'autorise pas plusieurs enregistrements SPF pour un même nom de domaine. Lorsqu'un second fournisseur doit être autorisé, modifiez délibérément la politique existante au lieu d'ajouter un autre enregistrement v=spf1 indépendant. Plusieurs enregistrements TXT différents sont normaux ; plusieurs politiques SPF concurrentes posent problème.

L'évaluation SPF limite aussi à 10 les mécanismes et modificateurs entraînant des requêtes DNS. Les inclusions imbriquées peuvent consommer ce quota : compter les noms de fournisseurs visibles ne suffit donc pas. Demandez à l'administrateur de messagerie d'évaluer toute la politique plutôt que d'ajouter des inclusions jusqu'à ce qu'un tableau de bord passe au vert.

Pour DKIM, suivez les instructions de clé et de sélecteur de chaque expéditeur, puis vérifiez un message réellement envoyé par ce service. Publier une clé ne prouve pas que le service a commencé à signer avec elle. Gardez les clés privées privées ; seules les données DNS publiques désignées par le fournisseur doivent figurer dans une configuration partagée.

Ne supprimez pas un ancien fournisseur d'envoi avant de vérifier si des tâches programmées ou une autre équipe l'utilisent encore. Une zone DNS apparemment propre peut masquer une facturation mensuelle qui ne fonctionne plus. Retirez l'autorisation uniquement après avoir supprimé la dépendance opérationnelle et testé son remplacement.

Exploitez les rapports DMARC avant d'imposer le rejet

Commencez par observer lorsque tous les expéditeurs légitimes ne sont pas encore connus. Une politique DMARC p=none ne demande ni quarantaine ni rejet fondés sur DMARC, tandis que les rapports peuvent révéler les problèmes d'authentification et d'alignement. C'est une étape de surveillance, pas la preuve que les messages usurpés sont bloqués.

Une validation DMARC exige SPF aligné ou DKIM aligné, pas simplement une authentification réussie pour un domaine sans rapport. Examinez les domaines authentifiés dans un message de test livré. Le nom de marque visible n'est pas le test d'alignement, et une livraison réussie une fois ne prouve pas que la politique est correcte.

Désignez quelqu'un pour analyser les rapports agrégés et examiner les sources inconnues avant de modifier la politique. Protégez la destination des rapports et limitez l'accès aux données opérationnelles. Une adresse de rapports que personne ne consulte ajoute du paramétrage sans créer de contrôle utile.

Renforcez le traitement seulement lorsque les circuits légitimes passent les vérifications et qu'un retour arrière est documenté. Testez de nouveau après un changement de fournisseur, de domaine From ou de configuration de signature. Le but est de rejeter l'usurpation sans transformer les messages ordinaires des clients en dommages collatéraux.

Vérifiez les exigences des destinataires et la livraison réelle

Les consignes Gmail aux expéditeurs exigent SPF ou DKIM pour tous les expéditeurs vers des comptes Gmail personnels, et SPF, DKIM et DMARC pour les expéditeurs en masse. Google traite aussi de l'alignement, de la sécurité du transport et d'autres pratiques d'acheminement. L'authentification est un préalable nécessaire, pas une garantie de placement en boîte de réception.

N'appliquez pas aveuglément une règle destinée aux promotions en masse à tous les messages transactionnels. Identifiez le public, la finalité du message et les exigences applicables du destinataire. Distinguez reçus et notifications de compte du marketing pour éviter que le dépannage de livraison ne se mélange à des pratiques promotionnelles sans rapport.

Après déploiement, vérifiez les messages de chaque expéditeur inventorié et examinez les avis de rejet. Conservez les horodatages et détails d'erreur, mais ne publiez ni identifiants ni contenus privés de clients dans un outil de suivi public. Comparez les échecs au changement précis plutôt que de modifier sans cesse plusieurs enregistrements DNS à la fois.

Ajoutez la revue des expéditeurs à votre routine de maintenance web, notamment lorsque des changements d'hébergement ou d'infrastructure touchent la messagerie. L'objectif final n'est pas trois enregistrements DNS. C'est une liste testée d'expéditeurs légitimes, une politique observée et un responsable clairement identifié pour la prochaine modification.