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

La RFC 8601 définit l’en-tête Authentication-Results:, qu’un système de réception 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, …), afin que les filtres en aval et les MUA, ainsi que les humains qui diagnostiquent un problème, puissent les exploiter sans refaire les vérifications. Lire cet en-tête dans un message livré est le moyen le plus rapide de voir exactement comment un serveur de réception donné a jugé votre authentification.

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 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 par un point-virgule, rapporte le résultat d’une méthode, éventuellement accompagné d’un texte libre reason et d’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é 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 (domaine ou 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 (premiers octets de la signature, pour distinguer plusieurs signatures)
dmarc (enregistrée par la RFC 7489) pass, fail, none, temperror, permerror header.from (domaine RFC5322.From évalué) ; souvent des commentaires policy.dmarc indiquant le traitement appliqué
iprev pass, fail, temperror, permerror policy.iprev (l’IP du client dont le DNS inverse a été validé)
auth (SMTP AUTH) pass, fail, none, temperror, permerror smtp.auth (identité authentifiée), smtp.mailfrom
arc (enregistrée par la RFC 8617) none, pass, fail voir ARC

policy en tant que résultat signifie que la vérification a abouti mais que 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

Interprétation : le 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’IP 203.0.113.5 ; DMARC a réussi pour le domaine From: example.com (sa politique publiée est reject ; le traitement appliqué est none, c’est-à-dire que le message a été livré). DKIM est aligné (d= est égal au domaine From:) ; SPF réussit et bounce.example.com est en alignement souple avec example.com : les deux volets de DMARC ont réussi.

Confiance et règle de suppression

L’en-tête est très facile à falsifier pour un expéditeur ; son modèle de sécurité repose donc sur une hygiène stricte des frontières 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 portant leur propre authserv-id avant d’ajouter la leur, authentique.
  • Les consommateurs (filtres, MUA) ne devraient tenir compte que des en-têtes dont l’authserv-id appartient à leur propre ADMD ; tout le reste est une donnée étrangère non fiable.
  • Par conséquent, pour diagnostiquer un problème de délivrabilité, lisez 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 (sauts antérieurs) ou usurpés.

Relation avec les autres en-têtes

  • Received-SPF: est l’ancien en-tête de résultat propre à SPF, ajouté à chaque saut (RFC 7208) ; dans la pratique, Authentication-Results le remplace en tant que mécanisme unifié de rapport.
  • ARC-Authentication-Results: reprend exactement ce format de contenu pour prendre 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 →