• Méthodes d'authentification des e-mails : comment l'SPF, le DKIM et le DMARC protègent votre domaine

Méthodes d'authentification des e-mails : comment l'SPF, le DKIM et le DMARC protègent votre domaine

par

Dernière mise à jour :
9 Temps de lecture : 9 min
Méthodes d'authentification des e-mails : comment l'SPF, le DKIM et le DMARC protègent votre domaine

Points clés à retenir

  • Les méthodes d'authentification des e-mails permettent de vérifier qu'un message provient bien de votre domaine et qu'il n'a pas été falsifié.
  • SPF, DKIM et DMARC constituent les trois principaux. Chacun vérifie un aspect différent, et c'est en les utilisant conjointement qu'ils sont les plus efficaces.
  • Ensemble, ils bloquent l'usurpation d'identité, empêchent vos e-mails d'atterrir dans les courriers indésirables et protègent votre marque sur Gmail, Outlook et Yahoo.
  • Les normes ARC, MTA-STS, TLS-RPT et BIMI étendent cette protection aux e-mails transférés, au transport chiffré et aux logos de marque.
  • Sans eux, n'importe qui peut usurper votre nom de domaine et vous n'avez aucun moyen de savoir comment il est utilisé.
  • Les rapports DMARC vous permettent d'identifier les expéditeurs non autorisés et les échecs bien plus rapidement que si vous vérifiiez manuellement le DNS ou les en-têtes.

Les méthodes d'authentification des e-mails sont les protocoles, principalement l'SPF, le DKIM et le DMARC, qui permettent aux serveurs destinataires de vérifier qu'un message provient bien de votre domaine. Sans elles, n'importe qui peut usurper votre adresse d'expéditeur, et vos e-mails légitimes risquent davantage d'être classés dans le dossier « spam ».

Correctement configurées, ces méthodes protègent votre marque contre l’usurpation d’identité, garantissent que les e-mails légitimes parviennent bien dans la boîte de réception et vous permettent de savoir exactement comment votre domaine est utilisé. Google, Yahoo, Microsoft et Apple imposant désormais une authentification aux expéditeurs en masse, cette configuration n’est plus facultative. Ce guide présente les principales méthodes d’authentification des e-mails, leur fonctionnement, leur impact sur la délivrabilité et la manière de les mettre en œuvre.

Pour les équipes gérant plusieurs domaines ou services d’envoi, le plus difficile n’est pas de publier les enregistrements une seule fois. Il s’agit plutôt de maintenir la visibilité à mesure que chaque nouveau CRM, chaque nouvelle plateforme marketing, chaque service d’assistance ou chaque domaine régional modifie les SPF, DKIM et DMARC sous-jacents.

Qu'est-ce que l'authentification des e-mails ?

L'authentification des e-mails désigne un ensemble de méthodes permettant de vérifier qu'un message provient bien du domaine qu'il prétend provenir et qu'il n'a pas été falsifié en cours de transmission. Ces méthodes, principalement l'SPF, le DKIM et le DMARC, sont publiées sous forme d'enregistrements TXT dans le DNS. Lorsqu'un serveur destinataire vérifie un message entrant, il se réfère à ces enregistrements DNS pour confirmer la propriété du domaine et décider s’il faut le délivrer, le rediriger vers le dossier spam ou le rejeter.

Bon à savoir

L'authentification est souvent confondue avec trois concepts apparentés. L'authentification permet de vérifier l'identité de l'expéditeur du message. L'autorisation détermine ce qu'un expéditeur est autorisé à faire. Le chiffrement protège le contenu pendant son acheminement. La réputation de l'expéditeur reflète l'historique d'envoi d'un domaine et son taux de plaintes. Ces quatre éléments influencent la délivrabilité, mais l'authentification constitue le fondement sur lequel reposent les trois autres.

Principales méthodes d'authentification des e-mails : SPF, DKIM et DMARC

Voici les méthodes qui permettent l'authentification des e-mails ; chacune d'entre elles intervient à une étape différente du processus de vérification.

Considérez l'SPF, le DKIM et le DMARC comme trois niveaux de vérification d'identité. L'SPF confirme que le serveur expéditeur est autorisé à envoyer des e-mails au nom de votre domaine. Le DKIM confirme que le message n'a pas été altéré pendant son acheminement. Le DMARC vérifie que ces résultats correspondent bien à l'adresse « De » visible et indique aux fournisseurs d'accès comment réagir en cas de divergence.

