Posts

Pourquoi l'authentification SPF échoue-t-elle ? Comment réparer l'échec de SPF ?

Avez-vous déjà vu un courriel échouer au test SPF ? Si oui, je vais vous expliquer exactement pourquoi l'authentification SPF échoue. Sender Policy Framework, ou SPF, est l'une des normes de vérification des e-mails que nous utilisons tous depuis des années pour arrêter le spam. Même si vous n'en êtes pas conscient, je parie que si je vérifiais les paramètres de votre compte de connexion à Facebook, je verrais probablement que vous avez choisi l'option " opt-in " pour " email from friends only ". C'est effectivement la même chose que le SPF.

Qu'est-ce que l'authentification SPF ?

SPF est un protocole d'authentification du courrier électronique utilisé pour vérifier que l'expéditeur du courrier électronique correspond à son nom de domaine dans le champ "From :" du message. Le MTA d'envoi utilise le DNS pour interroger une liste préconfigurée de serveurs SPF afin de vérifier si l'IP d'envoi est autorisée à envoyer des courriels pour ce domaine. Il peut y avoir des incohérences dans la manière dont les enregistrements SPF sont configurés, ce qui est essentiel pour comprendre pourquoi les courriels peuvent échouer à la vérification SPF, et quel rôle vous pouvez jouer pour vous assurer que des problèmes ne se produisent pas dans vos propres efforts de marketing par courriel ou lorsque vous envoyez des coupons de marketing par courriel pour gagner des clients.

Pourquoi l'authentification SPF échoue : Aucun, Neutre, Hardfail, Softfail, TempError et PermError.

Les échecs d'authentification SPF peuvent se produire pour les raisons suivantes :

  • Le MTA récepteur ne trouve pas d'enregistrement SPF publié dans votre DNS.
  • Vous avez plusieurs enregistrements SPF publiés dans votre DNS pour le même domaine.
  • Vos ESP ont modifié ou ajouté des adresses IP qui n'ont pas été mises à jour dans votre enregistrement SPF.
  • Si vous dépassez la limite de 10 consultations de DNS pour SPF
  • Si vous dépassez le nombre maximum de recherche de vide autorisé de 2
  • La longueur de votre enregistrement SPF aplati dépasse la limite de 255 caractères SPF.

Les scénarios ci-dessus expliquent pourquoi l'authentification SPF échoue. Vous pouvez surveiller vos domaines avec notre analyseur DMARC pour obtenir des rapports sur les échecs d'authentification SPF. Lorsque le rapport DMARC est activé, le MTA récepteur renvoie l'un des résultats d'échec d'authentification SPF suivants pour l'e-mail, en fonction de la raison pour laquelle votre e-mail a échoué. Apprenons à mieux les connaître :

Types de qualificatifs d'échec SPF

Voici les types de qualificatifs d'échec SPF, chacun d'entre eux étant ajouté comme préfixe avant le mécanisme d'échec SPF :

"+" "Pass"
"-" "Fail"
"~" "Softfail"
" ?" "Neutre"

En quoi cela est-il important ? Si votre courriel échoue au test SPF, vous pouvez choisir la rigueur avec laquelle vous voulez que les destinataires le traitent. Vous pouvez spécifier un qualificateur pour "passer" les messages qui échouent à la vérification (les livrer), "échouer" la livraison, ou prendre un point de vue "neutre" (ne rien faire).

Cas 1 : Le résultat de SPF None est retourné.

Dans le premier cas de figure, si le serveur de messagerie récepteur effectue une recherche DNS et ne trouve pas le nom de domaine dans le DNS, un résultat nul est renvoyé. Aucun résultat n'est également renvoyé si aucun enregistrement SPF n'est trouvé dans le DNS de l'expéditeur, ce qui implique que l'expéditeur n'a pas configuré l'authentification SPF pour ce domaine. Dans ce cas, l'authentification SPF pour vos e-mails échoue.

Générez votre enregistrement SPF sans erreur maintenant avec notre outil gratuit de génération d'enregistrements SPF pour éviter cela.

Cas 2 : Résultat neutre de SPF est retourné

Lors de la configuration du SPF pour votre domaine, si vous avez apposé un mécanisme ?all à votre enregistrement SPF, cela signifie que, quelles que soient les conclusions des contrôles d'authentification SPF pour vos courriels sortants, le MTA récepteur renvoie un résultat neutre. Cela se produit parce que lorsque vous avez votre SPF en mode neutre, vous ne spécifiez pas les adresses IP qui sont autorisées à envoyer des e-mails en votre nom et vous autorisez les adresses IP non autorisées à les envoyer également.

