Un domaine réputé ou un service d’envoi partagé peut faire partie d’un chemin de message abusif. La question utile n’est pas de savoir si l’infrastructure est généralement fiable. Il s'agit de savoir si ce message particulier était autorisé à utiliser l'identité authentifiée. L'authentification et l'autorisation commerciale répondent à différentes questions.
Définir l'autorité à réutiliser
Une boîte aux lettres compromise peut envoyer via sa route authentifiée ordinaire. Une autorisation de réseau trop large peut admettre une source involontaire. Un relais peut signer un message après l'avoir accepté selon une règle d'admission insuffisamment précise. Ces mécanismes ont des propriétaires et des recours différents. Ne les réduisez pas à une seule affirmation inexpliquée de détournement de réputation.
La recherche originale BreakSPF examine le permissif SPF configurations et infrastructure partagée. Son modèle de menace fait de l’accès au réseau source une condition centrale. Il s'agit d'une limite de déploiement et non d'une preuve qu'un attaquant peut falsifier des informations. Signature DKIM. Article BreakSPF, Section III. Considérez les mesures du document comme une recherche historique et non comme un inventaire actuel des services vulnérables.
Construire un modèle de menace précis
Écrivez séparément le domaine protégé, l'identifiant authentifié, l'ensemble de sources autorisé, la capacité de l'attaquant et la décision du récepteur. Dans le scénario limité ici, brand.test autorise 192.0.2.0/24 pour SPF . L'application approuvée utilise 192.0.2.10 , tandis qu'un hypothétique locataire involontaire peut provenir de 192.0.2.99 . Les deux adresses se situent dans la plage publiée. La question de savoir si un tel accès des locataires existe dans un service réel nécessite des preuves distinctes.
SPF vérifie l'autorisation de la source pour son identité évaluée. Il n’identifie pas l’humain derrière une adresse IP partagée. Si l'identité SPF transmise correspond également au domaine de l'auteur, ce chemin peut satisfaire DMARC sans DKIM. RFC 7208 et RFC 9989. Une évaluation réussie peut donc révéler qu'une trop grande autorité a été accordée, plutôt qu'un destinataire ignorant la règle de réussite.
Comparez trois cas d’autorisation écrite
Supposer visible depuis alerts@brand.test , non vide COURRIER DE bounce@brand.test , pas de signature DKIM et une évaluation DMARC par ailleurs éligible. Comparer hypothétique Enregistrements SPF v=spf1 ip4:192.0.2.0/24 -all and v=spf1 ip4:192.0.2.10/32 -all. No other mechanisms exist in these examples.
- Source approuvée 192.0.2.10 : incluse dans les deux préfixes réseau ; SPF réussit et s'aligne sur brand.test, de sorte que le message illustratif réussit DMARC dans les deux cas.
- Source involontaire 192.0.2.99 : incluse par le /24 mais pas par le /32 ; SPF ne passe que sous le large enregistrement. Sans signature DKIM , le résultat DMARC stipulé est une réussite sous /24 et un échec sous /32.
- Source externe 198.51.100.10 : inclus par aucun des deux préfixes ; -all les rendements SPF échouent dans les deux cas. Sans signature DKIM , le résultat DMARC stipulé est un échec dans les deux cas.
Il s'agit d'adhésions à préfixe écrites et alignement déductions, pas un analyseur SPF en cours d'exécution, une observation DNS ou une reproduction de BreakSPF. Le contrôle des sources est supposé, non démontré. Aucun message externe ou service en direct n'a été testé. La technique inter-protocoles utilisée dans cet article ne fait pas partie de cet exemple pédagogique.
Un seul mécanisme aligné de passage peut satisfaire la condition de réussite DMARC d'un message. Cela ne rend pas le déploiement SPF uniquement adéquat : la section 7.4 de la RFC9989 nécessite DKIM valide pour la publication des domaines. p=reject, et la section 8 traite de la pleine participation. Il s’agit de tâches de déploiement distinctes, et non d’une porte de passage supplémentaire par message.
Fixer la limite de responsabilité
Avant de restreindre un véritable enregistrement SPF , inventoriez chaque expéditeur légitime et suivez la configuration prise en charge par le fournisseur. Une source dédiée n’est utile que si elle est réellement exclusive et entretenue. Confirmez que le service d'envoi lie les clients à leurs identités autorisées ; vérifiez la configuration DKIM et supprimez les autorités obsolètes via le contrôle des modifications.
Surveillez les échecs spécifiques à l'itinéraire après la modification, conservez un plan de récupération et documentez les expéditeurs inconnus. Ne remplacez pas un enregistrement étendu par une liste IP devinée à partir de cet exemple. La leçon est de concilier l’autorisation avec la propriété réelle du service, et non de copier DNS de démonstration en production.