Comprendre les limites du SPF dans l'authentification des e-mails

Sender Policy Framework ou SPF ne suffit pas à sécuriser les courriels d'entreprise contre l'hameçonnage et le spamming. l'hameçonnage et le spamming et du spamming. SPF est un protocole d'authentification des courriels qui protège le destinataire des courriels usurpés en vérifiant si l'adresse IP d'envoi est autorisée dans l'enregistrement DNS du domaine. Cependant, la limite de SPF sur le nombre maximum de consultations DNS et le désalignement de l'adresse From et du domaine provoquent des erreurs de mise en œuvre qui entraînent des problèmes de délivrabilité des courriels. DMARC s'appuie sur SPF (et DKIM) pour améliorer la sécurité et les rapports. Ce blog traite de ces problèmes SPF et de la manière dont DMARC permet de surmonter les limites de SPF.

Quelles sont les limites de l'enregistrement SPF ?

Il y a trois limites majeures au SPF qui rendent sa mise en œuvre et sa maintenance un peu délicates.

1. La limite SPF 10-Lookup

Lorsqu'un utilisateur interroge le serveur DNS, les ressources de son validateur, comme la bande passante, le temps, le processeur et la mémoire, sont utilisées. Pour éviter toute charge sur le validateur, il existe une limite SPF de 10 consultations supplémentaires. Cependant, la requête DNS pour l'enregistrement de politique SPF lui-même ne compte pas dans cette limite.

Conformément à la section 4.6.4 du RFC7208 section 4.6.4le serveur de messagerie du destinataire ne doit pas poursuivre le traitement lorsque la limite de 10 recherches est atteinte. Dans ce cas, le courrier électronique rejette la validation SPF avec une erreur Permerror. L'erreur SPF Permerror est l'un des messages qui apparaissent fréquemment dans le processus de mise en œuvre de SPF. Il entraîne la non-délivrance des courriels et se produit si plusieurs enregistrements SPF existent sur un domaine, si une erreur de syntaxe apparaît ou si les limites d'enregistrement SPF sont dépassées. Lorsque vous dépassez cette limite, l'implémentation SPF est considérée comme invalide et votre courriel échoue à SPF, ce qui peut nuire à vos taux de livraison.

Vous pouvez utiliser le Vérificateur d'enregistrement SPF pour éliminer cette erreur et garantir la sécurité des conversations par courrier électronique.

De plus, selon le RFC, une requête DNS d'un nom d'hôte trouvé dans un enregistrement enregistrement MX ne devrait pas générer plus de 10 enregistrements A ou AAAA. Si une requête DNS PTR génère plus de 10 résultats, seuls les 10 premiers résultats sont affichés et utilisés.

2. L'adresse de départ lisible par l'homme