Cas 3 : Résultat de l'échec de la SPF Softfail

Tout comme le SPF neutre, le SPF softfail est identifié par le mécanisme ~all qui implique que le MTA récepteur acceptera le courrier et le délivrera dans la boîte de réception du destinataire, mais il sera marqué comme spam, dans le cas où l'adresse IP ne figure pas dans l'enregistrement SPF trouvé dans le DNS, ce qui peut être une raison pour laquelle l'authentification SPF échoue pour votre courrier électronique. Voici un exemple d'échec de l'authentification SPF :

 v=spf1 include:spf.google.com ~all

Cas 4 : Résultat de l'échec de la SPF

SPF hardfail, également connu sous le nom de SPF fail, désigne le cas où les MTA de réception rejettent les e-mails provenant d'une source d'envoi qui n'est pas répertoriée dans votre enregistrement SPF. Nous vous recommandons de configurer SPF hardfail dans votre enregistrement SPF, si vous voulez vous protéger contre l'usurpation de domaine et l'usurpation d'adresse électronique. Vous trouverez ci-dessous un exemple de SPF hardfail :

v=spf1 include:spf.google.com -all

Cas 5 : SPF TempError (erreur temporaire de SPF)

L'une des raisons très courantes et souvent inoffensives de l'échec de l'authentification SPF est SPF TempError (erreur temporaire) qui est due à une erreur DNS telle qu'un dépassement de délai DNS pendant qu'une vérification de l'authentification SPF est effectuée par le MTA récepteur. Il s'agit donc, comme son nom l'indique, d'une erreur temporaire renvoyant un code de statut 4xx qui peut provoquer un échec temporaire de SPF, mais qui donne un résultat positif lors d'une nouvelle tentative ultérieure.

Cas 6 : SPF PermError (erreur permanente de SPF)

Un autre résultat courant auquel les erreurs de domaine sont confrontées est SPF PermError. C'est pourquoi l'authentification SPF échoue dans la plupart des cas. Cela se produit lorsque votre enregistrement SPF est invalidé par le MTA récepteur. Il y a de nombreuses raisons pour lesquelles SPF peut s'interrompre et être rendu invalide par le MTA lors des recherches DNS :

  • Dépassement de la limite de 10 recherches SPF
  • Syntaxe d'enregistrement SPF incorrecte
  • Plus d'un enregistrement SPF pour le même domaine
  • Dépassement de la limite de longueur des enregistrements SPF, fixée à 255 caractères.
  • Si votre enregistrement SPF n'est pas à jour par rapport aux changements effectués par vos ESPs

Remarque : Lorsqu'un MTA effectue une vérification SPF sur un courriel, il interroge le DNS ou effectue une recherche DNS pour vérifier l'authenticité de la source du courriel. Idéalement, dans SPF, vous êtes autorisé à effectuer un maximum de 10 recherches DNS, au-delà desquelles SPF échouera et renverra un résultat PermError.

Comment l'aplatissement dynamique du SPF peut-il résoudre le SPF PermError ?

Contrairement aux autres erreurs SPF, SPF PermError est beaucoup plus délicat et compliqué à résoudre. PowerSPF vous aide à l'atténuer facilement grâce à l'aplatissement automatique du SPF. Il vous aide :

  • Rester sous la limite stricte du SPF
  • Optimisez instantanément votre enregistrement SPF
  • Aplatissez votre dossier en une seule déclaration d'inclusion
  • Assurez-vous que votre enregistrement SPF est toujours mis à jour en fonction des modifications apportées par vos ESP.

Vous voulez tester si vous avez configuré correctement le SPF pour votre domaine ? Essayez dès aujourd'hui notre outil gratuit de recherche d'enregistrements SPF!

/par

La différence entre SPF -all et SPF ~all | SPF -all vs ~all

SPF existe dans le DNS de votre domaine sous la forme d'un enregistrement TXT avec un ensemble de mécanismes et de modificateurs qui correspondent à des instructions spécifiques. Le mécanisme SPF all est présent à l'extrémité droite d'un enregistrement SPF, précédé de "-" ou "~". Examinons la différence entre les mécanismes SPF -all et ~all afin de déterminer quand vous devez les configurer.

SPF -all vs ~all

Les mécanismes SPF -all et ~all signifient tous deux "NOT PASS" pour l'authentification SPF. Ces derniers temps, pour une majorité de fournisseurs de services de messagerie, il n'y a pas de différence entre les mécanismes -all et ~all, et le même résultat est renvoyé. Cependant, ce n'était pas le cas il y a quelques années.