ProtocoleCe que cela vérifiePourquoi c'est importantPrincipale limitation
SPFL'adresse IP d'origine est-elle autorisée ?Réduit l'usurpation d'identité et les abus de la part des expéditeursLimite de 10 requêtes DNS ; interruption en cas de transfert
DKIMLe message a-t-il été modifié pendant son acheminement ?Protège l'intégrité des messagesNe vérifie pas l'adresse d'expéditeur visible
DMARCVérification de la cohérence entre l'SPF ou le DKIM et le domaine « De »Permet la mise en œuvre des politiques et la génération de rapportsNécessite l'SPF ation ou DKIM pour fonctionner
BIMIAffichage du logo de la marque pour les e-mails authentifiésRenforce la confiance envers la marque et sa visibilité dans la boîte de réceptionNécessite la configuration de DMARC avec p=quarantine ou p=reject
MTA-STSSécurité de transport TLS obligatoireEmpêche les attaques par dégradation et par interceptionNécessite l'hébergement d'un fichier de stratégie HTTPS
TLS-RPTSignalement des échecs de transmission TLSPermet d'identifier les problèmes au niveau de la couche de transportLes rapports JSON bruts sont difficiles à analyser manuellement
ARCChaîne d'authentification pour les e-mails transférésPréserve l'authentification lors du transfertNe fonctionne que si le serveur destinataire prend en charge ARC

SPF (Sender Policy Framework)

authentification par e-mail

Le Sender Policy Framework constitue la première ligne de défense. Le protocole « SPF » empêche l’usurpation d’identité en spécifiant les adresses IP autorisées à envoyer des e-mails depuis un domaine. Il valide l’expéditeur uniquement dans le champ « MAIL FROM » et ne tient pas compte de l’adresse « De » visible par le destinataire, car le protocole « SPF » se concentre sur l’enveloppe du message, à savoir le champ « Return-Path », plutôt que sur l’en-tête visible. Une adresse IP correspondante est acceptée ; toute autre est rejetée.

DKIM (DomainKeys Identified Mail)

Alors que le protocole « SPF » (SSPH-S) vérifie l’authenticité du serveur expéditeur, le protocole DKIM vérifie que le contenu n’a pas été altéré pendant le transit. Il ajoute une signature numérique à l’aide de clés cryptographiques : le serveur de l’expéditeur signe chaque message avec une clé privée, générant ainsi une signature DKIM qui est jointe aux en-têtes, puis le serveur destinataire récupère la clé publique correspondante via le DNS pour la vérifier. Si la signature correspond et que le contenu n’a pas été modifié, le contrôle DKIM est réussi, ce qui confirme que le message provient bien du domaine déclaré et qu’il n’a pas été altéré en cours de route.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC est le protocole qui rassemble tous ces éléments. Il vérifie si un e-mail entrant est conforme aux normes « SPF » ou DKIM, et si le domaine utilisé lors de ces vérifications correspond bien à l'adresse d'expéditeur. C'est précisément cette exigence de correspondance qui permet à DMARC de détecter efficacement les messages usurpés qui échappent aux contrôles « SPF » ou DKIM pris isolément, et il définit les mesures que le système destinataire doit prendre en cas d'échec.

Les options de la politique DMARC s'exécutent dans un ordre bien défini :

  • p=none : surveillance uniquement. Les messages ne sont pas affectés, mais vous recevez des rapports agrégés sur les résultats d'authentification pour l'ensemble des expéditeurs. Il s'agit du point de départ recommandé.
  • p=quarantine: les messages rejetés sont envoyés dans le dossier spam ou courrier indésirable. Utilisez cette option une fois que vous êtes certain que tous les expéditeurs légitimes sont acceptés.
  • p=rejet : les messages rejetés sont bloqués au niveau du serveur de réception. Il s'agit du niveau de protection le plus élevé, qui protège entièrement votre domaine contre l'usurpation d'identité.

DMARC génère également deux types de rapports : les rapports agrégés RUA, qui résument les résultats pour l'ensemble des expéditeurs, et les rapports d'analyse RUF, qui fournissent des détails au niveau de chaque message concernant les échecs ; ces deux types de rapports sont envoyés au format XML aux adresses indiquées dans votre enregistrement DMARC.

