Pourquoi l'authentification par courriel compte-t-elle?

Chaque jour, des milliards de courriels traversent Internet, et une partie importante d'entre eux sont frauduleux. Les courriels Spoophed, les attaques de phishing et les tentatives d'usurpation coûtent des milliards d'entreprises par an. Les protocoles d'authentification des courriels – SPF, DKIM et DMARC – sont la base d'un écosystème de messagerie sécurisé.

La configuration correcte de ces enregistrements DNS n'est pas seulement une tâche informatique, mais une fonction opérationnelle essentielle. Ce guide fournit une analyse approfondie et prête à la production de SPF, DKIM et DMARC, couvrant ce que chacun fait, comment les mettre en place, les erreurs courantes à éviter et comment les surveiller pour assurer une sécurité continue.

Qu'est-ce que le SPF?

Sender Policy Framework (SPF) est une méthode d'authentification par courriel qui spécifie quels serveurs de messagerie sont autorisés à envoyer des courriels au nom de votre domaine. Elle fonctionne en publiant une liste d'adresses IP approuvées ou de noms d'hôte dans un enregistrement TXT DNS. Lorsqu'un serveur de messagerie récepteur reçoit un message qui prétend être de votre domaine, elle vérifie l'enregistrement SPF pour voir si l'IP du serveur d'envoi et du serveur d'envoi et du numéro 8217; est autorisé.

SPF aide à prévenir le spoofing par e-mail, mais il a des limites. Il ne vérifie que le domaine de l'expéditeur d'enveloppe (l'adresse ), pas l'en-tête visible . Cela signifie qu'un spammeur pourrait spoof le nom d'affichage en utilisant un domaine d'enveloppe différent, contournant SPF.

Comment le SPF fonctionne sous le capot

Lorsqu'un courriel est transmis par SMTP, le serveur d'envoi annonce l'expéditeur d'enveloppe (généralement le retour-pathét). Le serveur de réception effectue une recherche DNS pour l'enregistrement SPF de ce domaine. L'enregistrement est un enregistrement TXT qui commence par suivi de mécanismes et de modificateurs. Les mécanismes comprennent:

  • et – spécifiez les adresses IP exactes ou les plages CIDR autorisées à envoyer.
  • – importe la politique SPF d'un autre domaine (communément utilisée pour les services de messagerie tiers comme SendGrid ou Mailgun).
  • et – autorisent les enregistrements A ou MX comme expéditeurs.
  • – vérifie si un domaine particulier existe (rarement utilisé).
  • – qualificatif qui définit l'action par défaut pour les expéditeurs non appariés.

Les qualificatifs peuvent être (pass), (softfail), (fail), ou (neutre). La configuration la plus sécurisée se termine par ] pour rejeter tous les expéditeurs non autorisés.