Comment le mécanisme SPF all (Softfail vs Fail) fonctionnait-il avant DMARC ?

DMARC a été créé longtemps après l'arrivée de SPF sur le marché en tant que protocole standard d'authentification des e-mails. À cette époque, le mécanisme SPF -all softfail fonctionnait de la manière suivante : 

Supposons que votre enregistrement SPF soit : 

v=spf1 include:spf.domain.com ~all (où ~all signifie SPF Softfail)

Le serveur de messagerie de votre destinataire aurait effectué une recherche DNS pour interroger le DNS de l'expéditeur sur son enregistrement SPF. Si le domaine Return-path de l'e-mail n'était pas répertorié dans l'enregistrement de l'expéditeur, le serveur de réception aurait renvoyé un résultat SPF "NOT PASS" mais aurait livré l'e-mail dans la boîte de réception du destinataire.

Supposons maintenant que votre enregistrement SPF soit : 

v=spf1 include:spf.domain.com -all (où -all signifie SPF Fail)

Le serveur de messagerie de votre destinataire aurait effectué une recherche DNS pour interroger le DNS de l'expéditeur sur son enregistrement SPF. Si le domaine Return-path de l'e-mail n'était pas répertorié dans l'enregistrement de l'expéditeur, le serveur de réception aurait renvoyé un résultat SPF "NOT PASS", mais dans ce cas, l'e-mail aurait été a été rejeté et non délivré dans la boîte de réception du destinataire.

En savoir plus sur l'histoire de Sender Policy Framework. 

Comment les fournisseurs de services de messagerie gèrent-ils désormais le mécanisme SPF -all vs ~all ?

Bien que vous soyez libre d'utiliser SPF -all ou ~all pour la plupart des fournisseurs de boîtes aux lettres à l'heure actuelle sans avoir à vous soucier des échecs de livraison pour les e-mails légitimes, il peut arriver qu'un serveur rejette votre courriel en cas d'utilisation de l'attribut -all..

Pour être plus sûr, vous pouvez éviter d'utiliser le mécanisme SPF hard fail -all lors de la création de votre enregistrement SPF. Voici comment procéder :

  • Ouvrez le générateur d'enregistrements SPF de PowerDMARC générateur d'enregistrements SPF pour commencer à créer un enregistrement gratuitement
  • Après avoir indiqué les adresses IP et les domaines des expéditeurs de vos courriels, passez à la dernière section destinée à indiquer aux serveurs de courriels la rigueur avec laquelle ils doivent vérifier vos courriels.
  • Choisissez l'option "Soft-fail" avant de cliquer sur le bouton "Generate SPF Record".

Que recommandons-nous ? SPF -all ou SPF ~all

Les problèmes de délivrabilité des e-mails liés au mécanisme SPF -all peuvent se produire en de très rares occasions. Il ne s'agit pas d'un problème récurrent que vous rencontrerez souvent. Pour vous assurer que vous ne rencontrerez jamais ce problème, vous pouvez prendre les mesures suivantes :

  • Configurer DMARC pour vos courriels, et activez le rapport DMARC
  • Réglez votre politique DMARC sur la surveillance et examinez attentivement vos résultats d'authentification SPF pour repérer toute incohérence dans la délivrabilité des e-mails.
  • Si tout est bon, vous pouvez utiliser le mécanisme -all dans votre enregistrement SPF. Nous recommandons d'utiliser l'attribut hard fail car il affirme que vous êtes confiant quant à l'authenticité de vos emails, ce qui peut améliorer la réputation de votre domaine.

Si vous n'êtes pas certain d'utiliser le SPF -all, vous pouvez suivre les étapes suivantes :

  • Configurer un enregistrement SPF en utilisant le mécanisme ~all
  • Configurer DMARC pour vos e-mails et activer le rapport DMARC
  • Définissez votre politique DMARC pour rejeter

Dépannage d'autres erreurs SPF

Lorsque vous utilisez des outils en ligne, vous rencontrez souvent le message "Aucun enregistrement SPF trouvé"Il s'agit d'un état d'erreur courant résultant d'un résultat nul renvoyé lorsqu'un serveur recherche l'enregistrement SPF de votre domaine. Nous avons couvert un article en détail parlant de ce problème et aidant les utilisateurs à le résoudre. Cliquez sur le texte lié pour en savoir plus !

Si vous avez mis en place DMARC pour votre domaine en plus de SPF, les serveurs de messagerie vérifieront la politique DMARC de votre domaine pour déterminer comment vous souhaitez que les courriels dont l'authentification échoue soient traités. Cette politique DMARC déterminera si vos e-mails seront livrés, mis en quarantaine ou rejetés. 

