Dernière mise à jour : juillet 2026

En bref : Le tag fo= (Failure Reporting Options) dans un enregistrement DMARC contrôle les conditions exactes dans lesquelles un serveur récepteur génère et envoie un rapport d’échec forensique (via ruf=). Il permet de choisir entre recevoir des alertes uniquement lors d’échecs complets d’authentification ou dès qu’un mécanisme individuel (SPF ou DKIM) échoue.

Lorsque tu actives les rapports d’échec détaillés en publiant une adresse ruf=, les serveurs de messagerie récepteurs ont besoin de règles précises pour savoir quand t’envoyer ces rapports de diagnostic individuels. Si tu veux surveiller les moindres anomalies ou si tu ne souhaites être alerté qu’en cas de rejet d’un message, tu le définis grâce au tag fo=.

Les options du tag fo= selon la RFC 7489

Selon la norme RFC 7489, le tag fo= accepte une liste de valeurs séparées par des deux-points parmi quatre indicateurs de base : 0, 1, d et s. S’il n’est pas spécifié dans la chaîne TXT publiée, DMARC applique par défaut la valeur 0.

Selon la RFC 7489, le protocole définit : fo: Failure reporting options (plain-text colon-separated list; OPTIONAL; default is "0".)

Voici comment se comporte chacune des quatre options de déclenchement :

1. Échec complet (fo=0 — valeur par défaut)

Si l’enregistrement omet le tag fo= ou déclare explicitement fo=0, les serveurs récepteurs génèrent un rapport d’échec uniquement lorsque le message échoue à la fois à l’évaluation SPF et à l’évaluation DKIM. Selon la RFC 7489 : 0: Generate a DMARC failure report if all underlying authentication mechanisms fail to produce an aligned "pass" result.

Dans ce mode, si un e-mail a une signature DKIM défaillante mais réussit l’alignement SPF, DMARC considère le message comme authentifié et aucun rapport d’échec n’est envoyé.

2. Échec de l’un ou l’autre des mécanismes (fo=1 — recommandé pour le dépannage)

L’option fo=1 est la configuration de diagnostic la plus populaire chez les administrateurs sécurité. Selon la RFC 7489 : 1: Generate a DMARC failure report if any underlying authentication mechanism produced something other than an aligned "pass" result.

Avec fo=1, un rapport forensique est envoyé dès qu’un seul mécanisme échoue. Par exemple, si l’alignement SPF réussit mais que la signature DKIM est rompue ou manquante, tu reçois immédiatement une alerte. C’est idéal pour détecter des serveurs qui oublient de signer les messages avant même que la délivrabilité globale ne soit impactée.

3. Échecs d’évaluation DKIM (fo=d)

L’option fo=d se concentre exclusivement sur les erreurs de signature cryptographique : d: Generate a DKIM failure report if the message had a signature that failed evaluation, regardless of its alignment.

Elle alerte l’équipe de sécurité chaque fois qu’une signature DKIM est invalide, qu’il s’agisse d’une clé publique révoquée, d’une corruption du corps du message en transit ou d’un sélecteur mal configuré.

4. Échecs d’évaluation SPF (fo=s)

L’option fo=s cible uniquement les évaluations d’adresse IP : s: Generate an SPF failure report if the message failed SPF evaluation, regardless of its alignment.

Elle envoie un rapport chaque fois qu’un serveur échoue à la vérification SPF sous-jacente, permettant d’identifier rapidement des adresses IP manquantes dans l’enregistrement SPF ou des problèmes de relais de messagerie.

Un enregistrement DMARC complet combinant les rapports forensiques avec fo=1 ressemble à ceci :

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; fo=1

Vérifier ta configuration

Pour vérifier comment tes options de rapport d’échec sont analysées et confirmer que ta syntaxe DMARC globale est conforme aux exigences de la RFC, teste ton domaine avec le scanner gratuit MXAudit.

Pour des guides techniques complets sur la gestion des rapports et les configurations spécifiques par hébergeur, consulte le guide complet DMARC et des tutoriels pratiques comme configurer DMARC chez IONOS.

Pour aller plus loin