emailmarketing.net
EnglishFrançais

L’en-tête Authentication-Results

Référence RFC 8601 : syntaxe de l’en-tête dans lequel les serveurs de réception consignent les résultats SPF/DKIM/DMARC/iprev, types de propriétés et propriétés, codes de résultat par méthode, et comment en lire un.

Référence4 min de lecture

À qui cela s’adresse Opérateurs ESP, Expéditeurs

S’applique aux expéditeurs, quelle que soit leur plateforme

SommaireSur cette page : 7 sections

Pour voir exactement comment un serveur de réception a jugé votre authentification, ouvrez un message qu’il a livré et lisez son en-tête Authentication-Results:. C’est le moyen le plus rapide de le savoir.

La RFC 8601 définit cet en-tête. Un système de réception l’ajoute en tête du message pour consigner le résultat des vérifications d’authentification qu’il a effectuées (SPF, DKIM, DMARC, iprev, SMTP AUTH et autres). Les filtres et les clients de messagerie (MUA) situés plus loin sur le parcours, ainsi que les personnes qui diagnostiquent un problème, peuvent ensuite exploiter ces résultats sans refaire les vérifications.

Syntaxe

Authentication-Results: <authserv-id> [version];
    <method>=<result> [reason="..."] [<ptype>.<property>=<value>] ... ;
    <method>=<result> ... ;
  • authserv-id identifie le système qui a effectué les vérifications, en général par un domaine DNS (par exemple mx.google.com). Il vous indique de qui vient le verdict que vous lisez.
  • Chaque clause resinfo, séparée des autres par des points-virgules, rapporte le résultat d’une méthode. Elle peut comprendre un texte libre reason et une ou plusieurs paires ptype.property=value qui identifient ce qui a été évalué.
  • Authentication-Results: example.com; none signifie que le serveur de réception n’a effectué aucune vérification.
  • Plusieurs méthodes peuvent figurer dans un même en-tête, ou le serveur de réception peut ajouter plusieurs en-têtes (un par méthode ou par saut).

Types de propriétés (ptypes)

ptype Valeurs tirées de
smtp Commandes du protocole SMTP (par exemple smtp.mailfrom, smtp.helo, smtp.auth)
header Champs d’en-tête du message ou parties de ceux-ci (par exemple header.d, header.i, header.b, header.from)
body Contenu du corps du message (aucune propriété n’est enregistrée à ce jour)
policy Informations de politique locale qui complètent ou remplacent les résultats bruts (par exemple policy.iprev)

Méthodes courantes et leurs codes de résultat

Méthode Codes de résultat Propriétés principales
spf pass, fail, softfail, neutral, none, policy, temperror, permerror smtp.mailfrom (le domaine ou l’adresse MAIL FROM complète vérifiée), smtp.helo
dkim pass, fail, none, neutral, policy, temperror, permerror header.d (domaine signataire), header.i (AUID), header.s (sélecteur), header.b (les premiers octets de la signature, pour distinguer plusieurs signatures)
dmarc (enregistrée par la RFC 7489) pass, fail, none, temperror, permerror header.from (le domaine RFC5322.From évalué), souvent avec des commentaires policy.dmarc qui indiquent le traitement appliqué
iprev pass, fail, temperror, permerror policy.iprev (l’adresse IP du client dont le DNS inverse a été validé)
auth (SMTP AUTH) pass, fail, none, temperror, permerror smtp.auth (l’identité authentifiée), smtp.mailfrom
arc (enregistrée par la RFC 8617) none, pass, fail Voir ARC

Lorsque policy apparaît comme résultat, la vérification a abouti, mais la politique locale a supprimé ou remplacé le résultat normal.

Lire un en-tête : exemple commenté

Authentication-Results: mx.google.com;
    dkim=pass header.i=@example.com header.s=s2048 header.b=Kx4pR2;
    spf=pass (google.com: domain of bounce.example.com designates 203.0.113.5
      as permitted sender) smtp.mailfrom=news@bounce.example.com;
    dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

Le serveur MX de Google a vérifié le message :

  • Une signature DKIM de example.com (sélecteur s2048) a été vérifiée.
  • SPF a réussi pour le domaine de rebond bounce.example.com depuis l’adresse IP 203.0.113.5.
  • DMARC a réussi pour le domaine From: example.com. Sa politique publiée est reject, et le traitement appliqué est none, ce qui signifie que le message a été livré.

DKIM est aligné, car d= est identique au domaine From:. SPF réussit, et bounce.example.com est aligné avec example.com en alignement souple. Les deux voies vers un pass DMARC ont réussi.

Confiance et règle de suppression

Un expéditeur peut facilement falsifier cet en-tête, donc sa sécurité repose sur un traitement rigoureux à la frontière de confiance :

  • Un MTA conforme à la RFC 8601 DOIT supprimer toute instance de l’en-tête qui prétend (par son authserv-id) avoir été ajoutée à l’intérieur de la frontière de confiance du serveur de réception, mais qui ne provient pas réellement d’un MTA interne de confiance. Les MTA de bordure suppriment ou renomment les instances entrantes qui portent leur propre authserv-id avant d’ajouter la leur, authentique.
  • Les filtres et les MUA ne devraient faire confiance qu’aux en-têtes dont l’authserv-id appartient à leur propre ADMD. Tout le reste est une donnée extérieure non fiable.
  • Pour diagnostiquer un problème de délivrabilité, lisez donc l’en-tête Authentication-Results le plus haut dont l’authserv-id correspond au fournisseur de réception final. Les en-têtes plus bas peuvent être périmés (issus de sauts antérieurs) ou falsifiés.

Relation avec les autres en-têtes

  • Received-SPF: est l’en-tête plus ancien, propre à SPF, qui consigne le résultat à chaque saut (RFC 7208). Dans la pratique, Authentication-Results l’a remplacé comme moyen unique de rapporter les résultats.
  • ARC-Authentication-Results: reprend exactement ce format pour consigner un instantané des résultats à chaque saut de transfert (voir ARC).

Voir aussi

Vérifier votre propre enregistrement

Le diagnostic gratuit lit ce que votre domaine publie dans le DNS.

Dans ce thème

Les 13 articles du thème Authentification →