Configuration SPF étape par étape

  1. Identifiez toutes les sources de courriel légitimes pour votre domaine : vos propres IP de serveur de messagerie, votre fournisseur de services de messagerie (par exemple Google Workspace, Microsoft 365, Zoho) et tout service tiers qui envoie des courriels (transactionnel, marketing, etc.).
  2. Connectez-vous à votre fournisseur DNS (p. ex. Cloudflare, AWS Route 53, GoDaddy, Namecheap).
  3. Ajouter un nouvel enregistrement TXT pour votre domaine (souvent l'enregistrement pour le domaine racine).
  4. Craft the value. Exemple pour un domaine utilisant Google Workspace et un service tiers:
v=spf1 include:_spf.google.com include:mailgun.org ~all
  • Le mécanisme tire dans les politiques SPF de Google et Mailgun.
  • Utiliser pendant les tests initiaux, puis passer à après avoir vérifié qu'aucun expéditeur légitime n'est bloqué.
  1. Enregistrer et propager. Les changements DNS peuvent prendre jusqu'à 48 heures, mais se propager souvent en quelques minutes.
  2. Validation avec des outils en ligne comme MXToolbox ou Kitterman’s SPF validator.

Pièges communs du FPS

  • Trop de recherches DNS – La spécification SPF limite le nombre total de recherches DNS (y compris, a, mx, etc.) à 10. En dépassant cela, la vérification SPF renvoie une erreur permanente, souvent traitée comme un résultat neutre. Pour réduire les recherches, la consolidation inclut ou utilise une liste plate d'IPs lorsque c'est possible.
  • Utilisation – Un qualificatif neutre ne fait pas exécuter l'authentification; utiliser ou pour fournir une politique significative.
  • Pour éviter de mettre à jour les fournisseurs de messageries ou d'ajouter de nouveaux services. Consultez toujours votre enregistrement SPF après toute modification de l'infrastructure.
  • Incluant trop de tiers inclut sans vérifier qu'ils sont nécessaires.

Qu'est-ce que DKIM?

DomainKeys Identified Mail (DKIM) fournit une façon cryptographique de vérifier qu'un courriel n'a pas été altéré en transit et qu'il provient réellement du domaine revendiqué. DKIM utilise une paire de clés : une clé privée gardée secrète par le serveur de messagerie et une clé publique publiée dans un enregistrement DNS TXT. Lorsqu'un courriel est envoyé, le serveur signe le message (ou des en-têtes spécifiques) avec la clé privée. Le serveur récepteur récupère la clé publique du domaine’s DNS et vérifie la signature. Si la signature correspond, le courriel est considéré comme authentifié.

DKIM est plus robuste que SPF car il survit à la transmission des courriels. SPF peut se casser lorsqu'un message est envoyé parce que l'expéditeur d'enveloppe peut changer. DKIM signe toutefois les en-têtes et le corps d'origine, de sorte que la signature reste valide même après la transmission.

Comment les signatures DKIM sont créées

Lorsqu'un courriel est signé, le serveur d'envoi ajoute un en-tête contenant des paramètres tels que le sélecteur (que la clé publique à utiliser), le domaine, l'algorithme de signature (généralement ) et les champs signés. Le corps du message est hashé et inclus dans la signature. Le serveur récepteur extrait le sélecteur de l'en-tête, construit le nom de la clé DNS (par exemple ), et récupère l'enregistrement de la clé publique. Il recompile ensuite le hash et le compare.

Configuration de DKIM: un guide pratique

  1. Activer la signature DKIM dans votre plateforme de messagerie.La plupart des fournisseurs ont une page de paramètres pour générer des clés.
  2. Notez le sélecteur. De nombreuses plateformes utilisent (pour Google Workspace) ou . Des fournisseurs comme Microsoft 365 peuvent utiliser ou .
  3. Copier la clé publique. Ce sera une longue base64 chaîne.
  4. Ajouter un enregistrement TXT à votre DNS avec le nom d'hôte et la valeur fournie par votre fournisseur de messagerie, qui ressemble généralement à:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...[truncated]
  • La balise indique la version. est le type de clé (par défaut). est les données de clé publique.
  1. »Attendez la propagation puis testez en envoyant un courriel et en examinant les en-têtes pour obtenir une signature DKIM valide. Des outils comme ou Google’s Postmaster Tools peuvent vérifier.

Rotation et sécurité des clés de DKIM

La meilleure pratique est de faire tourner périodiquement les clés DKIM (par exemple tous les 6 mois). De nombreux fournisseurs de messagerie gèrent automatiquement la rotation des clés. Si vous gérez votre propre serveur de messagerie, créez régulièrement une nouvelle paire de clés et mettez à jour l'enregistrement DNS.

Envisagez également d'utiliser Auteur Domain Signing Practices (ADSP) pour indiquer que tous les courriels de votre domaine doivent être signés DKIM. Cependant, ADSP est largement obsolète; DMARC couvre maintenant ce cas d'utilisation.

Qu'est-ce que le DMARC ?

Authentification des messages par domaine, reporting & Conformance (DMARC) unifie SPF et DKIM dans un cadre politique unique. DMARC indique aux serveurs de messagerie récepteurs ce qu'ils doivent faire avec les messages qui échouent à la fois SPF et DKIM. Il fournit également un mécanisme de reporting qui donne aux propriétaires de domaines une visibilité sur les défaillances d'authentification par courriel, les aidant à détecter les abus et à affiner leurs configurations.

La politique du DMARC est établie dans un dossier TXT DNS sous . Le dossier précise une politique pour traiter le courrier non authentifié : (moniteur seulement), (marquer comme du spam), ou (livraison par blocs).

Comment le DMARC aligne SPF et DKIM

Pour que le SPF passe le DMARC, le domaine dans l'enveloppe (ou Retour-Path) doit s'aligner sur le domaine dans l'en-tête visible . Pour DKIM, le domaine de signature (le paramètre dans l'en-tête DKIM-Signature) doit s'aligner. L'alignement peut être strict (accord exact) ou détendu (sous-domaines autorisés). Vous définissez cela via les balises et .

Une vérification DMARC réussit si au moins un des SPF ou DKIM passe et s'aligne sur le domaine utilisé dans l'en-tête . Si les deux échouent, la politique DMARC est appliquée.

Configuration du DMARC : De la surveillance à l'application

  1. Commencez par une politique . Cela vous permet de recueillir des rapports sans affecter la livraison. Ne sautez pas cette étape.
  2. Ajouter une adresse courriel en utilisant l'étiquette (rapports agrégés) et facultativement (rapports forensiques). Exemple :
v=DMARC1; p=none; rua=mailto:[email protected]
  1. Analyse les rapports pendant au moins deux semaines. Utilisez des outils comme Postmark’s DMARC Dashboard, DMARCian, ou Dmarcian. Recherchez tous les services légitimes qui échouent à l'authentification et les corriger (mise à jour SPF, ajouter la signature DKIM).
  2. Déplacez-vous vers dès que vous êtes convaincu qu'aucun courriel légitime ne échoue.
  3. Enfin, définir après un mois ou deux de manipulation réussie de quarantaine. Cela indique aux récepteurs de bloquer tout courriel non authentifié, fournissant la protection la plus forte contre l'effusion.

