Comment configurer la zone DNS TXT pour SPF, DKIM et DMARC et comment empêcher les messages électroniques professionnels d'être rejetés par Gmail - Échec de la distribution du courrier

Administratorje de Courriel privé sévère pour les entreprises elle est souvent confrontée à de nombreux problèmes et défis. Des vagues de SPAM qui doivent être bloqués par des filtres spécifiques, sécurité de la correspondance dans le serveur de messagerie local et les serveurs distants, configuration si surveillance des services SMTP, POP, IMAP, ainsi que beaucoup d'autres détails Configuration SPF, DKIM et DMARC de suivre les meilleures pratiques pour un e-mail sécurisé.

Beaucoup de problèmes envoyer des messages électroniques ou destinataire vers/depuis vos fournisseurs, apparaissent en raison d'une configuration incorrecte de la zone DNS, qu'en est-il du service e-mail.

Pour que les e-mails soient envoyés depuis un nom de domaine, il doit être hébergé sur un serveur de messagerie correctement configuré, et nom de domaine pour avoir des zones DNS pour SPF, MX, DMARC SI DKIM définir correctement dans le gestionnaire DNS TXT du domaine.

Dans l'article d'aujourd'hui, nous allons nous concentrer sur un problème assez courant serveurs de messagerie professionnels privés. Impossible d'envoyer un e-mail à Gmail, Yahoo ! ou iCloud.

Les messages envoyés à @ Gmail.com sont automatiquement rejetés. "Échec de la livraison du courrier : renvoi du message à l'expéditeur"

J'ai récemment rencontré un problème sur un domaine de messagerie d'une entreprise, à partir de laquelle des e-mails sont régulièrement envoyés à d'autres sociétés et à des particuliers, dont certains ont des adresses @ Gmail.com. Tous les messages envoyés aux comptes Gmail sont immédiatement renvoyés à l'expéditeur. "Échec de la livraison du courrier : retour du message à l'expéditeur".

Message d'erreur renvoyé au serveur de messagerie le EXIM ressemble à ça:

1nSeUV-0005zz-De ** reciver@gmail.com R=dnslookup T=remote_smtp H=gmail-smtp-in.l.google.com [142.x.x.27] X=TLS1.2:ECDHE-ECDSA-AES128-GCM-SHA256:128 CV=yes: SMTP error from remote mail server after pipelined end of data: 550-5.7.26 This message does not have authentication information or fails to\n550-5.7.26 pass authentication checks. To best protect our users from spam, the\n550-5.7.26 message has been blocked. Please visit\n550-5.7.26  https://support.google.com/mail/answer/81126#authentication for more\n550 5.7.26 information. d3-20020adff843000000b001f1d7bdaeb7si6107985wrq.510 - gsmtp

Dans ce scénario, ce n'est pas quelque chose de très grave, comme inclure le nom de domaine d'envoi ou l'adresse IP d'envoi dans une liste de SPAM globale ou o erreur de configuration majeure des services de messagerie sur sevrer (EXIM).
Même si de nombreuses personnes voient ce message immédiatement lorsqu'elles pensent à un SPAM ou à une erreur de configuration SMTP, le problème est généré par la zone. DNS TXT du domaine. La plupart du temps, DKIM n'est pas configuré dans la zone DNS ou n'est pas passé correctement dans le gestionnaire DNS du domaine. Ce problème se retrouve souvent chez ceux qui l'utilisent CloudFlare en tant que DNS Manager et oublier de passer DNS TXT: mail._domainkey (DKIM), DMARC si SPF.

Comme nous l'indique le message de rejet de Gmail, l'authenticité et l'authentification du domaine de l'expéditeur ont échoué. "Ce message ne contient pas d'informations d'authentification ou ne réussit pas les vérifications d'authentification \ n550-5.7.26. » Cela signifie que le domaine n'a pas de DNS TXT configuré pour garantir la crédibilité du serveur de messagerie du destinataire. Gmail, dans notre script.

