Améliorer la sécurité du courrier électronique : Stop Sender Fraud with SPF, DKIM, and DMARC

Il n’est pas possible de filtrer la vérité : vous devez protéger le courrier électronique de votre entreprise.

En 2013, plus de 100 milliards de courriers électroniques professionnels ont été envoyés et reçus chaque jour. Seulement un courriel sur cinq envoyé en 2013 était légitime, et 92 % de tous les courriels illégitimes comprenaient des liens vers du contenu potentiellement malveillant.

Il y a cependant des signes d’amélioration ; ce mois-ci est le premier au cours des 12 dernières années où moins de la moitié des courriels des clients de Symantec étaient des spams.

Vous pouvez remercier trois normes de sécurité des courriels (et d’autres initiatives) pour la réduction des spams : SPF, DKIM et DMARC. Malgré tout, les risques de sécurité sont répandus. On m’a récemment raconté l’histoire d’un directeur financier qui a fait l’objet d’une tentative d’hameçonnage. La tentative a échoué, mais si elle avait réussi, elle aurait coûté 50 000 $ à l’organisation.

En ce qui concerne ces normes de messagerie, il y a encore beaucoup de confusion autour d’elles. J’espère pouvoir apporter un peu de clarté avec ce post, ainsi que vous guider à travers la façon de mettre en œuvre SPF, DKIM et DMARC.

Sender Policy Framework (RFC 4408)

Sender Policy Framework, ou SPF, est le vieil homme à la fête de l’authentification des e-mails. SPF est une norme ouverte qui spécifie une méthode pour empêcher la falsification des adresses d’expéditeur, selon openspf.org. Il ne s’agit pas d’arrêter le spam, mais de contrôler et d’arrêter les tentatives de falsification d’adresse d’expéditeur.

SPF vous permet d’identifier les sources de courrier légitimes de votre domaine et empêche les sources non autorisées d’envoyer des milliers – voire des millions – d’e-mails illicites depuis votre domaine.

Il existe quatre types d’abus de courrier électronique couramment associés à la falsification de l’expéditeur de courrier électronique :

• Spam (courrier électronique en vrac non sollicité & courrier électronique commercial non sollicité)
• Fraudeurs (arnaques 419)
• Malware (adware, zero days, virus, trojans, etc.)
• Phishers (spear-phishing)

Vous ne voulez pas que le domaine de votre organisation soit associé à l’un de ces éléments pour des raisons évidentes. SPF permettra de s’assurer que les courriels de votre organisation proviennent bien de vous.

DomainKeys Identified Mail (RFC 6376, remplace les RFC 4871 et RFC 5672 qui sont maintenant obsolètes)

DKIM, ou DomainKeys Identified Mail, est un enregistrement TXT publié dans votre système de nom de domaine (DNS). Il implique quelque chose que tous les administrateurs informatiques devraient apprendre à aimer : les clés – les clés publiques pour être spécifique.

Avant de plonger dans DKIM, il est important que nous comprenions ce que sont les clés et comment elles fonctionnent. Les clés, dans ce cas, la cryptographie à clé publique, consiste en une clé publique (connue de tous) et une clé privée (souvent appelée secret). Les clés publiques et privées sont mathématiquement liées les unes aux autres, rendant possible une communication sécurisée sur des canaux publics.

Ces clés sont comme un sceau inviolable sur une enveloppe transparente. Vous ne cachez pas nécessairement le message ; vous authentifiez seulement avec 100% de certitude à la fois l’expéditeur et le message.

Maintenant, revenons à DKIM.

« Techniquement, DKIM fournit une méthode pour valider une identité de nom de domaine qui est associée à un message par authentification cryptographique », selon dkim.org. En d’autres termes, DKIM utilise des clés pour s’assurer qu’un expéditeur de courrier électronique est bien celui qu’il prétend être.

Avec DKIM, des paires de clés publiques et privées sont générées pour maintenir l’authentification des serveurs de messagerie et des communications. Chaque serveur SMTP (Simple Mail Transfer Protocol) sortant a besoin de la bonne clé privée et du bon préfixe afin de correspondre à un enregistrement DNS public que le serveur de messagerie récepteur vérifie ensuite.