La deuxième limitation de SPF est que les enregistrements SPF s'appliquent à des domaines Return-Path spécifiques (également connus sous le nom d'expéditeur de l'enveloppe ou MFrom) et non à l'adresse From (expéditeur de l'en-tête ou adresse From) que les destinataires voient dans leurs clients de messagerie. Les destinataires ne prêtent généralement pas beaucoup d'attention à l'adresse Return-Path cachée et se concentrent uniquement sur l'adresse From visible lorsqu'ils ouvrent un courriel. Les pirates profitent de cette faille pour tenter des attaques par hameçonnage en utilisant un faux domaine dans leur adresse de retour (qui passe le SPF) et en falsifiant l'adresse d'origine avec une adresse légitime ou d'apparence légitime. Comme la plupart des gens ignorent l'existence de l'adresse Return Path et ne la vérifient pas, cette astuce permet aux pirates de contourner facilement la protection SPF.

3. Problèmes de transfert d'e-mails

SPF présente un autre point de défaillance critique qui peut nuire à la délivrabilité des courriels. Lorsque vous avez mis en place SPF sur votre domaine et que quelqu'un transfère votre courriel, le courriel transféré peut être rejeté en raison de votre politique SPF. En effet, le processus de transfert modifie le serveur qui envoie le message (et son adresse IP), mais l'adresse "From" de l'expéditeur d'origine reste souvent la même. Le serveur destinataire voit l'adresse From d'origine mais vérifie l'adresse IP du serveur *transférant* par rapport à l'enregistrement SPF de l'expéditeur d'origine. Comme l'adresse IP du serveur de transfert n'est généralement pas incluse dans l'enregistrement SPF de l'expéditeur initial, la vérification échoue, ce qui peut entraîner le rejet du courrier électronique transféré ou son marquage en tant que spam.

Simplifiez la sécurité avec PowerDMARC !

L'impact de la taille de l'enregistrement SPF sur la livraison des e-mails

Lorsqu'un destinataire dépasse la limite d'enregistrements SPF, il échoue aux contrôles SPF et une erreur de type Permerror se produit. Vous pouvez observer cette erreur lors de l'utilisation de la surveillance DMARC. Le destinataire peut choisir la manière de traiter les courriels ayant un échec Permerror. Il peut choisir de rejeter l'entrée, ce qui signifie que l'e-mail sera renvoyé. Certains destinataires configurent le système pour qu'il affiche un résultat SPF "neutre" (comme si aucun SPF n'était utilisé). Ils peuvent également choisir "fail" ou "softfail", ce qui signifie que les courriels qui échouent aux contrôles d'authentification SPF ne sont pas rejetés mais atterrissent dans le dossier spam. 

Ces résultats sont également déterminés en tenant compte des résultats de DMARC, DKIM et de l'évaluation du spam. Le dépassement de la limite SPF a un impact sur la délivrabilité des e-mails en réduisant la probabilité que les e-mails atterrissent dans la boîte de réception principale des destinataires.

Le validateur évalue la politique SPF de gauche à droite et lorsqu'une correspondance sur l'adresse IP de l'expéditeur est trouvée, le processus s'arrête. Désormais, selon l'expéditeur, un validateur peut ne pas toujours atteindre la limite de consultation, même si la politique SPF exige plus de 10 consultations pour une évaluation complète. Cela crée des difficultés pour identifier les problèmes de délivrabilité des e-mails liés à la limite des enregistrements SPF. 

Comment réduire le nombre de recherches nécessaires ?

Il est difficile pour certains propriétaires de domaines de rester dans la limite de 10 recherches SPF, car les habitudes d'échange de courriels ont considérablement changé depuis 2006 (date à laquelle la RFC4408 a été mise en œuvre). Aujourd'hui, les entreprises utilisent plusieurs programmes et services basés sur l'informatique en nuage avec un seul domaine. Voici donc quelques moyens de surmonter cette limite SPF courante.

• Supprimer les services non utilisés

Évaluez votre dossier SF et regardez s'il y a des services inutilisés ou non requis. Vérifiez si l'option 'inclure' ou d'autres mécanismes qui indiquent les domaines des services qui ne sont plus utilisés.

• Supprimer les valeurs SPF par défaut

La politique SPF par défaut est généralement fixée à 'v=spf1 a mx. Étant donné que la plupart des enregistrements A et AAAA sont utilisés pour des serveurs web qui n'envoient pas nécessairement de courriers électroniques, la valeur 'aet 'mx ne sont pas nécessaires.

• Évitez d'utiliser la fonction ptr Mécanisme

Le site ptr est fortement déconseillé en raison de sa faible sécurité et de son manque de fiabilité. Ce mécanisme provoque le problème de la limite SPF en exigeant plus de recherches. Il doit donc être évité autant que possible.

• Évitez d'utiliser le mx Mécanisme

Le site mx est utilisé pour recevoir des courriels, et pas nécessairement pour les envoyer. C'est pourquoi vous pouvez éviter de l'utiliser pour rester dans la limite d'enregistrement SPF fixée pour les recherches. Si vous utilisez un service de messagerie basé sur le cloud, utilisez le mécanisme 'inclure à la place.

• Utiliser IPv6 ou IPv4 

L'IPv4 et l'IPv6 ne nécessitent pas de vérifications supplémentaires, ce qui signifie qu'ils vous aident à ne pas dépasser la limite SPF de 10 vérifications maximum. Cependant, vous devez rester à jour et entretenir régulièrement les deux mécanismes car ils sont plus sujets aux erreurs lorsqu'ils ne sont pas reconditionnés.

• Envisager l'aplatissement de l'enregistrement SPF

Certaines ressources affirment que plus la politique SPF est aplatie (ou courte), meilleure est la réputation du domaine. Elles suggèrent cette méthode pour rester dans les limites de l'enregistrement SPF fixées pour les recherches. L'aplatissement consiste à remplacer des mécanismes tels que "include" par les adresses IP réelles auxquelles ils se rapportent, ce qui réduit directement le nombre de recherches DNS nécessaires lors de la validation. Toutefois, l'aplatissement nécessite une gestion minutieuse ; si les adresses IP derrière un service inclus changent, l'enregistrement aplati devient obsolète et doit être mis à jour manuellement pour éviter que des courriels légitimes n'échouent aux vérifications SPF. Les outils d'aplatissement SPF automatique peuvent aider à gérer ce processus.

Le rôle de DMARC pour surmonter les limites du SPF

DMARC répond à la limitation SPF de l'adresse de provenance lisible par l'homme en exigeant une correspondance ou un alignement entre le domaine du champ de provenance lisible par l'homme et le domaine authentifié par SPF (le domaine du chemin de retour).

Ainsi, si un courriel passe les contrôles SPF (ce qui signifie que l'adresse IP d'envoi est autorisée pour le domaine Return-Path) mais que le domaine Return-Path n'est pas le même que le domaine From, l'alignement DMARC pour SPF échoue. Pour qu'un courriel soit accepté par DMARC, il doit être accepté soit par SPF *avec* alignement, soit par DKIM *avec* alignement. Cela permet d'éviter la tactique courante du phishing qui consiste à usurper l'adresse "From" alors que le "Return-Path" passe SPF. DMARC introduit également des fonctionnalités de reporting, fournissant aux propriétaires de domaines un retour d'information sur les courriels prétendant provenir de leur domaine, y compris les résultats d'authentification (SPF, DKIM, DMARC, alignement) et des informations sur les sources d'envoi. Cette visibilité permet d'identifier les mauvaises configurations, les problèmes de transfert et les tentatives d'usurpation malveillantes.

Comment l'aplatissement des enregistrements SPF aide-t-il à surmonter la limite de 10 consultations du DNS ?

Aplatissement des enregistrements SPF est une technique utilisée pour optimiser les enregistrements SPF (Sender Policy Framework) afin de surmonter la limite de 10 recherches DNS pour SPF. La limite de 10 consultations DNS est une restriction imposée par de nombreux résolveurs DNS, qui limite le nombre de requêtes DNS pouvant être effectuées lors de la vérification d'un enregistrement SPF pour un domaine.

Lorsqu'un courriel est reçu, le serveur de messagerie du destinataire interroge le DNS du domaine de l'expéditeur pour obtenir son enregistrement SPF afin de vérifier si l'expéditeur est autorisé à envoyer des courriels à partir de ce domaine. Les enregistrements SPF utilisent souvent des mécanismes tels que "include", "a", "mx" et "ptr" qui nécessitent des recherches dans le DNS. Si l'enregistrement SPF contient de nombreux mécanismes de ce type, en particulier des inclusions imbriquées (lorsque l'enregistrement SPF d'un domaine inclus contient également des inclusions), il peut rapidement dépasser la limite de 10 consultations DNS, ce qui entraîne des échecs de vérification SPF (Permerror) et des problèmes potentiels de livraison de courrier électronique.

Pour surmonter cette limitation, l'aplatissement des enregistrements SPF est utilisé. L'aplatissement des enregistrements SPF est une technique qui remplace les mécanismes de recherche (principalement "include", mais aussi potentiellement "a" et "mx") dans un enregistrement SPF par les adresses IP ou les plages CIDR correspondantes. Cela réduit le nombre de requêtes DNS nécessaires pour vérifier l'enregistrement SPF, puisque les adresses IP sont listées directement au lieu de nécessiter des recherches supplémentaires.

En aplatissant l'enregistrement SPF, le nombre de requêtes DNS nécessaires pour vérifier l'enregistrement SPF est considérablement réduit, ce qui permet aux messages électroniques de passer la vérification SPF même si la structure originale de l'enregistrement aurait donné lieu à plus de 10 recherches DNS. Cette technique permet d'éviter les Permerrors SPF et réduit le risque d'échec de la validation de l'enregistrement SPF en raison de délais d'interrogation du DNS ou de problèmes temporaires du serveur DNS. Toutefois, comme indiqué précédemment, les enregistrements aplatis nécessitent une maintenance pour rester exacts lorsque les adresses IP sous-jacentes changent.

Les défis de la mise en œuvre du SPF dans les grandes entreprises

SPF a imposé la limitation à 10 consultations au maximum pour éviter les attaques DoS et DDoS. attaques DoS et DDoS contre l'infrastructure DNS pendant la validation SPF. Malheureusement, ces consultations peuvent s'accumuler très rapidement, en particulier dans les grandes entreprises. Auparavant, les entreprises exploitaient souvent leurs propres serveurs de messagerie, mais aujourd'hui, elles font largement appel à de nombreux expéditeurs tiers pour le marketing, les courriels transactionnels, la gestion de la relation client, les systèmes d'assistance, etc. Chaque service tiers nécessite souvent un mécanisme d'inclusion dans l'enregistrement SPF, qui compte pour une consultation, et leurs propres enregistrements SPF peuvent contenir d'autres consultations. Cela pose un problème, car l'ajout de plusieurs services peut rapidement amener le domaine à atteindre ou à dépasser la limite de 10 consultations, ce qui entraîne les problèmes de Permerror décrits ci-dessus. La gestion de ces nombreuses sources et le respect de la limite tout en s'assurant que tous les courriers légitimes sont autorisés deviennent un défi de taille.

• À propos de
• Derniers messages

Ahona Rudra

Expert en sécurité des domaines et des courriels chez PowerDMARC

Ahona est la responsable du marketing chez PowerDMARC, avec plus de 5 ans d'expérience dans l'écriture sur des sujets de cybersécurité, spécialisée dans la sécurité des domaines et des courriels. Ahona est titulaire d'un diplôme de troisième cycle en journalisme et communication, solidifiant sa carrière dans le secteur de la sécurité depuis 2019.

Derniers messages de Ahona Rudra (voir tous)

• Compromission des courriels des fournisseurs (VEC) : comment stopper les attaques provenant de fournisseurs de confiance - 3 juillet 2025
• Les e-mails marketing n'atteignent pas les boîtes de réception des clients - 2 juillet 2025
• Étude de cas DMARC MSP : Comment S-IT a automatisé la gestion de l'authentification des courriels avec PowerDMARC - 29 juin 2025