Le rejet DMARC permet de protéger votre domaine contre diverses attaques par usurpation d'identité telles que l'usurpation d'identité, le phishing et les ransomwares.

/par

Comment corriger " SPF Softfail Domain Does Not Designate IP as Permitted Sender " ?

Si votre entreprise utilise ses propres domaines et gère ses courriers électroniques, il y a de fortes chances qu'elle rencontre des problèmes de courrier électronique et qu'elle soit confrontée à l'erreur " SPF Softfail Domain Does Not Designate IP as Permitted Sender ". Il est crucial que les entreprises désignent correctement les adresses IP utilisées pour envoyer des e-mails en leur nom comme expéditeur autorisé dans l'enregistrement SPF.

Qu'est-ce que le SPF ?

SPF ou Sender Policy Framework est une norme d'authentification du courrier électronique qui protège les organisations contre l'usurpation d'identité. Un attaquant peut utiliser le domaine et la marque d'une entreprise pour envoyer de faux messages à ses clients. Ces courriels de phishing semblent suffisamment authentiques pour convaincre les clients et les faire tomber dans une escroquerie sur Internet au nom de l'entreprise. Cela nuit à la crédibilité de la marque de l'entreprise et à son image publique. Le SPF peut être vu comme une liste de domaines de confiance d'une entreprise d'où peuvent provenir des communications authentiques.

Comment vérifier si votre domaine est un expéditeur autorisé ?

La première étape pour résoudre l'erreur "SPF Softfail Domain Does Not Designate IP as Permitted Sender" est de vérifier l'autorité de l'expéditeur. Pour ce faire :

Étape 1: Connectez-vous au compte de messagerie du domaine de l'entreprise, disons, [email protected]

Étape 2: Envoyez un courriel à un autre compte de courriel auquel vous avez accès ; il peut s'agir d'un domaine externe comme Gmail, Yahoo, Hotmail, ou autres.

Étape 3: Connectez-vous au compte de messagerie où vous avez envoyé le premier courrier, puis consultez les en-têtes de ce courrier. Il sera marqué comme "Show original".

Ensuite, vous verrez quelque chose de similaire à ceci. Remarquez le message SPF Softfail.

-Message original -

X-Received : ...

sam, 13 mars, 2022 11:01:19 IST

Return-Path : [email protected]

Received : de mymy2.spfrecords.com (mymy2.spfrecords.com [60.130.71.223])

par mx.google.com avec l'identifiant ESMTPS 

*id*

Pour [email protected]

Received SPF : softfail (google.com : le domaine de transition [email protected] ne désigne pas 60.130.71.223 comme expéditeur autorisé) client-ip=60.130.71.223 ; 

Résultats de l'authentification : mx.google.com ;

Spf = softfail (google.com : le domaine de transition [email protected] ne désigne pas 60.130.71.223 comme expéditeur autorisé) client-ip=60.130.71.223 ; 

*fin du message d'en-tête

Note: Si vous observez "Received-SPF : pass" dans l'en-tête, alors le domaine que vous utilisez pour envoyer les mails est authentifié et est déjà ajouté à votre enregistrement SPF, et vous n'avez rien à craindre. Cependant, comme indiqué ci-dessus, il y a un problème de softfail. Nous allons maintenant voir comment résoudre ce problème.

Que signifie "SPF Softfail Domain Does Not Designate IP as Permitted Sender" ?

L'expéditeur de votre courriel a une IP hôte qui ressemble à ceci :

30.10.323.005

Si cette adresse IP du domaine expéditeur ne figure pas dans l'enregistrement SPF de votre domaine, le serveur de réception des e-mails ne parvient pas à identifier l'IP désignée comme un expéditeur autorisé. Le serveur interprète automatiquement le message comme provenant d'une source non autorisée. C'est une raison possible pour laquelle le SPF a échoué pour le message. Il y a une forte probabilité d'échec de DMARC si le système d'authentification du courrier électronique dépend uniquement de SPF pour la vérification de la source (et non de DKIM). 

Dans de telles circonstances, si votre politique de protocole est réglée sur le rejet, votre message ne sera jamais remis ! Le propriétaire du domaine doit donc prendre des mesures rapides et efficaces pour résoudre le problème "SPF Softfail Domain Does Not Designate IP as Permitted Sender".

Comment inclure une IP comme expéditeur autorisé pour SPF ?

La solution à ce problème peut être divisée en plusieurs étapes : 

1. Créez une liste de sources d'envoi pour votre domaine. Vous pouvez utiliser une liste d'adresses e-mail basée sur votre domaine, ainsi que des sources d'envoi tierces pour les transactions par e-mail.