Vous vous êtes déjà demandé pourquoi l’icône de verrouillage s’affiche dans Gmail lorsque vous recevez des messages d’eBay, de Paypal ou de votre banque ? Il s’agit de DKIM et d’un peu de DMARC (que nous aborderons prochainement). Ci-dessous, mailed-by montre la correspondance SPF et signed-by montre la correspondance DKIM. DKIM et DMARC ne sont pas encore essentiels, mais comme IPv6, ils passent rapidement du laboratoire de test au mieux-disant.

Domain-based Message Authentication, Reporting, and Conformance (RFC 7489)

DMARC, ou Domain-based Message Authentication, Reporting, and Conformance, aide les expéditeurs et les destinataires à travailler ensemble pour créer des communications par courrier électronique plus sûres. DMARC a été créé par un groupe d’organisations pour limiter les abus basés sur le courrier électronique « en résolvant quelques problèmes de longue date liés à l’exploitation, au déploiement et au signalement des protocoles d’authentification du courrier électronique », selon dmarc.org.

DMARC permet à l’expéditeur du message d’indiquer que ses messages sont protégés par SPF et/ou DKIM. Une politique DMARC applique des instructions claires que le récepteur du message doit suivre si un courriel ne passe pas l’authentification SPF ou DKIM – par exemple, le rejeter ou le jeter.

De plus, DMARC renvoie un rapport à l’expéditeur sur les messages qui PASSENT et/ou échouent à l’évaluation DMARC.

Comment mettre en œuvre SPF, DKIM et DMARC

Maintenant que nous avons une meilleure compréhension de chacune de ces trois normes (et pourquoi elles sont importantes), regardons comment vous pouvez améliorer votre sécurité du courrier électronique en les mettant en œuvre.

Note : Pour les besoins de cette marche à suivre étape par étape, supposons que vous êtes le responsable informatique de 301 Moved, une petite entreprise de conception web qui utilise Google Apps.

Récemment, vous avez eu quelques problèmes avec les robots de spam russe. Vos utilisateurs finaux se sont plaints de recevoir des notifications de rebond d’emails provenant d’adresses qu’ils n’ont jamais vues ou auxquelles ils ont envoyé des messages. Vous réalisez que quelqu’un envoie clairement des courriels frauduleux à partir de votre domaine.

Alors, comment les arrêter ?

Note : j’inclus le format BIND standard en texte brut et une capture d’écran de la façon dont l’enregistrement se présente dans GoDaddy DNS. Dans GoDaddy, tous les enregistrements pour le domaine de premier niveau 301Moved.com utilisent l’hôte « @ », votre hôte sera probablement différent. Dans le cadre de cet exercice, je ne parlerai que du courrier sortant, et non de la façon dont nous traitons ces normes par rapport au courrier entrant provenant d’expéditeurs externes.

Mise en œuvre de SPF

Première étape : le guide de Google sur la configuration des enregistrements SPF pour fonctionner avec Google Apps est un bon point de départ. En suivant ces instructions, nous ajoutons un nouvel enregistrement TXT à notre DNS public.

301Moved.com. IN TXT "v=spf1 include:_spf.google.com ~all"

301 Moved utilise également Zendesk, un système de billetterie qui envoie des e-mails directement depuis votre domaine. Vous devez vous assurer qu’aucun spam n’est envoyé de là non plus.

Etape deux : trouver et ajouter l’enregistrement SPF de Zendesk.

301Moved.com. IN TXT "v=spf1 include:mail.zendesk.com include:_spf.google.com ~all"

Il est important de noter que nous n’ajoutons pas un deuxième enregistrement SPF, ce qui casserait les choses ; au lieu de cela, nous les combinons en un seul enregistrement, le rendant plus long au fur et à mesure que des expéditeurs sont ajoutés.

Note : Vous ne pouvez ajouter qu’un seul enregistrement SPF par domaine ou sous-domaine.

