Authentification
SPF
SPF (Sender Policy Framework) est une norme d’authentification d’email qui permet au propriétaire d’un domaine de spécifier les serveurs de messagerie autorisés à envoyer des emails pour le compte de ce domaine. Cette norme utilise le domaine indiqué dans l’en-tête « Return-Path » de l’e-mail (également appelé adresse « Envelope From »).
NOTELa technique SPF permet, dans une certaine mesure, de s'assurer que le nom de domaine utilisé dans un email n'est pas usurpé. Lorsqu’un message provient d’un domaine, le serveur DNS du domaine est interrogé. Il répond par un enregistrement court (enregistrement SPF) détaillant les serveurs autorisés à envoyer des emails depuis ce domaine. Si nous supposons que seul le propriétaire du domaine a les moyens de modifier cet enregistrement, nous pouvons considérer que cette technique ne permet pas de falsifier l’adresse de l’expéditeur, du moins pas la partie située à droite du « @ ».
Dans la dernière spécification RFC 4408, deux éléments du message sont utilisés pour déterminer le domaine considéré comme l’expéditeur : le domaine spécifié par la commande SMTP "HELO" (ou "EHLO") et le domaine spécifié par l’adresse de l’en-tête "Return-Path" (ou "MAIL FROM"), qui est également l’adresse de rebond. Différentes considérations permettent de ne prendre en compte que l’une de ces valeurs ; nous vous recommandons de vous assurer que les deux sources spécifient le même domaine.
La vérification SPF produit une évaluation de la validité du domaine expéditeur :
- None : aucune évaluation n’a pu être effectuée.
- Neutral : le domaine interrogé ne permet pas l’évaluation.
- Pass : le domaine est considéré comme authentique.
- Fail : le domaine est usurpé et le message doit être rejeté.
- SoftFail : le domaine est probablement usurpé, mais le message ne doit pas être rejeté en fonction de ce résultat.
- TempError : une erreur temporaire a interrompu l’évaluation. Le message peut être rejeté.
- PermError : les enregistrements SPF du domaine sont incorrects.
Il faut bien noter que les modifications des enregistrements au niveau des serveurs DNS peuvent mettre jusqu'à 48 heures pour être prises en compte. Ce délai est en fonction de la fréquence de rafraîchissement des caches DNS des serveurs de réception.
DKIM
L’authentification DKIM (DomainKeys Identified Mail) est un successeur de SPF. Il utilise la cryptographie à clé publique qui permet au serveur de messagerie de réception de vérifier qu’un message a bien été envoyé par la personne ou l’entité revendiquant l’envoi, et si le contenu du message a été modifié entre le moment où il a été envoyé (et "signé" par DKIM) et celui où il a été reçu. Cette norme utilise généralement le domaine dans l’en-tête « From » ou « Sender ».
DKIM est né de l'union des principes d'authentification DomainKeys, de Yahoo! et Identified Internet Mail, de Cisco et va permettre de vérifier l'authenticité du domaine expéditeur et garantir l'intégrité du message.
DKIM a remplacé l'authentification DomainKeys.
L'utilisation de DKIM nécessite quelques prérequis :
- Sécurité : le chiffrement est un élément clé du DKIM. Pour garantir le niveau de sécurité du DKIM, la taille de cryptage recommandée est 1024b. Les clés DKIM inférieures ne sont pas considérées comme valides par la majorité des fournisseurs d’accès.
- Réputation : la réputation est basée sur l’IP et/ou le domaine, mais le sélecteur DKIM moins transparent est également un élément clé à prendre en compte. Le choix du sélecteur est important : évitez de conserver celui "par défaut" qui peut être utilisé par n’importe qui et qui a donc une mauvaise réputation. Vous devez mettre en oeuvre un sélecteur différent pour les communications de rétention/acquisition et pour l’authentification.
En savoir plus sur les conditions préalables DKIM lors de l'utilisation de Campaign Classic dans cette section.