Autres méthodes : ARC, MTA-STS, TLS-RPT et BIMI

Le trio de base couvre la plupart des besoins. Quatre protocoles supplémentaires étendent la protection à des cas de figure spécifiques : le transfert, le transport chiffré, la visibilité du transport et l'affichage de la marque.

ARC (chaîne authentifiée reçue)

Si vous transférez des e-mails via des listes de diffusion, des systèmes de tickets ou d'autres intermédiaires, les messages transférés peuvent parfois ne pas passer les contrôles d'SPF s ou de DKIM. ARC résout ce problème en conservant les résultats d’authentification d’origine à chaque étape du transit. Lorsqu’un message transite par un intermédiaire de confiance, ARC enregistre les résultats à chaque étape et crée une chaîne signée cryptographiquement, que le serveur final vérifie pour confirmer que l’e-mail a bien été authentifié à l’origine, même si le transfert a rompu la signature d’origine. Il s’agit d’une source courante d’ échecs DMARC.

MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS exige des connexions SMTP chiffrées entre les serveurs de messagerie, empêchant ainsi les attaquants d'intercepter ou de convertir le trafic en texte clair lors d'attaques de type « man-in-the-middle ». Une fois configuré, il indique aux serveurs émetteurs qu'ils doivent utiliser le protocole TLS pour acheminer les e-mails vers votre domaine, et de refuser la livraison si une connexion sécurisée ne peut être établie.

Les services MTA-STS et TLS-RPT hébergés simplifient le déploiement en supprimant la nécessité d'héberger manuellement les fichiers de stratégie et d'analyser les rapports de transport, ce qui aide les organisations des secteurs de la finance, de la santé et du secteur public qui ont besoin d'un transit chiffré à des fins de conformité.

TLS-RPT (rapports SMTP TLS)

TLS-RPT offre aux propriétaires de domaines une visibilité sur les problèmes de livraison liés au chiffrement TLS, en indiquant quand les messages n'ont pas pu être transmis de manière sécurisée. Utilisé conjointement avec MTA-STS, il aide les équipes à détecter plus rapidement les attaques par rétrogradation, les erreurs de configuration des politiques et les défaillances de certificats. Sans cet outil, les défaillances de chiffrement se produisent de manière silencieuse, sans aucun signe indiquant qu'une connexion sécurisée n'a pas pu être établie.

