← RFC Reference

RFC 6591 : Signalement des Défaillances d'Authentification (AFRF)

Pourquoi cela existe

Les mécanismes d'authentification des e-mails comme SPF, DKIM et DMARC détectent les messages usurpés ou non autorisés. Lorsque ces vérifications échouent, le serveur destinataire prend des mesures (rejeter, mettre en quarantaine ou autoriser). Mais le propriétaire du domaine — celui qui est usurpé — doit connaître ces échecs pour :

• Détecter l'utilisation non autorisée de son domaine (hameçonnage, usurpation)
• Identifier les expéditeurs légitimes mal configurés (par exemple, une plateforme marketing qui ne signe pas avec DKIM)
• Déboguer les problèmes d'enregistrements d'authentification (inclusions SPF cassées, clé DKIM incorrecte)
• Établir une image des modèles d'attaque avant de basculer DMARC vers p=reject

Les rapports agrégés DMARC (rua) fournissent des résumés statistiques, mais n'incluent pas les détails des messages. Les rapports médico-légaux DMARC (ruf) utilisent le format AFRF défini par cette RFC pour fournir des détails par message : les en-têtes réels, les résultats d'authentification et la raison d'échec spécifique.

La RFC 6591 étend la RFC 5965 (ARF) en ajoutant le type de rapport Feedback-Type: auth-failure et en définissant des champs supplémentaires pour les données spécifiques à l'authentification.

Comment cela fonctionne

Un rapport AFRF est un message ARF (multipart/report avec report-type=feedback-report) où la partie lisible par machine utilise Feedback-Type: auth-failure et inclut des champs spécifiques à l'authentification.

Exemple de rapport AFRF

From: dmarc-reporter@receiver.example.com
To: dmarc-ruf@example.com
Subject: Auth failure report for example.com
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
    boundary="AFRF-BOUNDARY-001"

--AFRF-BOUNDARY-001
Content-Type: text/plain

Authentication failure report for a message claiming
to be from example.com, received from IP 192.0.2.55.

--AFRF-BOUNDARY-001
Content-Type: message/feedback-report

Feedback-Type: auth-failure
User-Agent: Receiver-DMARC/2.0
Version: 1
Original-Mail-From: spoofed@example.com
Arrival-Date: Tue, 10 Mar 2026 16:42:00 -0500
Source-IP: 192.0.2.55
Auth-Failure: dmarc
Authentication-Results: receiver.example.com;
    dkim=fail header.d=example.com;
    spf=fail smtp.mailfrom=spoofed@example.com;
    dmarc=fail header.from=example.com
Reported-Domain: example.com
DKIM-Domain: example.com
Delivery-Result: reject

--AFRF-BOUNDARY-001
Content-Type: text/rfc822-headers

From: ceo@example.com
To: finance@receiver.example.com
Subject: Urgent wire transfer needed
Message-ID: <fake-msg-001@192.0.2.55>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com;
    s=selector1; b=INVALID...

--AFRF-BOUNDARY-001--

Détails techniques clés

Champs ajoutés par la RFC 6591

Ces champs apparaissent dans la partie message/feedback-report aux côtés des champs ARF standard :

Valeurs Auth-Failure

Relation avec la création de rapports DMARC

DMARC (RFC 7489) définit deux adresses de rapport dans son enregistrement DNS :

• rua — rapports agrégés (XML). Résumés statistiques des résultats d'authentification pour tous les messages.
• ruf — rapports médico-légaux. Détails par message utilisant le format AFRF défini par cette RFC.

En pratique, la création de rapports médico-légaux via ruf a une adoption limitée. De nombreux grands fournisseurs de boîtes aux lettres (Gmail, Yahoo) n'envoient pas de rapports médico-légaux en raison de préoccupations concernant la confidentialité. Ceux qui le font souvent masquent le corps du message et l'adresse du destinataire. Les rapports agrégés (rua) restent la source principale de commentaires DMARC.

Erreurs courantes

• S'attendre à des rapports médico-légaux de tous les récepteurs. La plupart des grands fournisseurs de boîtes aux lettres n'envoient pas de rapports AFRF. Ne comptez pas sur ruf comme seule source de données d'échec d'authentification. Les rapports agrégés DMARC (rua) sont beaucoup plus largement pris en charge.
• Confondre AFRF avec les rapports d'abus ARF. Les deux utilisent multipart/report avec report-type=feedback-report, mais ils ont des valeurs Feedback-Type différentes. Un rapport auth-failure signifie qu'une vérification d'authentification a échoué ; un rapport abuse signifie qu'un utilisateur a cliqué sur « Signaler le courrier indésirable ». Traitez-les différemment.
• Ignorer le champ Auth-Failure. Le champ Auth-Failure vous indique exactement quelle vérification a échoué. Un échec dkim suggère un problème de signature ; un échec spf suggère une IP manquante dans votre enregistrement SPF ; un échec dmarc signifie qu'aucun mécanisme n'était aligné.
• Ne pas publier d'adresse ruf. Bien que la plupart des récepteurs ne l'utiliseront pas, certains petits fournisseurs et passerelles d'entreprise envoient des rapports médico-légaux. L'inclusion de ruf dans votre enregistrement DMARC ne coûte rien et peut fournir des données utiles.
• Traiter les rapports médico-légaux comme des retours. Un rapport d'échec d'authentification ne signifie pas que le message n'a pas été livré. Vérifiez le champ Delivery-Result — le message peut avoir été livré dans le dossier spam malgré l'échec.

Impact sur la délivrabilité

• Détection précoce des campagnes d'usurpation. Lorsque quelqu'un hameçonne avec votre domaine, les rapports AFRF (le cas échéant) fournissent les en-têtes spécifiques et les adresses IP sources des messages falsifiés, permettant une réaction aux incidents plus rapide.
• Déboguer les erreurs de configuration d'authentification. Un rapport médico-légal montrant Auth-Failure: dkim avec un sélecteur et un domaine spécifiques vous indique exactement quelle clé DKIM ou configuration de signature est cassée.
• Déploiement DMARC sûr. Lors du passage de p=none à p=quarantine ou p=reject, les rapports médico-légaux vous aident à identifier les expéditeurs légitimes qui échouent l'authentification avant que ces messages ne commencent à être bloqués.
• Compléter les données agrégées. Les rapports DMARC agrégés vous montrent que 50 messages ont échoué l'authentification à partir de l'IP 192.0.2.55. Un rapport médico-légal vous montre les en-têtes réels d'un de ces messages, révélant s'il s'agissait d'un hameçonnage ou d'un système légitime mal configuré.

Related RFCs