2. Maintenant, identifiez les adresses IP des hôtes de ces sources d'envoi. 

Comment trouver les adresses IP liées à vos sources d'envoi d'e-mails ?

C'est assez simple ! Pour trouver l'adresse IP de votre source d'envoi, ouvrez le courriel et affichez l'en-tête complet de votre courriel. Pour ce faire, vous devez cliquer sur les trois points situés dans le coin supérieur droit de votre courriel pour afficher le menu déroulant, et sélectionner "Afficher l'original".

Sur le message d'origine, faites défiler vers le bas jusqu'à la rubrique Reçu vous pourrez repérer l'adresse IP de l'expéditeur initial, comme indiqué ci-dessous :

3. Utilisez notre Générateur d'enregistrements SPF pour générer un enregistrement SPF gratuit pour votre domaine.

  • Dans le générateur d'enregistrements, ajoutez toutes les adresses IP que vous souhaitez voir authentifiées pour envoyer des e-mails et des communications au nom de l'entreprise.
  • Ajoutez tout serveur tiers ou service de livraison externe comme source d'envoi autorisée pour votre domaine. De cette façon, tous les mails envoyés via des serveurs tiers passeront également l'authentification SPF.

4. Une fois que vous avez utilisé le générateur d'enregistrement SPF pour générer l'enregistrement SPF pour votre domaine avec tous les domaines et adresses IP de confiance ajoutés, il ne reste plus qu'à mettre en œuvre le SPF en le publiant sur votre DNS. Voici comment vous pouvez y parvenir :

  • Connectez-vous à votre console de gestion DNS
  • Ensuite, naviguez vers le domaine de votre choix (le domaine pour lequel vous essayez d'ajouter/modifier l'enregistrement SPF).
  • Spécifiez que votre type de ressource est "TXT".
  • Spécifiez le nom d'hôte comme "_spf".
  • Collez la valeur de votre enregistrement SPF généré. 
  • Sauvegarder les changements pour configurer SPF pour votre domaine

Note: Les noms ou en-têtes ci-dessus peuvent varier en fonction de la console de gestion DNS que vous utilisez pour votre entreprise..

De cette façon, les propriétaires de domaines peuvent s'assurer que toutes leurs adresses IP et domaines de confiance qu'ils pourraient utiliser pour envoyer des communications au nom de l'entreprise sont ajoutés au serveur, et une erreur similaire où le domaine SPF Softfail ne désigne pas l'IP comme expéditeur autorisé ne se produira pas. 

Comment utiliser efficacement la norme SPF ?

La seule façon de consolider la technologie SPF d'une entreprise est de l'intégrer à la norme DMARC. Voici les avantages de cette démarche,

1. DMARC = SPF + DKIM

Les protocoles d'authentification des e-mails tels que DMARC sont configurés en ajoutant un enregistrement TXT à votre DNS. Outre la configuration d'une politique pour les e-mails de votre domaine, vous pouvez également tirer parti de DMARC pour activer un mécanisme de rapport qui vous enverra une foule d'informations sur vos domaines, vos fournisseurs et vos sources d'e-mails.

DMARC peut vous aider à utiliser les technologies SPF (Sender Policy Framework) et DKIM (DomainKeys Identified Mail) en tandem pour donner à votre domaine une protection encore meilleure contre l'usurpation.

Note: Ceci est recommandé, mais pas obligatoire. DMARC peut fonctionner avec l'alignement des identifiants SPF ou DKIM.

2. Rapport et retour d'information avec PowerDMARC

Ni SPF ni DKIM ne donnent au propriétaire du domaine un retour d'information sur les courriels dont l'authentification échoue. DMARC vous envoie directement des rapports détaillés, que la plateforme PowerDMARC convertit en graphiques et tableaux faciles à lire.

3. Contrôler ce qui arrive aux courriels non authentifiés 

DMARC vous permet, à vous, le propriétaire du domaine, de décider si un email qui échoue à la validation va dans la boîte de réception, dans les spams, ou est rejeté. Avec PowerDMARC, il vous suffit de cliquer sur un bouton pour définir votre politique DMARC, c'est aussi simple que cela.

Les expéditeurs non autorisés peuvent constituer une menace dangereuse pour la sécurité de vos clients ainsi que pour l'image et la valeur de marque de votre entreprise. Protégez vos clients contre le phishing et les escroqueries en incorporant DMARC dans votre entreprise, et ne permettez que les courriers provenant d'expéditeurs authentifiés de leur parvenir.

/par