Vous savez également que 301 Moved a une ancienne passerelle de messagerie sur place qui gère certaines choses héritées, alors ajoutons également leur bloc IP. 301 Moved utilise le mécanisme « IP4 » pour définir le bloc IP qu’il possède-198.51.100.0/24 (192.51.100.0-254).

Utilisez le SPF Surveyor de Dmarcian pour voir vos enregistrements SPF.

Etape trois : Ajoutez des adresses IPv4 uniques en soi, et des netblocks en notation CIDR (Classless Inter-Domain Routing). 198.51.100.0 pour une adresse IP unique (pas besoin d’un /32) et 198.51.100.0/24 pour les sous-réseaux.

301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com ~all"

L’ajout de l’ancienne passerelle de messagerie garantira que le courrier électronique sortant de la passerelle sera autorisé par SPF.

Les mécanismes ci-dessus sont les plus couramment utilisés, mais il y en a huit au total – y compris le bizarre et le déprécié. Ces mécanismes définissent uniquement la portée de la correspondance, et non les actions elles-mêmes.

Les qualificatifs de la section suivante sont les endroits où PASS, SOFTFAIL et FAIL peuvent être définis-une correspondance entraînerait le déclenchement de l’une des trois actions (PASS, SOFTFAIL et FAIL).

• ALL : Correspond à tout ce qui n’est pas déjà défini par un autre mécanisme correspondra au mécanisme all
• A : Si le nom de domaine a un enregistrement d’adresse (A ou AAAA) qui peut être résolu à l’adresse de l’expéditeur, il correspondra.
• IP4 : Si l’expéditeur est dans une plage d’adresses IPv4 donnée, il correspondra.
• IP6 : Si l’expéditeur est dans une plage d’adresses IPv6 donnée, il correspondra.
• MX : Si le nom de domaine a un enregistrement MX se résolvant à l’adresse de l’expéditeur, il correspondra (c’est-à-dire que le courrier provient d’un des serveurs de courrier entrant du domaine).
• PTR : Si le nom de domaine (enregistrement PTR) pour l’adresse du client est dans le domaine donné et que ce nom de domaine se résout à l’adresse du client (forward-confirmed reverse DNS), correspondance. Ce mécanisme est déprécié et ne devrait plus être utilisé.
• EXISTS : Si le nom de domaine donné se résout à une adresse quelconque, il correspondra (quelle que soit l’adresse à laquelle il se résout). Cette option est rarement utilisée. Avec le langage macro SPF, il offre des correspondances plus complexes comme les DNSBL-queries.
• INCLUDE : Si la politique incluse (un terme mal choisi) passe le test, ce mécanisme correspond. Ceci est généralement utilisé pour inclure les politiques de plus d’un FAI.

Viennent ensuite les qualificatifs. Il existe un million de façons de les combiner avec un modèle de liste noire et/ou de liste blanche, mais pour nos besoins ici, nous allons inclure uniquement les trois mécanismes de recherche que nous avons mentionnés ci-dessus avec un seul qualificateur à la fin pour faire une liste blanche. Nos quatre qualificatifs sont :

• + pour un résultat PASS. Ceci peut être omis ; par exemple, +mx est identique à mx.
• ? pour un résultat NEUTRE interprété comme NONE (pas de politique).
• ~ (tilde) pour SOFTFAIL, une aide au débogage entre NEUTRE et FAIL. Typiquement, les messages qui renvoient un SOFTFAIL sont acceptés mais marqués.
• – (moins) pour FAIL, le courrier doit être rejeté (voir ci-dessous).

Quatrième étape : Appliquer la politique SOFTFAIL.

Pour l’instant, 301 Moved utilise le tilde pour SOFTFAIL. En utilisant le tilde, tout courrier ne correspondant pas à Google, Zendesk ou au bloc d’IP mentionné serait SOFTFAIL. Le courrier sera toujours distribué, mais il sera probablement envoyé dans le dossier Spam ou Junk. Cependant, cela dépend entièrement du serveur de messagerie du destinataire. Il n’est défini par aucune norme.

