# 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.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/authentification/en-tete-authentication-results

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](https://emailmarketing.net/fr/apprendre/authentification/spf), [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim), [DMARC](https://emailmarketing.net/fr/apprendre/authentification/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](https://emailmarketing.net/fr/apprendre/authentification/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](https://emailmarketing.net/fr/apprendre/authentification/arc)).

## Voir aussi

- [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf)
- [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim)
- [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc)
- [Rapports agrégés DMARC](https://emailmarketing.net/fr/apprendre/authentification/rapports-agreges-dmarc), les mêmes résultats rassemblés sur l'ensemble des serveurs de réception