Le mécanisme neutre du SPF (?all) expliqué : Quand et comment l'utiliser
par
Temps de lecture : 5 min
Le mécanisme neutre du FPS "?tous"est un mécanisme des enregistrements SPF (Sender Policy Framework) qui aboutit à une évaluation neutre. Il indique aux serveurs de réception de ne pas prendre de décision de réussite ou d'échec sur la base de SPF.
- Exemple d'enregistrement SPF avec ?all :
v=spf1 include:_spf.google.com ?all
Dans cet exemple, le domaine inclut les paramètres SPF de Google mais se termine par "all", qui indique aux serveurs de réception d'adopter une position neutre à l'égard des autres expéditeurs. Il ne les approuve pas et ne les rejette pas, n'émettant pas de jugement clair.
Bien que techniquement valide, `?all` peut créer une ambiguïté qui affaiblit la confiance, entrave l'application de DMARC et peut conduire à des problèmes de livraison s'il n'est pas utilisé correctement.
Points clés à retenir
- Le mécanisme neutre SPF ne précise pas clairement si un courriel est légitime ou non.
- Le mécanisme ?all peut encore être utile dans certains cas, par exemple pour les tests et les anciennes configurations.
- Cependant, lorsqu'il est utilisé en production, il peut créer une ambiguïté pour les serveurs de messagerie.
- Il n'est pas recommandé d'utiliser le mécanisme neutre SPF en production, car il peut faciliter l'usurpation d'identité et provoquer des échecs d'authentification et de délivrabilité du courrier électronique.
- Pour améliorer la sécurité des e-mails de votre domaine, il est recommandé de remplacer le mécanisme ?all par le softfail (c.-à-d. ~all).
Mécanisme neutre du FPS (?tous) vs. autres mécanismes
"Le propriétaire du domaine a explicitement déclaré qu'il ne peut pas ou ne veut pas affirmer que l'adresse IP est autorisée ou non. Un résultat "Neutre" DOIT être traité exactement comme le résultat "Aucun" ; la distinction n'existe qu'à titre d'information. Traiter "Neutre" plus sévèrement que "Aucun" découragerait les propriétaires de domaines de tester l'utilisation des enregistrements SPF". - RFC 4408
Le "?tous"diffère des autres qualificateurs SPF, car il ne donne pas de résultat positif ou négatif, ce qui peut entraver l'évaluation DMARC et la prise de décision par les serveurs de messagerie.
Les "?tous"peut perturber les serveurs de messagerie destinataires, qui ne sauront pas s'ils doivent faire confiance au courrier électronique ou non. Le tableau ci-dessous fournit un résumé concis des effets et des cas d'utilisation des différents mécanismes.
| Mécanisme | Effet | Cas d'utilisation |
|---|---|---|
| ?tous (mécanisme neutre) | Neutre - pas de jugement de réussite ou d'échec | Rarement utilisé et non recommandé. Parfois utilisé lors de configurations transitoires. |
| ~tous (approche recommandée) | Échec brutal - marqué comme suspect | Utilisé lors du déploiement de SPF, car il signale les expéditeurs non autorisés sans les bloquer, ce qui permet à DMARC d'appliquer des politiques sans risquer de faux positifs. |
| -tout | Hard fail - peut être rejeté par les serveurs de messagerie | Utilisé pour une application stricte et une sécurité renforcée. À utiliser avec précaution. Assurez-vous que votre enregistrement SPF est complet avant d'appliquer -all pour éviter de rejeter des courriels légitimes. |
Quand utiliser le mécanisme neutre du FPS ?
Le mécanisme neutre SPF n'est pas recommandé pour la plupart des configurations modernes de courrier électronique. Il peut encore être utilisé dans certains cas, en faisant preuve de prudence et en planifiant à l'avance une transition vers des mécanismes plus sûrs.
Systèmes hérités
Certaines infrastructures et certains systèmes plus anciens peuvent ne pas disposer de politiques d'expéditeur claires ou d'un traitement SPF approprié. Dans de tels cas, vous aurez besoin d'une position neutre, comme avec le mécanisme neutre SPF, pour maintenir la fonctionnalité.
Phase de test
Vous pouvez également utiliser ce mécanisme lors de la mise en œuvre initiale de SPF. Il permettra aux propriétaires de domaines de surveiller le trafic de courrier électronique tout en maintenant la livraison intacte, ce qui permet de l'utiliser en toute sécurité comme point de départ.
Des cas marginaux rares
Parfois, d'autres mécanismes comme ~all ou -all peuvent causer des problèmes de délivrabilité inattendus. Pour diagnostiquer ces problèmes, vous pouvez utiliser temporairement le mécanisme ?all.
⚠️ Les mécanismes SPF sont évalués de manière séquentielle, et le fait de placer ?all avant d'autres mécanismes peut entraîner un arrêt prématuré de l'évaluation SPF, ce qui risque de contourner les vérifications prévues.
Quels sont les risques liés à l'utilisation de ?all ?
Le mécanisme ?all empêche d'obtenir des résultats clairs en matière d'authentification, ce qui nuit à la fois à la sécurité du courrier électronique (par exemple, la protection contre l'usurpation d'identité) et à la délivrabilité du courrier électronique. Les risques possibles sont les suivants :
Usurpation d'identité par courrier électronique
Puisque ?all renvoie un résultat neutre, il n'offre aucune défense contre l'usurpation d'identité. En revanche, ~all et -all renvoient des signaux d'échec identifiables. Associés à une politique DMARC appliquée, ces signaux permettent aux serveurs de réception de quarantine ou de rejeter les courriels non autorisés.
Conflits DMARC
Les résultats SPF neutres de ?all peuvent toujours être techniquement conformes à DMARC si les domaines correspondent, mais ils ne fournissent aucun signal de réussite ou d'échec, ce que DMARC exige pour prendre des mesures d'exécution.
Questions relatives à la faisabilité
Certains serveurs de messagerie interprètent le mécanisme ?all (neutre) de SPF comme une politique faible ou sans engagement. Cela peut être le signe d'une mauvaise application de l'identité de l'expéditeur, ce qui peut réduire la confiance. Les fournisseurs de messagerie tels que Gmail utilisent plusieurs signaux, et une politique SPF faible peut n'être qu'un facteur parmi d'autres.
Comment remplacer ?all par ~all ou -all
Pour améliorer la sécurité du courrier électronique de votre domaine, vous devez remplacer le mécanisme ?all par un mécanisme plus définitif. Voici les principales étapes à suivre dans ce processus.
1. Vérifier votre enregistrement SPF actuel
Utilisez le vérificateur de SPF de PowerDMARC vérificateur SPF de PowerDMARC pour vérifier votre configuration actuelle. Si vous n'avez pas d'enregistrement, notre SPF gratuit vous aide à en créer un adapté à vos sources d'envoi.r gratuit vous aide à en créer un adapté à vos sources d'envoi.
2. Remplacer ?tous par ~tous
Le mécanisme d'échec en douceur (~all) est une approche à la fois prudente et pratique. DMARC à p=reject peut toujours rejeter les courriels basés sur SPF ~all si la vérification SPF échoue (~all déclenche "fail").
3. Surveiller les rapports DMARC
Il est également important de suivre régulièrement l'activité des courriels à l'aide des rapports agrégés DMARC. L'analyseur de rapports analyseur de rapports DMARC offre des rapports DMARC conviviaux et en temps réel pour vous aider à rester informé et en sécurité.
Mauvaises configurations courantes du mécanisme neutre du SPF
Lorsque vous utilisez mal le mécanisme ?all, vous risquez d'être confronté à des failles de sécurité involontaires et à des problèmes de délivrabilité. Voici quelques erreurs fréquentes à éviter.
Erreur 1 : Utiliser ?all dans la production
Les politiques neutres n'offrent aucune protection. Cela permet à des courriels frauduleux d'apparaître comme légitimes. Par conséquent, votre réputation et la sécurité de vos destinataires peuvent être menacées.
Erreur 2 : Combiner ?all avec des politiques DMARC strictes
Une politique DMARC telle que p=reject dépend de la capacité de SPF (ou DKIM) à fournir une réponse claire de réussite ou d'échec. Si SPF est neutre, DMARC ne saura pas quoi faire, et un échec DMARC inutile peut se produire.
Erreur 3 : Supposer que ?tout est équivalent à ~tout
~all signale au moins les expéditeurs non autorisés. Le mécanisme ?all, quant à lui, n'apporte aucun jugement. Nombreux sont ceux qui confondent les deux, ce qui entraîne des problèmes d'authentification et de distribution du courrier électronique.
FAQ
1. Est-ce la même chose que de ne pas avoir d'enregistrement SPF ?
Non. ?tous indiquent une position neutre. L'absence d'enregistrement SPF, en revanche, ne fournit aucune indication. Les serveurs de messagerie les traitent différemment.
2. Puis-je utiliser ?all avec DMARC ?
Techniquement, oui, mais c'est déconseillé. DMARC s'appuie sur des résultats clairs de réussite ou d'échec du SPF pour l'application de la loi. L'utilisation de ?all aboutit souvent à des résultats neutres, ce qui réduit l'efficacité du DMARC.
Réflexions finales
Le mécanisme ?all dans les enregistrements SPF peut sembler inoffensif à première vue, mais il peut être dangereux. Il n'est pas recommandé dans la pratique et peut exposer votre domaine à l'usurpation d'identité et réduire l'efficacité des politiques DMARC.
Si vous utilisez actuellement ?all, prévoyez de le remplacer par ~all (soft fail) pour une meilleure sécurité et une authentification plus fiable du courrier électronique.
Pour une fiabilité SPF à long terme, simplifiez la gestion et évitez les limites de recherche DNS grâce à la technologie PowerDMARC SPF hébergé solution. Elle est conçue pour gérer des enregistrements complexes et pour optimiser automatiquement l'authentification de domaines sans erreur.
Expert en sécurité des domaines et des courriels chez PowerDMARC
Yunes est chef d'équipe des opérations chez PowerDMARC et possède des connaissances approfondies en matière d'authentification et de sécurité des courriels. Yunes est certifié Microsoft Azure Administrator Associate et possède des certifications CompTIA A+ et bien d'autres encore.
Derniers messages de Yunes Tarada (voir tous)