Un « – » (moins) dans cette situation ferait échouer (et probablement rebondir) le courrier non correspondant entièrement. Vous pouvez basculer cela sur une fois que vous commencez à obtenir plus de visibilité dans votre courrier sortant (attendez DMARC), et une fois que vous êtes plus à l’aise avec votre infrastructure de messagerie.

SPF est génial parce qu’il n’y a aucune modification des serveurs de messagerie eux-mêmes. Les en-têtes restent les mêmes. Juste un simple enregistrement TXT (le type d’enregistrement SPF réel et dédié n’a jamais été aussi populaire et est maintenant déprécié) et vous pouvez indiquer à la plupart des serveurs de messagerie du monde qui devrait flasher votre nom autour.

À la fin de la journée, le serveur SMTP récepteur vérifie l’IP de l’expéditeur contre votre enregistrement SPF qu’il a interrogé, il applique ensuite la politique basée sur vos instructions. En d’autres termes, vous vous autorisez, ainsi que vos fournisseurs, à envoyer du courrier (principalement) de confiance parce que vous publiez une liste de contrôle d’accès (ACL) au public.

Cependant, les messages peuvent toujours être modifiés en transit, et les faussaires et hameçonneurs rusés peuvent se faufiler autour de SPF de certaines façons intéressantes (peut-être un sujet pour un autre jour). C’est le SMTP : le TLS de bout en bout n’est pas garanti, nous devons donc toujours supposer que le texte est clair. Les messages peuvent être trafiqués ou falsifiés.

Mais entrez dans la scène à droite…

Implémentation du courrier identifié par DomainKeys

Lorsque le courrier est envoyé, 301Moved.com signe (sans chiffrer) le courrier avec la clé privée. A partir de maintenant, toute modification du message, y compris le corps, les en-têtes ou les pièces jointes, brisera la signature et rendra le message invalide. Encore une fois, nous nous tournons vers Google, en utilisant leur article Authentifier le courrier électronique avec DKIM

Etape cinq : Ajoutez la clé publique à votre enregistrement DNS.

google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"

Chaque enregistrement DKIM a un préfixe de sélecteur unique, ce qui signifie que nous pouvons en publier plusieurs. Au lieu de les combiner en un seul enregistrement, comme nous l’avons fait avec SPF, vous pouvez utiliser des sélecteurs uniques et publier autant de clés publiques que nécessaire. Cela nous permet d’ajouter un grand nombre de serveurs autorisés DKIM sans aucune limite supérieure.

Vous remarquerez que le préfixe ci-dessus est « google », la valeur par défaut que Google Apps utilise lors de la génération d’un enregistrement DKIM que vous devez publier. Vous pouvez le modifier dans Google, et dans la plupart des autres configurations, donc si vous vouliez le préfixe « dkimawesome », rien ne vous en empêche.

Certains fournisseurs de cloud computing procèdent différemment. Au lieu de générer des paires de clés uniques pour chaque locataire de cloud, ils signent tous les courriers sortants de tous les domaines avec la même clé – tout en vous faisant publier un nom canonique (CNAME) à la place pour leur clé.

Zendesk fait cela, nous CNAME deux clés différentes sur notre DNS vers leur DNS. Zendesk a un excellent article d’aide- Signer numériquement votre e-mail avec DKIM ou DMARC (Plus et Enterprise)

Step Six (si applicable) : CNAME les clés sur votre DNS à leur DNS. Toute requête DNS recherchant zendesk1._domainkey.301Moved.com sera redirigée par votre DNS vers zendesk1._domainkey.zendesk.com. Zendesk sert alors directement les clés DKIM.

zendesk1._domainkey.301Moved.com IN CNAME zendesk1._domainkey.zendesk.comzendesk2._domainkey.301Moved.com IN CNAME zendesk2._domainkey.zendesk.com

Nous pouvons voir à quoi cela ressemble pour d’autres serveurs en utilisant l’outil nslookup (pour Unix ou Windows) localement.

Pas tous les expéditeurs sortants prennent en charge DKIM. Google Apps le fait évidemment, mais vos anciens serveurs de messagerie peuvent ne pas le faire.

Mise en œuvre de l’authentification, du signalement et de la conformité des messages basés sur le domaine

