Rapports d'échec DMARC (RUF) : définition, fonctionnement et mise en place sécurisée

Publication d'un enregistrement DMARC constitue une étape importante pour protéger votre domaine contre l'usurpation d'identité, le hameçonnage et l'utilisation non autorisée des e-mails. Cependant, la véritable valeur opérationnelle réside dans les rapports qui indiquent si les expéditeurs légitimes passent l'authentification des e-mails et où se produisent les échecs.

De nombreuses équipes d'entreprise s'appuient sur les rapports agrégés DMARC pour surveiller l'état général de leur domaine, mais ces synthèses peuvent ne pas fournir suffisamment de détails pour la gestion des incidents, les enquêtes de conformité ou le dépannage complexe lié à des expéditeurs tiers. Les rapports d'échec DMARC (RUF) apportent un contexte au niveau des messages qui peut aider les équipes de sécurité et informatiques à identifier plus rapidement la source des échecs d'authentification. 

Ce guide explique ce que sont les rapports RUF, en quoi ils diffèrent des données agrégées et comment les utiliser efficacement.

Qu'est-ce qu'un rapport d'échec DMARC ?

Un rapport d'échec DMARC (également appelé « rapport d'échec » ou « rapport RUF ») est une notification détaillée, envoyée en temps quasi réel par les serveurs de messagerie destinataires lorsqu'un message échoue à l'authentification DMARC. Il fournit des diagnostics au niveau du message, notamment les résultats de l'authentification, la source d'envoi et les en-têtes du message, afin que les propriétaires de domaines puissent enquêter sur d'éventuelles tentatives d'usurpation d'identité et résoudre les problèmes d'authentification des e-mails.

Note terminologique : Les termes « rapport d'échec DMARC », « rapport d'échec DMARC » et « rapport RUF » désignent tous le même type de rapport. Le format sous-jacent est l'AFRF (Authentication Failure Reporting Format), défini dans la RFC 6591, qui est une extension spécifique à DMARC de l'ARF (Abuse Reporting Format, RFC 5965). Ces termes sont souvent utilisés de manière interchangeable dans le secteur.

• Qui les génère ? Les serveurs de messagerie récepteurs, les FAI, les passerelles de messagerie d'entreprise et les dispositifs de sécurité, mais uniquement lorsqu'ils prennent en charge le protocole RUF et détectent un échec d'authentification. Les propriétaires de domaines demandent des rapports via la balise « ruf= », mais ce sont les destinataires qui décident de les envoyer ou non, en fonction de leurs propres politiques de confidentialité et de leur configuration.
• Où est-il envoyé ? Il est envoyé à l'adresse e-mail indiquée dans la balise « ruf= » de votre enregistrement DNS DMARC.
• Quel format utilise-t-il ? Contrairement aux rapports agrégés, qui sont fournis sous forme de fichiers XML, les rapports RUF utilisent le format AFRF (Authentication Failure Reporting Format) afin de fournir des données détaillées sur les échecs d'authentification dans un format plus lisible par l'utilisateur.

Quelles informations figurent dans les rapports d'échec DMARC ?

En raison de RUF les rapports DMARC sont conçus pour un dépannage approfondi, ils contiennent des métadonnées spécifiques sur le message ayant échoué que vous ne trouverez pas dans les rapports agrégés. Un rapport RUF type comprend :

• Adresse IP de l'expéditeur : l'adresse IP exacte qui a tenté d'envoyer le message
• Adresses « De » et « Return-Path » : l'en-tête « From » et l'expéditeur de l'enveloppe
• Objet : l'objet réel de l'e-mail qui n'a pas pu être envoyé
• Résultats de l'authentification : des détails précis expliquant pourquoi SPF ou DKIM a échoué et si l'alignement DMARC a été établi
• En-têtes du message : les en-têtes complets du message
• Heure de réception : l'horodatage correspondant au moment où le message est arrivé sur le serveur destinataire
• Politique DMARC appliquée : la politique qui a été appliquée au message, qu'il s'agisse de « none », « quarantine » ou « reject »
• Résultat de la remise : si le message a été remis, mis en quarantaine ou rejeté
• Informations à caractère personnel (ICP) : comme ces rapports peuvent inclure des objets et des adresses de destinataires, ils contiennent souvent des informations personnelles identifiables