BIMI (Indicateurs de marque pour l'identification des messages)

BIMI affiche un logo de marque vérifié dans la boîte de réception du destinataire à côté des messages authentifiés, apportant ainsi une preuve visuelle de leur légitimité. Pour que cela fonctionne, votre domaine doit disposer d’une politique DMARC d'au moins p=quarantine. Le logo renforce la reconnaissance de la marque, ce qui aide les destinataires à identifier instantanément les e-mails authentiques, ce qui peut augmenter les taux d’ouverture. BIMI est également une cible pour l’ l'usurpation de logo lorsque les domaines ne sont pas correctement sécurisés.

Un certificat « Verified Mark » (VMC) est nécessaire pour que la coche bleue s'affiche dans Gmail, et le service BIMI hébergé avec prise en charge VMC réduit les opérations de configuration manuelle requises. Si vous êtes prêt à en configurer un, ce guide pratique sur la publication d’un enregistrement BIMI vous explique la marche à suivre.

Comment fonctionne l'authentification des e-mails

L'authentification s'effectue sous la forme d'une série de vérifications automatiques entre le serveur émetteur et le serveur récepteur. Le déroulement de bout en bout se présente comme suit.

  1. L'expéditeur envoie un message. Votre serveur de messagerie envoie un e-mail au nom de votre domaine.
  2. Le serveur destinataire interroge le DNS. Il consulte les enregistrements DNS du domaine émetteur pour trouver les paramètres SPF, DKIM et DMARC.
  3. SPF Vérification. Le serveur vérifie si l’adresse IP de l’expéditeur figure parmi les adresses autorisées dans l’enregistrement SPF du domaine. Si c’est le cas, la vérification est réussie.
  4. Vérification DKIM. Le serveur récupère la clé publique DKIM à partir du DNS et vérifie la signature cryptographique sur les en-têtes du message. Une signature valide sur un contenu non modifié est acceptée.
  5. Vérification de la conformité DMARC et de la politique. DMARC vérifie si le domaine ayant passé l'SPF ation ou la validation DKIM correspond au domaine « De » visible. Si ce n'est pas le cas, il applique la politique du domaine : « none », « quarantine » ou « reject ».
  6. Décision finale de remise. Le fournisseur achemine, met en quarantaine ou rejette le message, puis renvoie des rapports agrégés DMARC au propriétaire du domaine.

Pourquoi l'authentification des e-mails est-elle importante ?

Le fait de ne pas procéder à une authentification engendre un risque réel pour l'entreprise dans cinq domaines qui ont tendance à se cumuler. Une authentification insuffisante entraîne rarement un seul problème isolé.

Protège la réputation de votre marque

L'authentification empêche les escrocs d'utiliser votre domaine pour envoyer des messages frauduleux. Lorsque des pirates usurpent votre domaine, les destinataires associent la tentative d’hameçonnage à votre marque, même si vous n’y êtes pour rien. Il est essentiel d’empêcher cela pour préserver la confiance de vos clients.

Empêche le phishing et l'usurpation d'identitécourriel d'hameçonnage

SPF, DKIM et DMARC fonctionnent conjointement pour vérifier l’identité de l’expéditeur avant que le message n’atteigne le destinataire, ce qui rend beaucoup plus difficile l’usurpation d’identité d’une marque de confiance. Sans ces contrôles, les pirates peuvent librement falsifier les adresses d’expéditeur et lancer des campagnes de compromission des e-mails professionnels. La distinction entre hameçonnage et l’usurpation d’identité est importante ici, car l’authentification permet de lutter contre l’usurpation d’adresse qui rend le phishing convaincant.

Améliore la délivrabilité des e-mails

Les e-mails authentifiés ont moins de chances d'être signalés comme spam par des fournisseurs tels que Gmail ou Outlook, ce qui permet aux messages légitimes d'arriver dans la boîte de réception. De nombreux fournisseurs exigent désormais DKIM et DMARC pour garantir une bonne distribution, et le respect de ces normes améliore les taux de livraison dans la boîte de réception.

Répond aux exigences de conformité

Google, Yahoo, Microsoft et Apple imposent tous l'SPF, le DKIM et le DMARC aux domaines envoyant plus de 5 000 e-mails par jour. Google applique cette règle de manière stricte depuis novembre 2025 en rejetant les e-mails non conformes.

Dans les secteurs réglementés tels que la finance, la santé, l'éducation, le commerce de détail et le secteur public, l'authentification contribue également à la mise en œuvre de programmes plus larges de conformité et de gestion des risques. Les exigences de Google, Microsoft, de la norme PCI DSS, des programmes alignés sur le RGPD et des réglementations gouvernementales régionales considèrent de plus en plus l'SPF, le DKIM et le DMARC comme des contrôles essentiels plutôt que comme de simples bonnes pratiques.

Vous offre visibilité et contrôle

DMARC, en particulier, fournit des rapports sur la manière dont votre domaine est utilisé pour envoyer des e-mails. Ces rapports mettent en évidence les expéditeurs non autorisés, les échecs d'authentification et les tentatives d'usurpation d'identité, autant d'informations sur lesquelles vous pouvez vous appuyer pour agir. Sans authentification, vous ne disposez d'aucune visibilité sur les performances ou la sécurité de vos e-mails au sein de votre infrastructure d'envoi.

Constitue un avantage stratégique

Les fournisseurs de messagerie récompensent de plus en plus les expéditeurs correctement authentifiés. Les entreprises qui mettent en œuvre cette pratique renforcent la confiance de leurs destinataires, rencontrent moins de problèmes de livraison et protègent leur infrastructure d'envoi contre les abus, ce qui leur donne une longueur d'avance sur leurs concurrents qui ne le font pas.

authentification par e-mail

Comment mettre en place l'authentification des e-mails

La mise en œuvre consiste à configurer les enregistrements DNS que les serveurs destinataires utilisent pour valider chaque message envoyé par votre domaine. Suivez les cinq étapes dans l'ordre, depuis la création de votre premier enregistrement TXT jusqu'à la mise en œuvre complète.

  1. Effectuez un audit de votre infrastructure d'envoi. Répertoriez toutes les sources qui envoient des e-mails au nom de votre domaine : serveurs de messagerie principaux, outils d'automatisation du marketing, CRM, service d'assistance, facturation et tout prestataire de services transactionnels. La plupart des échecs d'authentification sont dus à un expéditeur qui a été oublié ; cette étape est donc déterminante pour garantir la qualité de votre déploiement.
  2. Publiez votre enregistrement « SPF ». Créez un seul enregistrement TXT répertoriant toutes les adresses IP et tous les services d'envoi autorisés. Chaque mention compte dans la limite de 10 requêtes ; si cette limite est dépassée, la validation « SPF » échouera pour tous les messages.
  3. Configurez la signatureDKIM. Générez une paire de clés via votre fournisseur d'accès ou votre serveur de messagerie. La clé privée reste sur le serveur d'envoi et signe les e-mails sortants ; la clé publique est enregistrée dans le DNS sous forme d'enregistrement TXT afin que les destinataires puissent vérifier chaque signature.
  4. Ajoutez votre enregistrement DMARC. Publiez un enregistrement TXT DMARC en commençant par une politique « p=none » (surveillance uniquement), afin de pouvoir observer les résultats avant de l'appliquer. Un enregistrement de base se présente comme suit : v=DMARC1; p=none; rua=mailto:[email protected]; fo=1.
  5. Tester et valider. Envoyez un e-mail de test à partir de chaque source identifiée à l'étape 1 et examinez l'en-tête « Authentication-Results » pour vérifier les verdicts relatifs à l'SPF, au DKIM et au DMARC.

Erreur courante

Copier un exemple d’enregistrement « SPF » ou DMARC tel quel dans le DNS. Les exemples ci-dessus sont des modèles, et non des enregistrements prêts à l’emploi. Une ligne « SPF » incluant des services que vous n’utilisez pas gaspille des requêtes sur le plafond de 10 requêtes, et un enregistrement DMARC pointant vers une boîte de messagerie de rapport dont personne n’est propriétaire signifie que les données agrégées ne mènent nulle part. Adaptez ces deux éléments à vos propres expéditeurs et adresses de rapport avant de les publier.

Pour les enregistrements dont la taille dépasse la limite de recherche à mesure que les plateformes SaaS s'accumulent, un SPF outil d’aplatissement les maintient automatiquement dans les limites autorisées. Une fois les enregistrements mis en production, utilisez un analyseur de domaine pour valider en quelques secondes la configuration complète de l'SPF, du DKIM et du DMARC.

TâcheProtocoleRequisOutil
Vérifier toutes les sources d'envoi d'e-mailsTousOuiRapports manuels ou DMARC
Publier l'enregistrement TXT « SPF » dans le DNSSPFOuiSPF Générateur ou PowerSPF
Configurer la signature DKIM et publier la cléDKIMOuiGénérateur DKIM ou DKIM hébergé
Publier l'enregistrement DMARC avec p=noneDMARCOuiGénérateur DMARC
Examiner les rapports DMARC et corriger les échecsDMARCOuiTableau de bord PowerDMARC
Transférer les messages DMARC vers quarantine , puis les rejeterDMARCRecommandéAssistant de mise en œuvre
Déployer MTA-STS et TLS-RPTMTA-STS / TLS-RPTRecommandéMTA-STS / TLS-RPT hébergés
Configurer BIMI avec VMC ou CMCBIMIEn optionAssistance PowerBIMI / VMC

Problèmes d'authentification courants et comment les résoudre

Les défaillances surviennent généralement lorsque l'environnement d'envoi subit des changements. Les nouveaux outils SaaS, les expéditeurs régionaux, les services de transfert et les modifications du DNS ont tous une incidence sur l'SPF, le DKIM, le DMARC et la sécurité du transport. Vous trouverez ci-dessous les scénarios les plus courants et leurs solutions.

ÉchecComment y remédier
SPF dépasse 10 requêtes DNSUtilisez la fonction de « aplatissement » d'SPF ou la gestion automatisée pour rester en dessous de la limite sans effacer les enregistrements existants.
Expéditeur tiers non inclus dans SPFVérifier les sources d'envoi et ajouter le mécanisme d'inclusion du service manquant
Sélecteur DKIM manquant ou obsolèteEffectuer la rotation et surveiller les clés DKIM ; faire correspondre le sélecteur de signature à celui du DNS
Échec de l'alignement DMARCAlignez le champ « Return-Path » de l'SPF ou le domaine de signature DKIM avec le domaine « De » affiché
Les e-mails transférés échouent à l'authentificationDéployez ARC lorsque cela est pris en charge afin de préserver les résultats lors du transfert via des intermédiaires
Échecs de transmission TLSDéployez MTA-STS pour garantir une transmission chiffrée et surveillez TLS-RPT afin de détecter les défaillances
SPF ou bien DKIM est validé mais DMARC échoueLe domaine authentifié ne correspond pas au domaine « De » ; vérifiez le mode de correspondance et le domaine de signature.

Meilleures pratiques d'authentification des courriers électroniques

La publication des enregistrements constitue la première étape. Pour garantir une authentification solide à long terme, il faut adopter quelques habitudes régulières.

Commencez par surveiller, puis appliquez les règles.

Commencez par p=none pour collecter des données sans affecter la distribution. Analysez les rapports afin d'identifier tous les expéditeurs légitimes, corrigez les erreurs de configuration, puis passez progressivement à p=quarantine et p=reject à mesure que votre confiance s'accroît.

Veillez à ce que les registres d'SPF s soient à jour et respectent les limites fixées

Mettez à jour votre enregistrement « SPF » chaque fois que vous ajoutez ou supprimez un service d’envoi, car un enregistrement obsolète peut entraîner le rejet de courriers légitimes. Surveillez la limite de 10 requêtes à mesure que votre pile s’agrandit, car son dépassement entraînera l’échec de l’ensemble de la SPF vérification pour chaque message. Les organisations utilisant de nombreuses plateformes SaaS doivent surveiller en permanence la complexité de leur SPF et recourir à une gestion automatisée ou à un « aplatissement » pour éviter les défaillances à mesure que le nombre d’expéditeurs augmente.

Faites tourner régulièrement les clés DKIM

La rotation des clés DKIM permet de réduire le risque de compromission des clés. Il est recommandé de procéder à cette rotation tous les 6 à 12 mois, et immédiatement si vous soupçonnez que la clé privée a été compromise.

authentification par e-mail

Foire aux questions

Ai-je besoin d'SPF, DKIM et DMARC si j'utilise un fournisseur de services de messagerie ?

Oui. La plupart des prestataires de services de messagerie (ESP) partagent leur infrastructure d'envoi entre plusieurs clients ; il se peut donc que leur configuration par défaut n'authentifie pas entièrement votre domaine. Vous publiez vos propres enregistrements SPF, DKIM et DMARC ; le prestataire de services de messagerie vous aide à configurer la signature DKIM.

Quel protocole dois-je configurer en premier ?

SPF, puis DKIM, puis DMARC avec p=none. DMARC s'appuie sur les résultats d'SPF ou de DKIM pour fonctionner ; par conséquent, le mettre en place en premier sans que les deux autres soient déjà opérationnels ne vous donne aucun point de référence.

Quelle est la différence entre l'authentification et le chiffrement ?

L'authentification permet de vérifier l'identité de l'expéditeur d'un message et de s'assurer qu'il n'a pas été altéré. Le chiffrement protège le contenu pendant son transfert. Les protocoles MTA-STS et TLS-RPT gèrent l'aspect chiffrement ; les protocoles « SPF », DKIM et DMARC gèrent l'aspect identité.

Pourquoi mes e-mails transférés ne passent-ils pas l'authentification ?

Le transfert via des listes de diffusion ou des systèmes de gestion des tickets peut altérer la signature « SPF » ou DKIM d'origine. ARC préserve les résultats d'origine à chaque étape du transfert ; ainsi, un serveur destinataire prenant en charge ARC peut continuer à considérer le message comme fiable.

Combien de temps faut-il pour que l'authentification prenne effet ?

Les modifications apportées au DNS se propagent en quelques minutes à quelques heures, selon la valeur du TTL. Il faut compter entre quelques jours et quelques semaines pour que des données significatives issues des rapports DMARC s'accumulent sur l'ensemble de vos sources d'envoi.

Puis-je passer directement à « p=reject » ?

Cette pratique est fortement déconseillée. Sans période de surveillance (p = none), vous ne pouvez pas identifier les expéditeurs légitimes qui rencontrent des problèmes, et le fait de passer directement au rejet risque de bloquer vos propres factures et vos e-mails transactionnels.

authentification par e-mail