Sender Policy Framework (SPF) : une couche de protection dans l'infrastructure de messagerie

Publié: 2020-03-04

Avez-vous déjà eu quelqu'un (de manière ludique ou malveillante) qui a pris votre téléphone et envoyé un SMS à quelqu'un se faisant passer pour vous ? Il ne se sent pas très bien, n'est-ce pas? Même après avoir clarifié la vérité avec le destinataire, il se méfiera probablement de tous vos messages à l'avenir. Et vous ferez probablement beaucoup plus attention à qui vous laisserez emprunter votre téléphone. La confiance a été brisée.

Un scénario similaire est possible dans le monde du courrier électronique, et les hameçonneurs potentiels n'ont pas besoin de votre nom d'utilisateur et de votre mot de passe pour se faire passer pour votre entreprise. Effrayant, non ?

Heureusement, nous connaissons une astuce simple et pas si secrète pour protéger la réputation de votre marque. C'est ce qu'on appelle Sender Policy Framework (SPF), et c'est une bouée de sauvetage pour la réputation des e-mails.

Lorsqu'un courrier électronique est envoyé d'un serveur à un autre, le protocole de transfert de courrier simple (SMTP) est utilisé pour transmettre un message de l'expéditeur au destinataire. En tant que service SMTP, Twilio SendGrid facilite ce processus.

Une faiblesse de sécurité dans l'infrastructure de messagerie est la capacité de tout expéditeur ou hôte à s'identifier, ainsi que son e-mail, comme n'importe quel domaine qu'il souhaite (un peu comme la façon dont les gens ont créé des tonnes de comptes Twitter de Donald Trump). Il est donc difficile pour les destinataires de croire qu'un message provient réellement de la personne dont il est censé provenir. Cela rend également les expéditeurs mal à l'aise de savoir que n'importe qui peut envoyer du courrier à partir de leur domaine et potentiellement nuire à la réputation de leur marque.

Les destinataires perdent confiance dans l'authenticité des e-mails et les expéditeurs sont des imposteurs paranoïaques qui se font passer pour leur marque - ce n'est bon pour personne ! Une partie de la solution est l'enregistrement SPF qui est stocké dans un enregistrement txt dans le DNS. Dans cet article, nous allons explorer tout ce qui concerne le SPF - de ce que c'est à la découverte d'erreurs avec les vôtres, nous couvrons tout.

Qu'est-ce qu'un enregistrement SPF ?

SPF signifie Sender Policy Framework. Il s'agit d'une méthode d'authentification des e-mails qui permet d'identifier les serveurs de messagerie autorisés à envoyer des e-mails à partir d'un domaine particulier. Grâce à ce protocole de validation, les FAI peuvent déterminer quand les usurpateurs et les hameçonneurs essaient de falsifier les e-mails de votre domaine pour envoyer des e-mails malveillants à vos utilisateurs.

Avec SPF, les destinataires peuvent être sûrs que les e-mails qu'ils reçoivent proviennent de la personne qu'ils attendent. Et les expéditeurs peuvent avoir l'esprit tranquille en sachant que les hameçonneurs n'usurpent pas les e-mails ou n'hameçonnent pas leur public à partir de leur marque.

Plus techniquement, un enregistrement SPF est une courte ligne de texte que l'administrateur d'un domaine ajoute à son enregistrement txt. L'enregistrement txt est stocké dans le DNS (système de noms de domaine) avec leurs enregistrements A, PTR et MX. Un enregistrement SPF ressemble à ceci :

"v=spf1 ip4:12.34.56.78 include:example.com -all"

Comment fonctionne le FPS

La ligne de texte ci-dessus est utilisée pour indiquer au serveur SMTP de réception quels hôtes sont autorisés à envoyer du courrier à partir d'un domaine donné.

L'enregistrement SPF est généralement vérifié très tôt dans la conversation SMTP, bien avant que le corps du message n'ait été transmis. Lors d'une tentative d'envoi d'un message, une connexion TCP est ouverte entre l'expéditeur et le serveur de réception.

Une fois la connexion établie, une commande HELO est émise, qui indique essentiellement au serveur de réception quel domaine tente de lui envoyer du courrier. Ceci est suivi d'une commande MAIL FROM qui indique au serveur de réception de quelle adresse e-mail provient le message. Le domaine trouvé dans la commande MAIL FROM (également connu sous le nom d'enveloppe de et chemin de retour) est le domaine utilisé pour la vérification des enregistrements SPF.

Supposons donc qu'un message ait été reçu et que l'adresse MAIL FROM soit [email protected]. Le serveur de réception vérifiera les enregistrements DNS publics pour example.com et recherchera un enregistrement TXT commençant par v=spf1. S'il n'y a pas d'enregistrement TXT commençant par v=spf1, l'authentification réussira. S'il y a plus d'un enregistrement TXT avec v=spf1, une erreur peut se produire.

Supposons qu'un soit trouvé, et il ressemble à notre exemple d'avant :

"v=spf1 ip4:12.34.56.78 include:example.com -all"

Le serveur de réception va maintenant vérifier si l'adresse IP du client SMTP essayant d'envoyer le message est incluse dans l'enregistrement SPF. Si l'adresse IP est répertoriée, le message passera l'authentification SPF.

Les choses sérieuses : décomposer chaque élément de l'enregistrement SPF