Note relative à la confidentialité

En raison de la présence d'informations personnelles identifiables (PII), de nombreux grands fournisseurs de messagerie ont choisi de ne plus envoyer de rapports RUF afin de protéger la vie privée des utilisateurs. PowerDMARC résout ce problème en prenant en charge le chiffrement PGP pour les rapports RUF, de sorte que les données sensibles restent chiffrées et ne soient accessibles qu’à vous. Certains destinataires qui envoient des rapports RUF masquent au préalable les parties sensibles du corps du message ou de l’objet ; c’est pourquoi certains rapports d’échec arrivent vides ou contiennent des chaînes de caractères [REDACTED].

Exemple de rapport d'échec DMARC : comment interpréter chaque champ

Pour comprendre ce qui se passe en arrière-plan, examinez les données brutes. Lorsqu'un e-mail échoue, le destinataire génère un rapport au format AFRF. Voici un exemple utilisant des domaines réservés et des plages d'adresses IP conformément à la RFC 5737.

Interprétation champ par champ

Conseil pratique

Lorsque vous examinez un rapport RUF, posez-vous les quatre questions suivantes dans l'ordre. L'adresse IP source figure-t-elle dans votre liste d'expéditeurs approuvés ? La validation SPF ou DKIM a-t-elle échoué, ou les deux ? L'en-tête « Original-Mail-From » correspond-il à votre domaine ? S'agit-il d'un cas limite de redirection ou d'un relais de liste de diffusion ? Si vous ne pouvez pas répondre à ces questions avec certitude, transmettez le rapport à votre équipe de sécurité pour qu'elle mène une enquête.

À quoi ressemble l'enregistrement dans votre DNS ?

Pour recevoir ces rapports, votre enregistrement DMARC doit inclure la balise « ruf= ». Voici un exemple représentatif :

Si vous envoyez des rapports vers un domaine différent du vôtre, le domaine de destination doit publier un enregistrement DNS l'autorisant à recevoir des rapports en votre nom. Décomposition des balises :

• v=DMARC1: balise de version standard identifiant le protocole DMARC
• p=none : mode de surveillance ; les messages ne sont ni rejetés ni mis en quarantaine, et les destinataires sont invités à signaler les résultats de l'authentification
• rua=: destination des rapports quotidiens agrégés résumant l'ensemble de l'activité d'authentification
• ruf=: la destination des rapports d'erreur ; acheminez-les vers une plateforme de traitement sécurisée et dédiée plutôt que vers une boîte de réception générale
• fo=1 : demande aux destinataires de générer un rapport en cas d'échec de la validation SPF ou DKIM

Rapport agrégé DMARC et rapport d'échec : RUA et RUF

Ces deux types de rapports sont configurés au sein du même enregistrement DMARC, mais ils ont des objectifs distincts. Le RUA offre une visibilité globale sur le domaine au fil du temps ; le RUF fournit des détails au niveau des messages pour des échecs spécifiques. Pour une analyse plus approfondie, consultez cette comparaison des rapports RUA et RUF.

Comment activer les rapports d'échec DMARC dans votre enregistrement DNS

Pour activer RUF, vous devez mettre à jour votre enregistrement TXT DMARC existant dans le DNS. Suivez les étapes suivantes.