Lorsque nous ajoutons un domaine Web avec un service de messagerie actif sur son cPanel VestaCP, les fichiers de la zone DNS du domaine respectif sont également créés automatiquement. Zone DNS incluant la configuration du service e-mail : MX, SPF, DKIM, DMARC.
Dans la situation où nous choisissons le domaine pour être le gestionnaire DNS Cloud Flare, la zone DNS du compte d'hébergement du domaine doit être copiée sur CloudFlare pour que le domaine de messagerie fonctionne correctement. C'était le problème dans le scénario ci-dessus. Dans un gestionnaire DNS tiers, l'enregistrement DKIM n'existe pas, bien qu'il existe sur le gestionnaire DNS du serveur local.

Qu'est-ce que DKIM et pourquoi les e-mails sont-ils rejetés si nous n'avons pas cette fonctionnalité sur un domaine de messagerie ?

Messagerie identifiée DomainKeys (DKIM) est une solution d'authentification de domaine de messagerie standard qui ajoute un signature numérique chaque message envoyé. Les serveurs de destination peuvent vérifier via DKIM si le message provient du domaine de droit de l'expéditeur et non d'un autre domaine qui utilise l'identité de l'expéditeur comme masque. Par tous les comptes, si vous avez le domaine ABCDqwerty.com sans DKIM, des e-mails peuvent être envoyés depuis d'autres serveurs en utilisant votre nom de domaine. C'est si vous voulez un vol d'identité, qui en termes techniques s'appelle usurpation d'e-mails.
Une technique courante lors de l'envoi de messages électroniques phishing si le spam.

Il peut également être assuré par DKIM que, le contenu du message n'a pas été modifié après son envoi par l'expéditeur.

Avoir DKIM correctement défini sur l'hôte strict du système de messagerie et dans la zone DNS élimine également la possibilité que vos messages puissent atteindre le destinataire SPAM ou ne pas l'atteindre du tout.

Un exemple de DKIM est :

mail._domainkey: "v=DKIM1; k=rsa; p=MIGfMA0GCSqGfdSIb3DQEBAQUAA4GN ... ocqWffd4cwIDAQAB"

Bien sûr, la valeur DKIM obtenue par Algorithme de chiffrement RSA est unique pour chaque nom de domaine et peut être régénéré à partir du serveur de messagerie de l'hébergeur.

Avoir DKIM installé et configuré correctement dans DNS TXT gestionnaire, il est très possible de résoudre le problème des messages renvoyés aux comptes Gmail. Au moins pour l'erreur "Mail delivery failed":

"SMTP error à partir du serveur de messagerie distant après la fin des données en pipeline : 550-5.7.26 Ce message ne contient pas d'informations d'authentification ou ne parvient pas à \ n550-5.7.26 passer les contrôles d'authentification. Pour protéger au mieux nos utilisateurs des spams, le message \n550-5.7.26 a été bloqué. »

En guise de bref récapitulatif, DKIM ajoute une signature numérique à chaque message envoyé, qui permet aux serveurs de destination de vérifier l'authenticité de l'expéditeur. Si le message provient de votre entreprise et que l'adresse du tiers n'a pas été utilisée pour utiliser votre identité.

Gmail (Google) peut-être rejette automatiquement tous les messages provenant de domaines qui n'ont pas une telle sémantique numérique DKIM.

Qu'est-ce que SPF et pourquoi est-il important pour l'envoi sécurisé d'e-mails ?

Tout comme DKIM, et SPF vise à empêcher messages d'hameçonnage si usurpation d'e-mails. De cette façon, les messages envoyés ne seront plus marqués comme spam.

Cadre de politique de l'expéditeur (SPF) est une méthode standard d'authentification du domaine à partir duquel les messages sont envoyés. Les entrées SPF sont définies sur Gestionnaire DNS TXT de votre domaine, et cette entrée spécifiera le nom de domaine, l'adresse IP ou les domaines autorisés à envoyer des messages électroniques à l'aide de votre nom de domaine ou de celui de votre organisation.

Un domaine sans SPF peut permettre aux spammeurs d'envoyer des emails depuis d'autres serveurs, utiliser votre nom de domaine comme masque. De cette façon, ils peuvent se propager fausse information ou des données sensibles peuvent être demandées au nom de votre organisation

Bien sûr, les messages peuvent toujours être envoyés en votre nom à partir d'autres serveurs, mais ils seront marqués comme spam ou rejetés si ce serveur ou ce nom de domaine n'est pas spécifié dans l'entrée SPF TXT de votre domaine.