DMARC, ou Domain-based Message Authentication, Reporting, and Conformance, est le dernier outil dont nous disposons pour lutter contre les courriels malveillants. Pour les serveurs de messagerie qui écoutent, DMARC, les relais comment traiter SPF et DKIM, ainsi que la façon de vous rapporter, vous donnant une visibilité indispensable sur vos taux de livraison et la conformité des enregistrements.

Et oui, DMARC est un autre enregistrement TXT.

Etape sept : Configurer une politique DMARC, identifier l’adresse mailto, configurer le mode d’alignement et identifier le pourcentage de messages auxquels la politique doit être appliquée (ne vous inquiétez pas, c’est plus simple qu’il n’y paraît).

301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100; sp=none"

La politique ci-dessus est désignée comme p=none. Nous ne modifions pas du tout le flux de courrier pour le moment – nous configurons simplement la politique et les rapports correspondants. L’adresse à laquelle les rapports XML du statut DMARC seront envoyés est désignée par rua=.

Les serveurs de messagerie récepteurs enverront des pièces jointes XML montrant comment les messages provenant de – et ceux qui prétendent provenir de – votre domaine se sont empilés contre le gant SPF, DKIM et DMARC que la plupart des serveurs de messagerie modernes imposent.

Ces rapports montrent, sur une base par enveloppe, si SPF a réussi, échoué ou softfailed. Ils montrent si DKIM a échoué, échoué l’alignement ou réussi-et comment les politiques ci-dessus ont été appliquées.

Enfin, ces rapports montrent la disposition finale de livraison du message. Il existe d’excellents outils pour vous aider à les analyser. Même si vous n’appliquez pas de politiques aux messages, c’est comme les journaux de pare-feu, de DNS et d’IDS/IPS – il est toujours bon d’avoir quelque chose que vous pouvez revenir en arrière et regarder.

L’adkim=r spécifie le mode d’alignement DKIM relaxé, « r » est pour relaxé et « s » pour strict. Le mode relaxé permet aux domaines DKIM d= authentifiés au sein d’un domaine organisationnel commun dans l’adresse de l’en-tête de courrier-From : de PASSER la vérification DMARC. Le mode strict exige une correspondance parfaite entre le domaine DKIM d= et l’adresse de l’en-tête de l’e-mail. Pensez aux sous-domaines, si vous les utilisez.

aspf=r fait exactement la même chose, sauf pour les vérifications SPF.

Le pct=100 est le pourcentage de messages qui sont effectivement traités selon la politique DKIM. Choisi au hasard, le serveur de messagerie récepteur appliquera la politique sur ce pourcentage de messages provenant de votre domaine. Nous utilisons 100 pour l’instant parce que nous n’appliquons pas de politique, encore.

Avant d’appliquer une politique, nous allons étrangler cela à cinq afin que seulement un message sur 20 ait une politique appliquée lorsque nous tournons le drapeau de politique p= sur quarantaine ou rejet. De cette façon, si nous foirons totalement cela, 95 % de notre courrier électronique sera toujours livré, au lieu de 0 % livré si nous avons commencé à pct=100.

Les messages échouant à la vérification DMARC, ou vos modes d’alignement adkim= et aspf= que nous avons définis ci-dessus sont alors soft bounced, comme ci-dessus, pour une politique de quarantaine, ou bounced entièrement lorsqu’ils sont définis sur reject.

Il est très important de noter que DMARC passera le message si SPF ou DKIM passe, et seulement FAIL le message si SPF et DKIM FAIL. Ainsi, les messages SPF uniquement et DKIM uniquement peuvent passer DMARC, mais les messages sans SPF/DKIM échoueront toujours. C’est une excellente nouvelle si vous avez des systèmes de messagerie qui ne supportent que SPF, ou que DKIM.

Utilisez DMARC Inspector de Dmarcian pour vérifier visualiser vos enregistrements DMARC.

Dmarcian est un outil payant qui vous permet de gérer vos rapports DMARC facilement, il y en a beaucoup d’autres, mais il se trouve que Dmarcian est mon préféré.