1. Accédez à votre fournisseur DNS. Connectez-vous à la console de gestion DNS de votre domaine.
2. Recherchez votre enregistrement TXT DMARC. Recherchez l'enregistrement TXT publié à l'adresse _dmarc.votredomaine.com.
3. Ajoutez la destination RUF. Insérez une adresse ruf=mailto: à laquelle les rapports d'erreur pris en charge doivent être envoyés.
4. Configurer les options en cas d'échec. Ajoutez la balise « fo= » pour définir quand les rapports doivent être générés ; ce point sera abordé dans la section suivante.
5. Utilisez un traitement sécurisé. Acheminez les rapports vers une plateforme sécurisée telle que PowerDMARC plutôt que vers une boîte de réception standard.
6. Enregistrez et attendez la propagation. La propagation des modifications DNS à l'échelle mondiale peut prendre jusqu'à 48 heures.

L'envoi des rapports RUF vers une boîte de réception standard génère du « bruit » et augmente le risque d'exposition des données. Une plateforme de reporting centralise les données DMARC, transforme les données d'authentification brutes en tableaux de bord lisibles et établit des corrélations entre les échecs et les résultats d'alignement d'SPF, DKIM et DMARC, afin que les équipes puissent identifier plus rapidement les problèmes.

Explication du DMARC pour les balises : quand les rapports d'échec sont-ils déclenchés ?

La balise « fo » est un élément de l'enregistrement DMARC qui indique au serveur destinataire quand générer un rapport d'échec.

La plupart des professionnels de la sécurité utilisent fo=1, car cela offre une visibilité maximale sur les échecs d’authentification. Cela dit, fo=1 doit être acheminé vers une plateforme de traitement dédiée et sécurisée plutôt que vers la boîte de réception d’un utilisateur. Le volume de rapports générés peut devenir ingérable sans automatisation, et leur envoi vers une boîte de réception non protégée augmente l’exposition des données sensibles contenues dans les messages. A échec DKIM peut notamment générer un afflux de rapports qu’il convient d’isoler d’une boîte aux lettres partagée.

Pourquoi vous ne recevez peut-être pas les rapports d'échec DMARC

Si vous avez activé RUF mais que votre destination de rapport est vide, cela n'indique pas nécessairement une erreur de configuration. Plusieurs facteurs courants peuvent expliquer l'absence de rapports reçus.

C'est pourquoi les données agrégées rapports RUA sont considérés comme la source de référence pour la surveillance globale de l’état de santé du domaine, tandis que les rapports RUF servent d’outil d’investigation complémentaire pour des scénarios de défaillance spécifiques.

Questions relatives à la confidentialité et à la sécurité

Étant donné que les rapports RUF peuvent contenir des objets, des adresses de destinataires, des en-têtes et parfois le contenu des messages, ils doivent être traités avec précaution dans le cadre de réglementations relatives à la protection de la vie privée telles que le RGPD et CCPA. Pour les organisations évoluant dans des secteurs réglementés tels que la finance, la santé, l'éducation, le commerce de détail et l'administration publique, les données de défaillance doivent être traitées via des systèmes sécurisés, dotés de contrôles d'accès, et respectant les obligations en matière de confidentialité et de conformité.

Pour les organisations qui doivent se conformer aux exigences de Google, Microsoft, de la norme PCI DSS, du RGPD ou aux exigences gouvernementales en matière d'authentification des e-mails, il est essentiel de disposer de workflows de reporting sécurisés. Les données RUF peuvent faciliter les enquêtes, mais une visibilité globale sur le protocole DMARC, le suivi des progrès en matière d'application de la norme et la gestion des expéditeurs authentifiés restent indispensables pour garantir la conformité à long terme.

Bonnes pratiques

• Utilisez une plateforme de signalement dédiée et sécurisée.
• Activer le chiffrement PGP : un modèle « apportez votre propre clé » signifie que seuls les utilisateurs autorisés disposant de la clé privée peuvent consulter le contenu sensible des rapports de défaillance.
• Limiter l'accès aux données relatives aux défaillances en fonction des rôles et des besoins opérationnels.
• Définir des politiques de conservation des données RUF stockées, conformément à la réglementation applicable en matière de protection de la vie privée.
• Procédez à une analyse juridique avant d'activer la fonctionnalité RUF dans les juridictions soumises à des exigences strictes en matière de protection des données.