Une valeur SPF dans le gestionnaire DNS ressemble à ceci :

@ : "v=spf1 a mx ip4:x.x.x.x ?all"

Où "ip4" est IPv4 sur votre serveur de messagerie.

Comment définir le SPF pour plusieurs domaines ?

Si nous voulons autoriser d'autres domaines à envoyer des e-mails au nom de notre domaine, nous les spécifierons avec la valeur "include"Dans SPF TXT :

v=spf1 ip4:x.x.x.x include:example1.com include:example2.com ~all

Cela signifie que des e-mails peuvent également être envoyés depuis notre nom de domaine vers example1.com et example2.com.
C'est un enregistrement très utile si nous avons par exemple un magasiner A l'adresse "exemple1.com", Mais nous voulons que les messages de la boutique en ligne aux clients partent adresse de domaine de l'entreprise, ceci étant "example.com«. Dans TXT FPS pour "example.com", comme nécessaire pour spécifier à côté de IP et "include: example1.com". Pour que les messages puissent être envoyés au nom de l'organisation.

Comment définir le SPF pour IPv4 et IPv6 ?

Nous avons un serveur de messagerie avec les deux IPv4 et avec IPv6, il est très important que les deux IP soient spécifiées dans le SPF TXT.

v=spf1 ip4:196.255.100.26 ip6:2001:db8:8:4::2 ~all

Ensuite, après le "ip" la directive "include”Pour ajouter des domaines autorisés pour l'expédition.

Qu'est-ce que ça veut dire "~all","-all"Et"+allDu FPS ?

Comme indiqué ci-dessus, les fournisseurs (FAI) peuvent toujours recevoir des e-mails au nom de votre organisation même s'ils sont envoyés depuis un domaine ou une adresse IP qui n'est pas spécifié dans la politique SPF. La balise "tous" indique aux serveurs de destination comment gérer ces messages provenant d'autres domaines non autorisés et envoyer des messages en votre nom ou au nom de votre organisation.

~all : Si le message est reçu d'un domaine qui n'est pas répertorié dans le SPT TXT, les messages seront acceptés sur le serveur de destination, mais ils seront marqués comme spam ou suspects. Ils seront soumis aux bonnes pratiques des filtres anti-spam du fournisseur destinataire.

-all : Il s'agit de la balise la plus stricte ajoutée à une entrée SPF. Si le domaine n'est pas répertorié, le message sera marqué comme non autorisé et sera rejeté par le fournisseur. Il ne sera pas livré non plus macdans les spams.

+all : Très rarement utilisé et déconseillé du tout, ce tag permet à d'autres d'envoyer des e-mails en votre nom ou au nom de votre organisation. La plupart des fournisseurs rejettent automatiquement tous les e-mails provenant de domaines avec SPF TXT."+all“. Précisément parce que l'authenticité de l'expéditeur ne peut pas être vérifiée, sauf après une vérification de "l'en-tête de l'email".

Sommaire: Que signifie Sender Policy Framework (SPF) ?

Autorise via la zone DNS TXT / SPF, les adresses IP et les noms de domaine pouvant envoyer des messages électroniques depuis votre domaine ou votre entreprise. Il applique également les conséquences qui s'appliquent aux messages envoyés à partir de domaines non autorisés.

Que signifie DMARC et pourquoi est-ce important pour votre serveur de messagerie ?

