Vérifier SPF, DKIM et DMARC pour chaque parcours d’envoi

Lorsqu’une application envoie des e-mails via un service externe, regarder l’adresse de l’entreprise dans le logiciel de messagerie ne suffit pas. Consignez le parcours réel et contrôlez un message de test autorisé au point de réception prévu. Les enregistrements DNS et le contrôle du message répondent à des questions différentes.

Partir d’un parcours d’envoi précis

Dans la conception fictive, un portail client envoie des notifications de statut. L’expéditeur visible est hinweis@firma.example ; le service externe utilise versand.example comme domaine pour son expéditeur SMTP et sa signature. Ces noms servent uniquement à cette conception. Aucun message n’a été envoyé et aucun enregistrement DNS n’a été interrogé.

Précisez d’abord quelle application déclenche l’e-mail, quel service le transmet et qui gère la configuration de domaine de ce service. Consignez séparément les autres parcours, par exemple les notifications d’un système d’assistance. La configuration d’un service ne prouve pas celle d’un autre.

Contrôler ensemble le DNS et le message réel

SPF décrit les serveurs autorisés pour les identités SMTP. Rattachez l’enregistrement publié au domaine SMTP réellement utilisé. La seule présence d’un enregistrement TXT ne constitue pas un résultat positif pour ce parcours précis.

DKIM associe les parties signées du message au domaine signataire. Vérifiez aussi que le service signe réellement et que la signature est valide au point de réception prévu. La publication d’une clé publique dans le DNS ne le confirme pas à elle seule. Tenez compte des services qui traitent le message après sa signature.

DMARC exige un contrôle SPF ou DKIM réussi avec un alignement de domaine approprié par rapport à l’expéditeur visible. Cette correspondance s’appelle alignment, ou alignement. Déterminez donc aussi l’enregistrement DMARC applicable et les conditions d’alignement qu’il prévoit.

Interpréter correctement un résultat positif isolé

Le tableau suivant contient des hypothèses délibérément construites pour cette même conception, pas des résultats mesurés.

Pour l’approbation, le service concerné doit prendre en charge une configuration de domaine appropriée et l’envoi correspondant. La modification nécessaire dépend du service. Copier un enregistrement DNS quelconque ou régler trop vite une politique sur le rejet ne résout pas le problème d’alignement.

Conserver les preuves du test d’envoi contrôlé

Documentez le parcours d’envoi, les domaines utilisés, le message contrôlé et les résultats du test. Si d’autres services interviennent, ce parcours nécessite aussi un cas de test adapté. Répétez le contrôle après toute modification du service, du domaine ou du traitement des messages.

Google traite l’authentification comme une composante de ses exigences d’envoi. Même un cas de test technique réussi ne prouve ni le classement en boîte de réception ni la lecture. Consignez séparément l’observation de la réception et désignez qui traite les contrôles échoués et les retours de livraison.

Sources

• IETF: Sender Policy Framework

• IETF: DKIM Signatures

• IETF: DMARC

• Google: Email sender guidelines