Comment utiliser les rapports RUF pour détecter l'usurpation d'identité et résoudre les défaillances

Dès que vous commencez à recevoir des données d'échec, considérez chaque rapport comme un indice à examiner plutôt que comme un verdict définitif. Vérifiez la validité des résultats en les recoupant avec les listes d'expéditeurs approuvées, les tendances globales DMARC, les journaux de la passerelle de messagerie et les informations sur les menaces avant de prendre des décisions correctives. Cinq scénarios couvrent la plupart des cas mis en évidence par les données d'échec.

Détection de l'usurpation de nom de domaine

Si un rapport d'échec identifie une adresse IP source non reconnue utilisant votre domaine dans le champ « From » de l'en-tête, considérez cela comme un signal nécessitant une enquête. Vérifiez d'abord cette adresse source en la comparant aux listes d'expéditeurs approuvés, aux tendances agrégées, aux journaux de passerelle et aux informations sur les menaces. Si elle s'avère non autorisée, l'adresse IP peut être ajoutée aux listes noires et votre centre des opérations de sécurité peut en être informé.

Correction des erreurs légitimes

Il arrive parfois que des e-mails légitimes ne parviennent pas à leur destinataire parce que l’expéditeur tiers n’est pas correctement configuré, qu’un sélecteur DKIM est mal configuré ou que l’enregistrement « SPF » du domaine est devenu trop complexe. Une plateforme de reporting aide les équipes à identifier ces échecs dans leur contexte et à simplifier la gestion de l’ SPF , grâce à l’hébergement de l’ SPF et à l’aplatissement automatisé, ce qui réduit le risque de problèmes de livraison à mesure que de nouveaux outils SaaS sont ajoutés.

Diagnostic des défaillances liées au transfert

Le transfert d'e-mails entraîne souvent une rupture de l'authentification « SPF », car l'adresse IP du serveur de transfert ne figure pas dans l'enregistrement « SPF » de l'expéditeur d'origine. Si un rapport RUF signale des échecs provenant d'un service de transfert reconnu ou d'un relais de liste de diffusion, la cause est probablement une rupture de l'authentification « SPF » plutôt qu'une tentative d'usurpation d'identité. Dans ces cas, vérifiez si la validation DKIM est toujours réussie, car les signatures DKIM résistent généralement au transfert, et si la politique DMARC peut être respectée grâce à l'alignement DKIM seul.

Détection de l'informatique parallèle et des expéditeurs non autorisés

Les rapports RUF peuvent mettre en évidence des sources d'envoi que les équipes informatiques n'ont pas autorisées ou dont elles n'ont pas connaissance, comme par exemple une équipe marketing qui aurait connecté un nouvel outil d'automatisation sans mettre à jour l'enregistrement « SPF ». Si un rapport d'échec signale un échec provenant d'une adresse IP appartenant à une plateforme SaaS récemment adoptée, il s'agit d'une lacune de configuration plutôt que d'une attaque. Ajoutez le service à votre liste d'expéditeurs autorisés et mettez à jour votre enregistrement DMARC en conséquence.

Déroulement de l'enquête

1. Identifiez l'adresse IP source dans le rapport RUF.
2. Vérifier l'autorisation : cette adresse IP est-elle associée à un outil ou à un service utilisé par votre organisation ?
3. Vérifier la cohérence : examiner les résultats de l'SPF ation et du DKIM dans le champ « Authentication-Results ».
4. Vérifiez le comportement de transfert ou de liste de diffusion : déterminez si l'échec de l'SPF ation provient d'un relais intermédiaire.
5. Classer le risque : expéditeur autorisé présentant une erreur de configuration, expéditeur non autorisé, artefact de transfert ou source issue de l'informatique parallèle.
6. Correction : si l'autorisation est accordée mais que la vérification échoue, corrigez l'alignement de l'SPF ou du DKIM. Si l'autorisation n'est pas accordée, utilisez votre politique DMARC avec p=quarantine ou p=reject pour appliquer la protection.
7. Suivi à l'aide de rapports agrégés : vérifiez l'efficacité des mesures correctives en examinant les rapports RUA ultérieurs.