Mise à jour : Nous avons reçu quelques courriels (conformes à DMARC !) posant des questions sur la politique de sous-domaine sp=none. Avec une politique qui inclut sp=none, vous ne spécifiez pas une politique DMARC pour tous les sous-domaines. Cela se fait manuellement en configurant un enregistrement DMARC approprié pour chaque sous-domaine spécifique ou inclus dans l’enregistrement DMARC principal avec un sp=quarantine ou sp=reject.

Configuration minimale

Si vous voulez essayer cela, je vous recommande de commencer très ouvert et de rester simple jusqu’à ce que vous ayez suffisamment de rapports DMARC pour commencer à appliquer quoi que ce soit.

301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com MX ?all"

Définissez les grands fournisseurs avec un « include : » et tous les blocs IP à partir desquels vous pouvez envoyer du courrier avec un « IP4 « ou un « IP6 ». Utilisez « MX » pour autoriser vos serveurs de courrier entrant. Et à moins que vous n’envoyiez du courrier directement à partir de la même boîte/serveur qui héberge votre site web (mauvaise, mauvaise pratique d’ailleurs), vous pouvez ignorer le mécanisme « A » mentionné ci-dessus. Le  » ? » n’applique aucune politique à vos messages, mais fait sortir votre enregistrement SPF pour que DMARC puisse le reconnaître.

google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"

Ayez le bon sélecteur, « google » dans ce cas, et la bonne clé. Rappelez-vous, vous pouvez en publier plus d’un.

Note : S’il vous plaît, ne publiez pas cette clé réelle ou je serai en mesure de signer DKIM votre courrier.

301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=5; sp=none"

Pour DMARC, nous n’avons pas de politique appliquée, nous sommes en mode relaxé, mais nous demandons que les rapports XML soient envoyés à une boîte aux lettres à laquelle nous pouvons accéder. À partir de là, DMARC nous donne un retour assez rapide (pas en temps réel) sur la façon dont nous pouvons resserrer les différentes politiques dans les trois enregistrements.

Mais attendez, qu’en est-il de TLS ?

La sécurité de la couche de transport, ou TLS, ne fait pas partie de la norme DMARC, et ce n’est pas un enregistrement DNS.

A la place, TLS est juste une couche de sockets sécurisés (SSL) adulte que les serveurs de messagerie peuvent utiliser pour soumettre des messages les uns aux autres sur des connexions publiques. C’est SMTP enveloppé dans TLS, comme vous pouvez faire beaucoup d’autres choses dans/au-dessus de TLS-SNMP sur TLS et FTP sur TLS étant des exemples communs. TLS ne crypte les messages qu’en transit, pas au repos.

Si nous envoyons un message signé par DKIM sur TLS, il est signé pendant toute sa durée de vie, mais seulement crypté lorsqu’il saute de vos Google Apps à leur Cisco Ironport, ou partout où votre courrier transite. TLS ne protège très certainement pas les messages au repos, bien qu’il soit également utilisé pour votre session HTTPS:// au webmail lorsque vous lisez ce même message, mais encore une fois, c’est en transit.

TLS est quelque chose que vous devriez utiliser autant que possible, mais soyez également prêt à parler en clair à d’autres systèmes de messagerie publics. Même en 2015, certains serveurs de messagerie ne prennent pas en charge STARTTLS (langage de serveur pour commencer la poignée de main TLS).

Vous pouvez imposer l’utilisation de TLS avec certains domaines externes dans Google Apps avec un simple changement de configuration. C’est une bonne chose à activer pour les entreprises externes associées, les partenaires et autres organisations, mais n’appliquez TLS qu’une fois que vous êtes sûr qu’il est fiable et pris en charge par tous les serveurs de messagerie sur ce domaine spécifique.

L’importance de la sécurité du courrier électronique et la prévention de la fraude de l’expéditeur

Que vous soyez un administrateur informatique chevronné ou que vous commenciez à peine, ces trois normes revêtent la même importance. Certes, ce que chacune d’entre elles fait et comment elles fonctionnent ensemble peut devenir un peu encombrant, mais leur mise en œuvre est relativement simple et les avantages valent bien votre temps.