Un enregistrement SPF est composé de divers mécanismes, notamment :

INCLURE

Toujours suivi d'un nom de domaine. Lorsque le serveur de réception rencontre un mécanisme d'inclusion, l'enregistrement SPF de ce domaine est vérifié. Si l'adresse IP des expéditeurs apparaît dans cet enregistrement, le courrier est authentifié et la vérification SPF est terminée. S'il n'est pas trouvé, la vérification SPF passe au mécanisme suivant.

UNE

Également suivi d'un nom de domaine. Cependant, dans ce cas, le SPF vérifie simplement les adresses IP associées à ce domaine. S'il correspond à l'adresse IP de l'expéditeur, il réussit et la vérification SPF s'arrête. Sinon, il passe au mécanisme suivant.

MX

Similaire à « A ». Il est toujours suivi d'un nom de domaine. Si le domaine répertorié correspond à l'adresse IP du client expéditeur, l'authentification réussit et la vérification SPF est effectuée. Sinon, il passe au mécanisme suivant.

IP4 et IP6

Toujours suivi d'une adresse IP spécifique ou d'une plage CIDR. Si l'adresse IP du client expéditeur est répertoriée après tout mécanisme IP4 ou IP6, l'authentification réussit et la vérification SPF est effectuée. Sinon, il passe au mécanisme suivant.

RPT

Ne doit jamais être inclus dans les enregistrements SPF. Pour certaines raisons techniques, ils sont sujets aux erreurs et coûtent beaucoup de mémoire et de bande passante pour les serveurs de réception à résoudre. Certains serveurs échoueront une authentification SPF basée sur la présence d'un mécanisme PTR.

RÉORIENTER

Bien qu'il s'agisse techniquement d'un modificateur et non d'un mécanisme, cela permet à l'administrateur d'un domaine de pointer un domaine vers l'enregistrement SPF d'un autre domaine. Si la fonction REDIRECT est utilisée, aucun autre mécanisme ne peut être inclus dans l'enregistrement SPF, y compris le mécanisme "tous". Exemple d'enregistrement de redirection : "v=spf1 redirect:example.com"

Les mécanismes "INCLUDE", "A", "MX", "PTR", "EXISTS" et "REDIRECT" nécessitent tous des recherches DNS, il ne peut donc pas y en avoir plus de 10. Cela semble assez simple, mais cela inclut également les recherches DNS imbriquées, ce qui signifie qu'un "INCLUDE" qui mène à un autre enregistrement SPF qui a deux autres mécanismes "INCLUDE" compterait comme trois recherches DNS. Ils s'additionnent vite !

Qu'en est-il des clients Twilio SendGrid ?

La plupart de nos expéditeurs ont mis en place un CNAME qui pointe leur domaine d'envoi vers sendgrid.net. Cela signifie que le serveur de réception voit le CNAME pointant vers sendgrid.net et vérifie plutôt cet enregistrement SPF. Ne soyez donc pas surpris si la plupart des enregistrements SPF que vous interrogez sont identiques.

Pour plus de questions spécifiques à Twilio SendGrid, consultez notre page de documentation Sender Policy Framework. Il contient des réponses supplémentaires à certaines questions et scénarios courants.

Comment vérifier mon enregistrement SPF ?

Tout le monde n'utilise pas l'authentification SPF, mais les destinataires qui rejettent en raison d'un échec SPF rejetteront la livraison. Certains destinataires peuvent également mettre en quarantaine le courrier qui échoue au SPF sans le bloquer.

Chaque enregistrement SPF sera un peu différent, mais vous devez vérifier que vous avez bien compris. Voici trois outils qui peuvent vous aider à valider vos enregistrements :

Outils de test SPF de Scott Kitterman : vérifiez si un enregistrement SPF existe déjà pour votre domaine, vérifiez sa validité ou testez ses performances.
OpenSPF.org : Passez en revue une série de formulaires et de testeurs basés sur les e-mails.
Vérification des enregistrements SPF : la vérification des enregistrements SPF agit comme une recherche et un validateur d'enregistrements SPF. Il recherchera un enregistrement SPF pour le nom de domaine interrogé et exécutera des tests de diagnostic sur l'enregistrement, mettant en évidence les erreurs susceptibles d'influencer la délivrabilité des e-mails.
SPF Wizard : SPF Wizard est un outil de génération d'enregistrements SPF basé sur un navigateur. Remplissez le formulaire et le site génère un enregistrement SPF pour vous.

Faites de Sender Policy Framework une priorité

En termes simples, les e-mails malveillants nuisent à votre entreprise et dégradent le canal de messagerie. Lorsque les hameçonneurs verront votre domaine protégé par Sender Policy Framework, ils seront plus susceptibles de passer à des cibles plus faciles. Bien que SPF n'empêche pas le spam, il peut servir de dissuasion et vous rendre moins vulnérable aux attaques. Et qui ne veut pas ça, n'est-ce pas ? C'est pourquoi nous encourageons tous les clients de messagerie à créer un enregistrement SPF.

Combiné avec Sender ID, DKIM et DMARC, SPF fournit un niveau supplémentaire de sécurité des e-mails qui soutiendra mieux vos utilisateurs en aidant les FAI à identifier correctement votre e-mail et, à leur tour, les spammeurs.