Quand il vaut mieux activer le RUF, et quand il vaut mieux ne pas le faire

L'option RUF n'est pas activée par défaut pour tous les domaines. Sa pertinence dépend des destinataires des rapports et de leur finalité. Trois situations justifient son utilisation, tandis que deux autres s'y opposent.

• Activez cette fonctionnalité lorsque vous disposez d'une équipe de sécurité capable d'exploiter ces données. Les analystes du SOC et les équipes d'intervention en cas d'incident utilisent les détails au niveau des messages pour enquêter sur les cas confirmés d'usurpation d'identité, ce qui constitue l'utilisation la plus pertinente de ce rapport.
• Activez cette option lors d'un dépannage en cours. Lorsqu'un expéditeur tiers rencontre des défaillances répétées et que les données agrégées ne sont pas suffisamment précises, les détails de la défaillance concernant l'adresse IP exacte et le résultat de l'alignement permettent d'accélérer le diagnostic.
• Activez cette fonctionnalité dans les environnements réglementés où un traitement sécurisé est déjà en place. Si vous utilisez déjà un système de reporting chiffré et à accès contrôlé, cette profondeur d'analyse supplémentaire ne présente qu'un risque marginal.
• Réfléchissez-y à deux fois si les rapports devaient être envoyés dans une boîte de réception partagée. Sans chiffrement ni contrôles d'accès, la réception de rapports contenant des informations personnelles identifiables (PII) crée un risque de non-conformité qui l'emporte sur les avantages.
• Réfléchissez-y à deux fois si personne n'est responsable des résultats. Un volume élevé de données (fo=1) sans analyste pour les trier devient du bruit, et les rapports agrégés couvrent déjà la surveillance de l'état du domaine.

Par défaut, la plupart des équipes privilégient l'approche « agrégée ». Elles exécutent d'abord RUA pour évaluer l'état du domaine et suivre l'avancement de la mise en conformité, puis activent délibérément RUF lorsqu'une enquête ou un problème récurrent avec un expéditeur nécessite une analyse approfondie au niveau des messages, redirigée vers une plateforme conçue pour gérer les données sensibles.

Limites des rapports d'échec DMARC

Il est tout aussi important de comprendre ce que les rapports RUF ne permettent pas de faire que de savoir ce qu’ils permettent de faire. Considérez les rapports d’échec comme un outil d’investigation complémentaire plutôt que comme le principal indicateur sur lequel fonder les décisions relatives au programme DMARC.

• Prise en charge limitée par les fournisseurs : les principaux fournisseurs de messagerie, notamment Gmail et Microsoft 365, n'envoient généralement pas de rapports RUF pour des raisons de confidentialité ; la couverture des échecs est donc intrinsèquement incomplète
• Données masquées : les destinataires qui envoient des rapports peuvent masquer les objets, le corps des messages ou les adresses des destinataires avant la remise
• Faux positifs liés au transfert : les relais de listes de diffusion et les services de transfert provoquent fréquemment des échecs d'SPF qui ressemblent à des échecs d'authentification, mais qui ne sont pas des tentatives d'usurpation d'identité
• Volume des rapports et bruit : avec fo=1, les expéditeurs à fort volume peuvent recevoir un nombre ingérable de rapports, dont beaucoup reflètent un comportement de transfert attendu plutôt que de véritables menaces
• Ne remplace pas le RUA : les rapports agrégés restent la source faisant autorité en matière d'état de santé de l'authentification à l'échelle du domaine ; le RUF doit donc compléter, plutôt que remplacer, la surveillance continue de la RUA
• Risque d'exposition des données à caractère personnel : en l'absence de chiffrement et de contrôles d'accès, le simple fait de recevoir des rapports RUF peut en soi entraîner des obligations de conformité au titre du RGPD, du CCPA et d'autres cadres réglementaires similaires