Mots clés et options DMARC

  • – version (obligatoire).
  • – politique relative au domaine organisationnel (aucune, quarantaine, rejet).
  • – politique relative aux sous-domaines (si elle n'est pas définie, les sous-domaines héritent ).
  • ; mode d'alignement DKIM (strict ou détendu).
  • ou – mode d'alignement SPF.
  • – adresse(s) électronique(s) pour la rétroaction globale (généralement un courriel à: URI).
  • – courriel pour les rapports médico-légaux (utilisés pour les détails de défaillance individuelle).
  • – options de rapport de défaillance (p. ex. ] pour générer des rapports si une vérification échoue).
  • – pourcentage de messages à appliquer (utilisation de 100 pour l'application intégrale).

Rapports et surveillance du DMARC

Les rapports agrégés (rua) sont des fichiers XML envoyés quotidiennement par les récepteurs participants (comme Google, Yahoo, Microsoft). Ils contiennent des comptes de messages par IP source, les résultats d'authentification et la disposition. Les rapports médico-légaux (ruf) fournissent des détails sur les défaillances individuelles. Utilisez ces rapports pour découvrir des expéditeurs non autorisés, des services tiers mal configurés ou des courriels envoyés qui rompent l'authentification.

Plusieurs outils gratuits et payants analysent les rapports DMARC et les présentent dans un format lisible. Pour une approche pratique, vous pouvez configurer un service d'analyse de rapport comme dmarcian ou utiliser des solutions open-source telles que parsedmarc.

Mettre tout en place : une stratégie d'authentification cohésive

SPF, DKIM et DMARC fonctionnent de manière synergique. SPF empêche les IP non autorisées d'envoyer des messages en utilisant votre domaine. DKIM assure l'intégrité et la provenance des messages. DMARC aligne ces deux éléments et fournit une couche d'application de la politique plus de visibilité.

Voici une liste de contrôle pour une configuration de qualité de production:

  • SPF: Publier un document qui comprend toutes les sources d'envoi légitimes, respecte la limite de 10 regards, et se termine par (après test).
  • DKIM: Signez tous les courriels sortants avec au moins un sélecteur. Rotez régulièrement les clés. Assurez-vous que votre plateforme de messagerie signe des courriels transactionnels et marketing.
  • DMARC: Commencez par , analysez les rapports, puis avancez vers et enfin .
  • Moniteur en continu: Vérifiez régulièrement les rapports DMARC, surtout après avoir ajouté de nouveaux services de messagerie.

Exemple de réalité mondiale : Configuration pour Directus

Si vous hébergez une instance Directus et envoyez des courriels (par exemple, réinitialisez le mot de passe, notifications), vous devez authentifier ces messages. Supposons que votre application Directus utilise un service SMTP comme SendGrid ou Mailgun. Suivez ces étapes :

  1. Obtenez les IPs d'envoi ou incluez le domaine de votre fournisseur SMTP (p. ex. ] pour SendGrid).
  2. Ajoutez cela à votre enregistrement SPF. Si vous envoyez également depuis un autre système (par exemple, un serveur de messagerie PHP), incluez également ses IP.
  3. Générez les clés DKIM dans votre fournisseur SMTP et publiez la clé publique.
  4. Configurez un enregistrement DMARC avec pointant vers une adresse email surveillée.
  5. Testez en envoyant un courriel de test de Directus à une boîte aux lettres comme Gmail et inspectez les en-têtes d'authentification.

Dépannage de problèmes communs

SPF PermError: Trop de recherche

Si votre enregistrement SPF contient plusieurs instructions , vous pouvez dépasser 10 requêtes DNS. Pour corriger, soit supprimer les inclut inutiles, les combiner avec des plages IP, soit créer un sous-domaine avec un enregistrement SPF plus maigre.

Signature DKIM manquante ou non

Vérifiez que la clé privée est correctement installée sur le serveur d'envoi. Pour les fournisseurs de messageries partagées, assurez-vous que la signature DKIM est activée dans le panneau de contrôle. Vérifiez que le sélecteur dans l'enregistrement DNS TXT correspond au sélecteur dans l'en-tête de messagerie.

Rapports du DMARC montrant les échecs pour le courriel légitime

Causes communes : envoi d'e-mail (le FPS échoue parce que le transitaire modifie l'enveloppe), services tiers non pas la signature DKIM, ou alignement incorrect. Pour envoyer un e-mail, envisager d'utiliser ARC (Authenticited Receive Chain) si supporté, ou demander aux destinataires de liste blanche.

Ressources et références externes

Pour des plongées plus profondes, consultez ces sources faisant autorité :

Les pensées finales

La configuration de SPF, DKIM et DMARC n'est pas une tâche ponctuelle mais un processus continu. Les paysages d'authentification des courriels évoluent, et font des menaces. En installant ces enregistrements correctement et en les surveillant continuellement, vous protégez votre domaine, améliorez sa livraison et créez la confiance avec vos destinataires. Commencez par un audit attentif de votre infrastructure d'envoi de courriels, implémentez les enregistrements un par un et ne sautez jamais la phase de rapport. Votre domaine — et votre entreprise — sera donc plus sécurisé.