DMARC (Rapports et conformité d'authentification des messages basés sur le domaine) est étroitement liée aux normes politiques SPF si DKIM.
DMARC est un système de validation conçu pour protéger votre nom de domaine de messagerie ou celui de votre entreprise, des pratiques telles que l'usurpation d'adresses e-mail et les escroqueries par phishing.

En utilisant les normes de contrôle Sender Policy Framework (SPF) et Domain Keys Identified Mail (DKIM), DMARC ajoute une fonctionnalité très importante. rapports.

Lorsqu'un propriétaire de domaine publie DMARC dans la zone DNS TXT, il obtient des informations sur qui envoie des messages électroniques en son nom ou au nom de la société propriétaire du domaine protégé par SPF et DKIM. Dans le même temps, les destinataires des messages sauront si et comment ces politiques de bonnes pratiques sont surveillées par le propriétaire du domaine d'envoi.

Un enregistrement DMARC dans DNS TXT peut être :

V=DMARC1; rua=mailto:report-id@rep.example.com; ruf=mailto:account-email@for.example.com; p=none; sp=none; fo=0;

Dans DMARC, vous pouvez mettre plus de conditions pour signaler les incidents et les adresses e-mail pour l'analyse et les rapports. Il est conseillé d'utiliser des adresses e-mail dédiées au DMARC car le volume de messages reçus peut être important.

Les balises DMARC peuvent être définies en fonction de la politique imposée par vous ou votre organisation :

v - version du protocole DMARC existant.
p - appliquer cette politique lorsque DMARC ne peut pas être vérifié pour les messages électroniques. Il peut avoir la valeur : "none","quarantine"Ou"reject“. Est utilisé "none» pour obtenir des rapports sur le flux des messages et l'état des brochessora.
rua - Il s'agit d'une liste d'URL sur lesquelles les FAI peuvent envoyer des commentaires au format XML. Si nous ajoutons l'adresse e-mail ici, le lien sera :rua=mailto:feedback@example.com».
ruf - La liste des URL sur lesquelles les FAI peuvent envoyer des rapports sur les cyberincidents et les crimes commis au nom de votre organisation. L'adresse sera :ruf=mailto:account-email@for.example.com" .
rf - Format de rapport sur la cybercriminalité. Il peut être façonné "afrf"Ou"iodef" .
pct - Demande au FAI d'appliquer la politique DMARC uniquement pour un certain pourcentage de messages ayant échoué. Par exemple, nous pourrions avoir :pct=50%"Ou des politiques"quarantine"Et"reject“. Cela ne sera jamais accepté."none" .
adkim – Spécifiez "Alignement Mode” pour les signatures numériques DKIM. Cela signifie que la correspondance de la signature numérique d'une entrée DKIM avec le domaine est vérifiée. adkim peut avoir les valeurs : r (Relaxed) ou s (Strict).
aspf - De la même manière que dans le cas adkim "Alignement" est spécifié Mode” pour SPF et prend en charge les mêmes valeurs. r (Relaxed) ou s (Strict).
sp - Cette politique s'applique pour permettre aux sous-domaines dérivés du domaine de l'organisation d'utiliser la valeur DMARC du domaine. Cela évite l'utilisation de politiques distinctes pour chaque domaine. C'est pratiquement un "joker" pour tous les sous-domaines.
ri - Cette valeur définit l'intervalle auquel les rapports XML seront reçus pour DMARC. La plupart du temps, le reporting est préférable sur une base quotidienne.
fo - Options pour les rapports de fraude. "Légal options“. Ils peuvent avoir des valeurs de "0" pour signaler les incidents lorsque la vérification SPF et DKIM échouent, ou la valeur "1" pour le scénario où le SPF ou DKIM n'existe pas ou ne réussit pas la vérification.

Par conséquent, pour vous assurer que vos e-mails ou ceux de votre entreprise arrivent dans votre boîte de réception, vous devez tenir compte de ces trois normes."bonnes pratiques pour l'envoi d'e-mails" . DKIM, SPF si DMARC. Les trois normes sont liées au DNS TXT et peuvent être gérées à partir du gestionnaire DNS du domaine.

Passionné par la technologie, j'écris avec plaisir sur StealthSettings.com depuis 2006. J'ai une expérience approfondie dans les systèmes d'exploitation : macOS, Windows et Linux, ainsi que dans les langages de programmation et les plates-formes de blogging (WordPress) et pour les boutiques en ligne (WooCommerce, Magento, PrestaShop).

Comment » remarquable » Comment configurer la zone DNS TXT pour SPF, DKIM et DMARC et comment empêcher les messages électroniques professionnels d'être rejetés par Gmail - Échec de la distribution du courrier

1 réflexion sur "Comment configurer la zone DNS TXT pour SPF, DKIM et DMARC et comment éviter que les messages électroniques professionnels soient rejetés par Gmail - Échec de la livraison du courrier"

Laisser un commentaire