Comment les MSP peuvent exploiter les rapports d'échec DMARC sur l'ensemble des domaines de leurs clients

Pour les MSP et les MSSP, les rapports d'échec constituent une ressource précieuse lorsqu'un client signale des messages manquants, des cas présumés d'usurpation d'identité ou des échecs d'authentification inexpliqués. Les rapports RUF bruts sont toutefois difficiles à gérer à grande échelle. Ils peuvent contenir des données sensibles sur les clients, provenir simultanément de plusieurs domaines et nécessiter une corrélation avec d'autres signaux d'authentification pour être exploitables.

• Visibilité multi-domaines : l'agrégation des rapports provenant de dizaines, voire de centaines de domaines clients, en l'absence d'une plateforme centralisée, nécessite un travail manuel considérable
• Traitement des données sensibles : Les rapports RUF provenant des domaines des clients peuvent contenir des informations personnelles identifiables (PII) des clients finaux, ce qui impose des obligations de conformité au MSP
• Gestion du volume des rapports : les domaines clients à fort volume peuvent générer un grand nombre de rapports d'erreur qui surchargent les flux de travail des techniciens
• Accès basé sur les rôles : les techniciens ne doivent avoir accès qu'aux rapports concernant les domaines clients qui leur ont été attribués

Une plateforme centralisée telle que PowerDMARC destinée aux MSP et aux MSSP aide les prestataires de services à traiter les données RUF en toute sécurité, à séparer les domaines des clients, à réduire le temps consacré aux investigations manuelles et à permettre aux techniciens d'identifier rapidement quel expéditeur, quelle adresse IP ou quel mécanisme d'authentification est à l'origine d'un échec, sans exposer inutilement des données sensibles.

Comment PowerDMARC facilite la gestion des rapports d'échec DMARC

PowerDMARC traite les données relatives aux échecs DMARC en toute sécurité et transforme les échecs d'authentification bruts en informations exploitables. Au lieu d'envoyer des rapports RUF sensibles vers une boîte de réception standard, les équipes consultent ces rapports dans un tableau de bord centralisé, protègent les données sensibles grâce au chiffrement PGP et établissent des corrélations entre les échecs et les résultats d'alignement d'SPF, DKIM et DMARC.

• Une visibilité claire : identifiez plus rapidement les sources d'envoi défaillantes, les résultats d'authentification et les adresses IP suspectes sur l'ensemble de vos domaines
• Traitement sécurisé : le chiffrement PGP avec un modèle « apportez votre propre clé » réduit l'exposition des données sensibles relatives aux défaillances, de sorte que même PowerDMARC ne peut pas lire le contenu chiffré
• Gestion centralisée : surveillez DMARC, l'SPF, DKIM, BIMI, MTA-STS et TLS-RPT à partir d'une seule plateforme, sans avoir à changer d'outil ni à analyser du code XML brut
• Correction plus rapide : résolvez les problèmes liés aux expéditeurs légitimes et aux tentatives d’usurpation d’identité sans avoir à analyser manuellement les rapports AFRF, grâce à l’ SPF hébergée et à l’aplatissement automatisé, afin de réduire les échecs de livraison à mesure que de nouveaux outils SaaS sont ajoutés
• Préparation à la conformité : pistes d'audit, contrôles d'accès basés sur les rôles et prise en charge des exigences de Google, Microsoft, PCI DSS, du RGPD et des autorités publiques en matière d'expéditeurs

Foire aux questions

Qu'est-ce qu'un rapport d'échec DMARC, exactement ?

Rapport d'échec généré en temps quasi réel lorsqu'un e-mail individuel ne satisfait pas aux contrôles d'authentification définis par votre politique DMARC et vos options en cas d'échec. Il contient des détails au niveau du message, contrairement aux rapports agrégés, qui résument l'activité de l'ensemble des messages sur une période de 24 heures.

En quoi le RUF diffère-t-il du RUA ?

Le protocole RUA fournit un résumé quotidien au niveau du domaine, au format XML, couvrant l'ensemble des messages. Le protocole RUF fournit des informations en temps quasi réel sur les messages individuels ayant échoué, au format AFRF (RFC 6591, qui étend le format ARF de la RFC 5965) ; il contient des détails spécifiques à chaque message et peut inclure des données à caractère personnel. Ce n'est pas le cas du protocole RUA.

Comment puis-je activer ces rapports ?

Ajoutez ruf=mailto:[email protected] à votre enregistrement TXT DMARC sur _dmarc.votredomaine.com. Indiquez « fo=1 » pour recevoir un rapport en cas d'échec de la validation SPF ou DKIM. Redirigez les rapports vers une plateforme sécurisée plutôt que vers une boîte de réception standard.

J'ai installé RUF, mais je n'obtiens aucun résultat. Est-ce qu'il ne fonctionne pas ?

Pas nécessairement. De nombreux fournisseurs n'envoient pas de RUF pour des raisons de confidentialité, et aucun rapport n'est généré lorsque les messages transitent. Si vous recevez des rapports RUA agrégés, vos données sont probablement correctes. Consultez le tableau de dépannage pour connaître les autres causes possibles.

Tous les fournisseurs de messagerie envoient-ils des rapports d'échec DMARC ?

Non. Gmail et Microsoft 365 ne le font généralement pas, invoquant la protection de la vie privée des utilisateurs. La prise en charge se limite aux destinataires ayant mis en place la prise en charge du protocole RUF, à savoir, en général, certaines passerelles de messagerie d'entreprise, certains FAI et certains serveurs de messagerie indépendants. Il s'agit là d'une limitation majeure.

Peut-on recevoir sans risque les rapports d'échec DMARC ?

Ils peuvent contenir des données à caractère personnel, telles que les objets des e-mails, les adresses des destinataires et les en-têtes. Leur réception sans mesures de contrôle peut entraîner des obligations au titre du RGPD et du CCPA. La solution la plus sûre consiste à les acheminer vers une plateforme sécurisée dotée d'un chiffrement PGP, d'un accès basé sur les rôles et d'une politique de conservation définie.

À quoi sert la balise « fo » ?

Cet acronyme signifie « Failure Options » (options d'échec) et définit les conditions dans lesquelles les destinataires génèrent un rapport. La valeur fo=0 (par défaut) exige que les vérifications « SPF » et DKIM échouent toutes les deux. La valeur fo=1 déclenche l'envoi en cas d'échec de l'une ou l'autre de ces vérifications. La valeur fo=d se déclenche uniquement en cas d'échec de la vérification DKIM ; la valeur fo=s, uniquement en cas d'échec de la vérification « SPF ».

• À propos de
• Derniers messages

Milena Baghdasaryan

Spécialiste du contenu chez PowerDMARC

Milena est une rédactrice et créatrice de contenu qualifiée qui possède plus de 7 ans d'expérience dans la création de contenu attrayant sur les technologies de l'information, la cybersécurité, les événements virtuels, etc. Elle est diplômée d'institutions prestigieuses telles que la New York University Abu Dhabi, l'UWC China et le Collège d'Europe.

Derniers messages de Milena Baghdasaryan (voir tous)

• « Répondre » ou « Répondre à tous » : règles de courtoisie et risques de sécurité - 14 août 2026
• Rapports d'échec DMARC (RUF) : définition, fonctionnement et mise en place sécurisée - 11 août 2026
• L'authentification par e-mail dans les plus grandes entreprises d'IA au monde - 10 août 2026