Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Configuration des identités dans Amazon SES
Amazon Simple Email Service (Amazon SES) utilise le protocole SMTP (Simple Mail Transfer Protocol) pour envoyer des e-mails. Étant donné que le protocole SMTP ne fournit aucune authentification par lui-même, les expéditeurs de courrier indésirable peuvent envoyer des messages électroniques qui prétendent provenir d'une autre personne, tout en masquant leur origine réelle. En falsifiant les en-têtes d'e-mail et en usurpant les adresses IP source, les expéditeurs de courrier indésirable peuvent amener les destinataires des messages à croire que ces derniers sont authentiques.
La plupart des ISPs entreprises qui redirigent le trafic de courrier électronique prennent des mesures pour évaluer si le courrier électronique est légitime. L'une de ces ISPs mesures consiste à déterminer si un e-mail est *authentifié.* L'authentification nécessite que les expéditeurs confirment qu'ils sont bien propriétaires du compte depuis lequel ils envoient le message. Dans certains cas, ISPs refusez de transférer un e-mail qui n'est pas authentifié. Pour garantir une délivrabilité optimale, nous vous recommandons d'authentifier vos e-mails.
Les sections suivantes décrivent deux mécanismes d'authentification ISPs utilisés, le Sender Policy Framework (SPF) et le courrier DomainKeys identifié (DKIM), et fournissent des instructions sur l'utilisation de ces normes avec Amazon SES.
+ Pour en savoir plus sur le standard SPF, qui fournit une manière de tracer un message électronique jusqu'au système à partir duquel il a été envoyé, consultez [Authentification d'e-mails avec SPF dans Amazon SES](send-email-authentication-spf.md).
+ Pour en savoir plus sur DKIM, une norme qui vous permet de signer vos e-mails afin de montrer ISPs que vos messages sont légitimes et qu'ils n'ont pas été modifiés pendant le transport, consultez[Authentification d'e-mails avec DKIM dans Amazon SES](send-email-authentication-dkim.md).
+ Pour savoir comment vous conformer à la spécification DMARC (Domain-based Message Authentication, Reporting and Conformance), qui repose sur les normes SPF et DKIM, consultez [Mise en conformité au protocole d'authentification DMARC dans Amazon SES](send-email-authentication-dmarc.md).
# Méthodes d'authentification d'e-mail
Amazon Simple Email Service (Amazon SES) utilise le protocole SMTP (Simple Mail Transfer Protocol) pour envoyer des e-mails. Étant donné que le protocole SMTP ne fournit aucune authentification par lui-même, les expéditeurs de courrier indésirable peuvent envoyer des messages électroniques qui prétendent provenir d'une autre personne, tout en masquant leur origine réelle. En falsifiant les en-têtes d'e-mail et en usurpant les adresses IP source, les expéditeurs de courrier indésirable peuvent amener les destinataires des messages à croire que ces derniers sont authentiques.
La plupart des ISPs entreprises qui redirigent le trafic de courrier électronique prennent des mesures pour évaluer si le courrier électronique est légitime. L'une de ces ISPs mesures consiste à déterminer si un e-mail est authentifié. L'authentification nécessite que les expéditeurs confirment qu'ils sont bien propriétaires du compte depuis lequel ils envoient le message. Dans certains cas, ISPs refusez de transférer un e-mail qui n'est pas authentifié. Pour garantir une délivrabilité optimale, nous vous recommandons d'authentifier vos e-mails.
**Topics**
+ [Authentification d'e-mails avec DKIM dans Amazon SES](send-email-authentication-dkim.md)
+ [Authentification d'e-mails avec SPF dans Amazon SES](send-email-authentication-spf.md)
+ [Utilisation d'un domaine MAIL FROM personnalisé](mail-from.md)
+ [Mise en conformité au protocole d'authentification DMARC dans Amazon SES](send-email-authentication-dmarc.md)
+ [Utilisation de BIMI dans Amazon SES](send-email-authentication-bimi.md)
# Authentification d'e-mails avec DKIM dans Amazon SES
DomainKeys Le *courrier identifié* (*DKIM*) est une norme de sécurité du courrier électronique conçue pour garantir qu'un e-mail prétendant provenir d'un domaine spécifique a bien été autorisé par le propriétaire de ce domaine. Elle utilise le chiffrement de clé publique pour signer un e-mail avec une clé privée. Les serveurs de destinataires peuvent ensuite utiliser une clé publique publiée dans le DNS d'un domaine pour vérifier que certaines parties de l'e-mail n'ont pas été modifiées pendant le transit.
Les signatures DKIM sont facultatives. Vous pouvez décider de signer vos e-mails à l'aide d'une signature DKIM pour améliorer la délivrabilité avec les fournisseurs de messagerie compatibles avec le standard DKIM. Amazon SES propose trois options pour signer vos messages à l'aide d'une signature DKIM :
+ **Easy DKIM** : SES génère une paire de clés public/privé et ajoute automatiquement une signature DKIM à chaque message que vous envoyez à partir de cette identité, consultez [Easy DKIM dans Amazon SES](send-email-authentication-dkim-easy.md).
+ **Deterministic Easy DKIM (DEED)** : vous permet de maintenir une signature DKIM cohérente sur plusieurs Régions AWS en créant des répliques d'identités qui héritent automatiquement des attributs de signature DKIM en tant qu'identité parent utilisant Easy DKIM, voir. [Utilisation de Deterministic Easy DKIM (DEED) dans Amazon SES](send-email-authentication-dkim-deed.md)
+ **BYODKIM (Bring Your Own DKIM)** : vous fournissez votre propre paire de clés public/privé et SES ajoute une signature DKIM à chaque message que vous envoyez à partir de cette identité, consultez [Fournissez votre propre jeton d'authentification DKIM (BYODKIM) dans Amazon SES](send-email-authentication-dkim-bring-your-own.md).
+ **Ajouter manuellement la signature DKIM** : vous ajoutez votre propre signature DKIM à tous les e-mails que vous envoyez à l'aide de l'API `SendRawEmail`, consultez [Signature DKIM manuelle dans Amazon SES](send-email-authentication-dkim-manual.md).
## Longueur de la clé DKIM
Puisque de nombreux fournisseurs de DNS prennent désormais en charge le cryptage RSA 2048 bits de DKIM, Amazon SES prend également en charge DKIM 2048 pour permettre une authentification plus sûre des e-mails et l'utilise donc en tant que longueur de clé par défaut lorsque vous configurez Easy DKIM à partir de l'API ou de la console. Les clés de 2048 bits peuvent être configurées et utilisées dans Bring Your Own DKIM (BYODKIM) également, où la longueur de votre clé de signature doit être au moins de 1024 bits et pas plus de 2048 bits.
Pour des raisons de sécurité et de délivrabilité de votre e-mail, lorsque vous configurez Easy DKIM, vous avez le choix d'utiliser des longueurs de clé de 1024 ou 2048 bits, avec la possibilité de revenir à 1024 en cas de problèmes liés à des fournisseurs DNS qui ne prennent pas encore en charge 2048. *Lorsque vous créez une nouvelle identité, elle est créée avec DKIM 2048 par défaut, sauf si vous spécifiez 1024.*
Pour préserver la délivrabilité des e-mails en transit, il existe des restrictions quant à la fréquence à laquelle vous pouvez modifier la longueur de la clé DKIM. Les restrictions sont les suivantes :
+ Impossibilité de passer à la même longueur de clé que celle déjà configurée.
+ Impossibilité de passer à une longueur de clé différente plus d'une fois au cours d'une période de 24 heures (sauf s'il s'agit de la première rétrogradation à 1024 de cette période).
Lorsque votre e-mail est en transit, DNS utilise votre clé publique pour l'authentifier. Par conséquent, si vous changez de clé trop rapidement ou trop fréquemment, DNS peut ne pas être en mesure d'authentifier votre e-mail par DKIM, car l'ancienne clé peut déjà avoir été annulée.
## Considérations relatives à DKIM
Lorsque vous utilisez DKIM pour authentifier vos e-mails, les règles suivantes s'appliquent :
+ Vous devez uniquement configurer DKIM pour le domaine que vous utilisez dans votre adresse « From ». Vous n'avez pas besoin de configurer DKIM pour les domaines que vous utilisez dans les adresses « Return-Path » (Chemin de retour) ou « Reply-to » (Répondre à).
+ Amazon SES est disponible dans plusieurs AWS régions. Si vous utilisez plusieurs Régions AWS pour envoyer des e-mails, vous devez exécuter le processus de configuration de DKIM dans chacune de ces Régions pour vous assurer que tous vos e-mails sont signés par DKIM.
+ Étant donné que les propriétés DKIM sont héritées du domaine parent, lorsque vous vérifiez un domaine avec l'authentification DKIM :
+ L'authentification DKIM s'appliquera également à tous les sous-domaines de ce domaine.
+ Les paramètres DKIM d'un sous-domaine peuvent remplacer ceux du domaine parent via la désactivation de l'héritage, si vous ne souhaitez pas que le sous-domaine utilise l'authentification DKIM. Vous avez la possibilité de le réactiver ultérieurement.
+ L'authentification DKIM s'appliquera également à tous les e-mails envoyés à partir d'une identité e-mail faisant référence au domaine vérifié DKIM dans son adresse.
+ Les paramètres DKIM d'une adresse e-mail peuvent remplacer ceux du sous-domaine (le cas échéant) et du domaine parent via la désactivation de l'héritage, si vous souhaitez envoyer des e-mails sans authentification DKIM. Vous avez la possibilité de le réactiver ultérieurement.
## Comprendre les propriétés de signature DKIM héritées
Il est important de comprendre d'abord qu'une identité d'adresse e-mail hérite de ses propriétés de signature DKIM de son domaine parent si ce domaine a été configuré avec DKIM, indépendamment du fait que Easy DKIM ou BYODKIM ait été utilisé. Par conséquent, la désactivation ou l'activation de la signature DKIM sur l'identité de l'adresse e-mail remplace les propriétés de signature DKIM du domaine sur la base de ces éléments clés :
+ Si vous avez déjà configuré DKIM pour le domaine auquel appartient une adresse e-mail, vous n'avez pas besoin d'activer la signature DKIM pour l'identité de l'adresse e-mail également.
+ Lorsque vous configurez DKIM pour un domaine, Amazon SES authentifie automatiquement chaque e-mail provenant de chaque adresse de ce domaine grâce aux propriétés DKIM héritées du domaine parent.
+ Les paramètres DKIM pour une identité d'adresse e-mail spécifique *remplacent automatiquement les paramètres du domaine ou du sous-domaine parent (le cas échéant)* auquel l'adresse appartient.
Étant donné que les propriétés de signature DKIM de l'identité d'adresse e-mail sont héritées du domaine parent, si vous envisagez de remplacer ces propriétés, vous devez garder à l'esprit les règles hiérarchiques de remplacement, comme expliqué dans le tableau ci-dessous.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/ses/latest/dg/send-email-authentication-dkim.html)
Il n'est généralement pas recommandé de désactiver la signature DKIM, car cela risque de ternir la réputation de l'expéditeur et d'augmenter le risque de voir les e-mails que vous envoyez aboutir dans les dossiers de courrier indésirable ou de spam, ou de voir votre domaine usurpé.
Toutefois, il existe la possibilité de remplacer les propriétés de signature DKIM héritées du domaine sur une identité d'adresse e-mail pour tout cas d'utilisation particulier ou décision commerciale externe pour lesquels vous pourriez avoir à désactiver la signature DKIM de façon permanente ou temporaire, ou à la réactiver ultérieurement. Consultez [Remplacement de la signature DKIM héritée sur une identité d'adresse e-mail](send-email-authentication-dkim-easy-managing.md#send-email-authentication-dkim-easy-setup-email).
# Easy DKIM dans Amazon SES
Lorsque vous configurez la fonction Easy DKIM pour une identité de domaine, Amazon SES ajoute automatiquement une clé DKIM 2 048 bits à chaque e-mail que vous envoyez à partir de cette identité. Vous pouvez configurer Easy DKIM à l'aide de la console Amazon SES ou de l'API.
**Note**
Pour configurer Easy DKIM, vous devez modifier les paramètres DNS de votre domaine. Si vous utilisez Route 53 comme votre fournisseur DNS, Amazon SES peut créer automatiquement les registres appropriés pour vous. Si vous utilisez un autre fournisseur DNS, consultez la documentation de ce dernier pour en savoir plus sur la modification des paramètres DNS pour votre domaine.
**Avertissement**
Si BYODKIM est actuellement activé et que vous passez à Easy DKIM, sachez qu'Amazon SES n'utilisera pas BYODKIM pour signer vos e-mails pendant la configuration d'Easy DKIM et que votre statut DKIM est en attente. Entre le moment où vous passez l'appel pour activer Easy DKIM (via l'API ou la console) et le moment où SES peut confirmer votre configuration DNS, vos e-mails peuvent être envoyés par SES sans signature DKIM. Par conséquent, il est conseillé d'utiliser une étape intermédiaire pour migrer d'une méthode de signature DKIM à l'autre (par exemple, en utilisant un sous-domaine de votre domaine avec BYODKIM activé, puis en le supprimant une fois la vérification Easy DKIM passée), ou d'effectuer cette activité pendant les temps d'arrêt de votre application, le cas échéant.
## Configuration de Easy DKIM pour une identité de domaine vérifiée
La procédure de cette section est simplifiée afin de présenter uniquement les étapes nécessaires pour configurer Easy DKIM sur une identité de domaine que vous avez déjà créée. Si vous n’avez pas encore créé d’identité de domaine ou si vous souhaitez voir toutes les options disponibles pour personnaliser une identité de domaine, telles que l'utilisation d'un jeu de configuration par défaut, d'un domaine MAIL FROM personnalisé et d'étiquettes, veuillez consulter [Création d'une identité de domaine](creating-identities.md#verify-domain-procedure).
Une partie de la création d'une identité de domaine Easy DKIM consiste à configurer sa vérification basée sur DKIM. Vous aurez donc le choix d'accepter la valeur par défaut Amazon SES de 2 048 bits, ou de la remplacer en sélectionnant 1 024 bits. Voir [Longueur de la clé DKIM](send-email-authentication-dkim.md#send-email-authentication-dkim-1024-2048) pour en savoir plus sur les longueurs de clés de signature DKIM et sur la façon de les modifier.
**Pour configurer Easy DKIM pour un domaine**
1. Connectez-vous à la console Amazon SES AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Dans le volet de navigation, sous **Configuration**, choisissez **Identities**.
1. Dans la liste des identités, choisissez une identité dans laquelle le **type d'identité** est le *Domaine*.
**Note**
Si vous devez créer ou vérifier un domaine, veuillez consulter [Création d'une identité de domaine](creating-identities.md#verify-domain-procedure).
1. Sous l'onglet **Authentification**, dans le conteneur **DomainKeysIdentified Mail (DKIM)**, choisissez **Modifier**.
1. Dans le conteneur **Advanced DKIM settings (Paramètres avancés de DKIM)**, choisissez le bouton **Easy DKIM** dans la zone**Identity type (Type d'identité)**.
1. Dans **DKIM signing key length (Longueur de clé de signature DKIM)**, choisissez [**RSA\$12048\$1BIT** ou **RSA\$11024\$1BIT**](send-email-authentication-dkim.md#send-email-authentication-dkim-1024-2048).
1. Dans **DKIM signatures (Signatures DKIM)**, cochez la case **Enabled (Activé)**.
1. Sélectionnez **Enregistrer les modifications**.
1. Maintenant que vous avez configuré votre identité de domaine avec Easy DKIM, vous devez terminer le processus de vérification avec votre fournisseur DNS. Passez à [Vérification d’une identité de domaine DKIM auprès de votre fournisseur DNS](creating-identities.md#just-verify-domain-proc) et suivez les procédures d'authentification DNS pour Easy DKIM.
## Modifier la longueur de la clé de signature Easy DKIM pour une identité
La procédure décrite dans cette section montre comment vous pouvez facilement modifier les bits Easy DKIM requis pour l'algorithme de signature. Bien qu'une longueur de signature de 2048 bits soit préférable pour le niveau de sécurité qu'elle procure, certaines situations peuvent vous obliger à utiliser la longueur de 1024 bits, par exemple si vous devez utiliser un fournisseur DNS qui ne prend en charge que DKIM 1024.
Pour préserver la délivrabilité des e-mails en transit, il existe des restrictions quant à la fréquence à laquelle vous pouvez modifier ou changer la longueur de votre clé DKIM.
Lorsque votre e-mail est en transit, DNS utilise votre clé publique pour l'authentifier. Par conséquent, si vous changez de clé trop rapidement ou trop fréquemment, DNS peut ne pas être en mesure d'authentifier votre e-mail par DKIM, car l'ancienne clé peut déjà avoir été annulée. Donc, les restrictions suivantes permettent d'éviter cela :
+ Vous ne pouvez pas passer à la même longueur de clé que celle qui est déjà configurée.
+ Vous ne pouvez pas passer à une longueur de clé différente plus d'une fois au cours d'une période de 24 heures (sauf s'il s'agit de la première rétrogradation à 1024 de cette période).
Lorsque vous utilisez les procédures suivantes pour modifier la longueur de votre clé, si vous dérogez à l'une de ces restrictions, la console renverra une bannière d'erreur indiquant que *l'entrée que vous avez fournie n'est pas valide*, ainsi que la raison pour laquelle elle ne l'est pas.
**Pour modifier les bits de longueur de clé de signature DKIM**
1. Connectez-vous à la console Amazon SES AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Dans le panneau de navigation, sous **Configuration**, choisissez **Verified identities (Identités vérifiées)**.
1. Dans la liste des identités, choisissez celle pour laquelle vous souhaitez modifier la longueur de la clé de signature DKIM.
1. Sous l'onglet **Authentification**, dans le conteneur **DomainKeysIdentified Mail (DKIM)**, choisissez **Modifier**.
1. Dans le conteneur **Advanced DKIM settings** (Paramètres avancés de DKIM), choisissez [**RSA\$12048\$1BIT** ou **RSA\$11024\$1BIT**](send-email-authentication-dkim.md#send-email-authentication-dkim-1024-2048) dans le champ **DKIM signing key length** (Longueur de la clé DKIM).
1. Sélectionnez **Enregistrer les modifications**.
# Utilisation de Deterministic Easy DKIM (DEED) dans Amazon SES
Deterministic Easy DKIM (DEED) propose une solution pour gérer les configurations DKIM sur plusieurs. Régions AWS En simplifiant la gestion du DNS et en garantissant une signature DKIM cohérente, DEED vous aide à rationaliser vos opérations d'envoi d'e-mails dans plusieurs régions tout en maintenant de solides pratiques d'authentification des e-mails.
## Qu'est-ce que Deterministic Easy DKIM (DEED) ?
[Deterministic Easy DKIM (DEED) est une fonctionnalité qui génère des jetons DKIM cohérents dans tous les domaines sur la Régions AWS base d'un domaine parent configuré avec Easy DKIM.](send-email-authentication-dkim-easy.md) Cela vous permet de répliquer des identités différentes Régions AWS qui héritent et conservent automatiquement la même configuration de signature DKIM qu'une identité parent actuellement configurée avec Easy DKIM. Avec DEED, vous ne devez publier les enregistrements DNS qu'une seule fois pour l'identité du parent, et les identités répliquées utiliseront les mêmes enregistrements DNS pour vérifier la propriété du domaine et gérer la signature DKIM.
En simplifiant la gestion du DNS et en garantissant une signature DKIM cohérente, DEED vous aide à rationaliser vos opérations d'envoi d'e-mails dans plusieurs régions tout en respectant les meilleures pratiques d'authentification des e-mails.
Terminologie utilisée pour parler de DEED :
+ **Identité parent** : identité vérifiée configurée avec Easy DKIM qui sert de source pour la configuration DKIM d'une réplique d'identité.
+ **Identité répliquée** : copie d'une identité parent qui partage la même configuration DNS et la même configuration de signature DKIM.
+ **Région parent** — L' Région AWS endroit où l'identité d'un parent est configurée.
+ **Région de réplication : zone** Région AWS dans laquelle une identité de réplique est configurée.
+ **Identité DEED** — Toute identité utilisée soit comme identité parent, soit comme identité de réplique. (Lorsqu'une nouvelle identité est créée, elle est initialement traitée comme une identité normale (autre que DEED). Cependant, une fois qu'une réplique est créée, l'identité est alors considérée comme une identité DEED.)
Les principaux avantages de l'utilisation de DEED sont les suivants :
+ **Gestion DNS simplifiée** : publiez les enregistrements DNS une seule fois pour l'identité du parent.
+ **Simplification des opérations multirégionales** — Simplifiez le processus d'extension des opérations d'envoi d'e-mails à de nouvelles régions.
+ **Réduction des frais administratifs :** gérez les configurations DKIM de manière centralisée à partir de l'identité du parent.
## Comment fonctionne Deterministic Easy DKIM (DEED)
Lorsque vous créez une identité de réplique, Amazon SES réplique automatiquement la clé de signature DKIM de l'identité parent vers l'identité de réplique. Toutes les rotations de touches DKIM ou les modifications de longueur de clé ultérieures apportées à l'identité parent sont automatiquement propagées à toutes les identités répliquées.
Le processus implique le flux de travail suivant :
1. Créez une identité de parent dans un Easy DKIM à Région AWS l'aide de Easy DKIM.
1. Configurez les enregistrements DNS requis pour l'identité du parent.
1. Créez des répliques d'identités dans d'autres Régions AWS, en spécifiant le nom de domaine et la région de signature DKIM de l'identité parent.
1. Amazon SES réplique automatiquement la configuration DKIM du parent sur les identités de réplication.
Considérations importantes :
+ Vous ne pouvez pas créer une réplique d'une identité qui est déjà une réplique.
+ [Easy DKIM doit être activé sur l'identité parent. Vous ne pouvez pas créer de répliques de BYODKIM](send-email-authentication-dkim-easy.md) ou d'identités signées manuellement.
+ Les identités parentes ne peuvent pas être supprimées tant que toutes les identités répliquées ne sont pas supprimées.
## Configuration d'une identité dupliquée à l'aide de DEED
Cette section fournit des exemples vous montrant comment créer et vérifier une réplique d'identité à l'aide de DEED, ainsi que les autorisations nécessaires requises.
**Topics**
+ [Création d'une identité répliquée](#creating-replica-identity)
+ [Vérifier la configuration de l'identité des répliques](#verifying-replica-identity)
+ [Autorisations requises pour utiliser DEED](#required-permissions)
### Création d'une identité répliquée
Pour créer une identité de réplique :
1. Dans l' Région AWS endroit où vous souhaitez créer une réplique d'identité, ouvrez la console SES à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
(Dans la console SES, les identités répliquées sont appelées *identités globales*.)
1. Dans le volet de navigation, sélectionnez **Identities**.
1. Choisissez **Create identity (Créer une identité)**.
1. Sélectionnez **Domaine** sous **Type d'identité** et entrez le nom de domaine d'une identité existante configurée avec Easy DKIM que vous souhaitez répliquer et servir de parent.
1. Développez **les paramètres DKIM avancés** et sélectionnez **Deterministic** Easy DKIM.
1. Dans le menu déroulant **Région parent**, sélectionnez une région parent dans laquelle réside une identité signée Easy DKIM portant le même nom que celui que vous avez saisi pour votre identité globale (réplique). (La région de votre réplique correspond par défaut à la région avec laquelle vous vous êtes connecté à la console SES.)
1. Assurez-vous que les **signatures DKIM** sont activées.
1. (Facultatif) Ajoutez une ou plusieurs **balises** à l'identité de votre domaine.
1. Passez en revue la configuration et choisissez **Create identity**.
En utilisant AWS CLI :
Pour créer une identité de réplique basée sur une identité parent configurée avec Easy DKIM, vous devez spécifier le nom de domaine du parent, la région dans laquelle vous souhaitez créer l'identité de réplique et la région de signature DKIM du parent, comme indiqué dans cet exemple :
```
aws sesv2 create-email-identity --email-identity example.com --region us-west-2 --dkim-signing-attributes '{"DomainSigningAttributesOrigin": "AWS_SES_US_EAST_1"}'
```
Dans l'exemple précédent :
1. Remplacez *example.com* par l'identité du domaine parent en cours de réplication.
1. Remplacez *us-west-2* par la région dans laquelle l'identité de domaine répliquée sera créée.
1. Remplacez *AWS\$1SES\$1US\$1EAST\$11* par la région de signature DKIM du parent qui représente sa configuration de signature Easy DKIM qui sera répliquée sur l'identité de réplique.
**Note**
Le `AWS_SES_` préfixe indique que DKIM a été configuré pour l'identité parent à l'aide d'Easy DKIM et que `US_EAST_1` c'est Région AWS là qu'il a été créé.
### Vérifier la configuration de l'identité des répliques
Après avoir créé la réplique d'identité, vous pouvez vérifier qu'elle a été correctement configurée avec la configuration de signature DKIM de l'identité parent.
**Pour vérifier l'identité d'une réplique :**
1. Dans l' Région AWS endroit où vous avez créé la réplique d'identité, ouvrez la console SES à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Dans le volet de navigation, choisissez **Identities** et sélectionnez l'identité que vous souhaitez vérifier dans le tableau **Identités**.
1. Sous l'onglet **Authentification**, le champ de **configuration DKIM** indiquera le statut, et le champ **Région parent** indiquera la région utilisée pour la configuration de signature DKIM de l'identité à l'aide de DEED.
En utilisant AWS CLI :
Utilisez la `get-email-identity` commande spécifiant le nom de domaine et la région de la réplique :
```
aws sesv2 get-email-identity --email-identity example.com --region us-west-2
```
La réponse inclura la valeur de la région parent dans le `SigningAttributesOrigin` paramètre indiquant que l'identité de réplique a été correctement configurée avec la configuration de signature DKIM de l'identité parent :
```
{
"DkimAttributes": {
"SigningAttributesOrigin": "AWS_SES_US_EAST_1"
}
}
```
### Autorisations requises pour utiliser DEED
Pour utiliser DEED, vous devez :
1. Autorisations standard pour créer des identités e-mail dans la région de réplication.
1. Autorisation de répliquer la clé de signature DKIM depuis la région parent.
#### Exemple de stratégie IAM pour la réplication DKIM
La politique suivante autorise la réplication des clés de signature DKIM depuis une identité parent vers des régions de réplication spécifiées :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowDKIMReplication",
"Effect": "Allow",
"Action": "ses:ReplicateEmailIdentityDKIMSigningKey",
"Resource": "arn:aws:ses:us-east-1:123456789124:identity/example.com",
"Condition": {
"ForAllValues:StringEquals": {
"ses:ReplicaRegion": ["us-east-1", "us-east-1"]
}
}
}
]
}
```
------
## Bonnes pratiques
Les meilleures pratiques suivantes sont recommandées :
+ **Planifiez vos régions parent et de réplique** : prenez en compte la région parent que vous choisissez, car elle sera la source fiable de la configuration DKIM utilisée dans les régions de réplication.
+ **Utilisez des politiques IAM cohérentes** : assurez-vous que vos politiques IAM autorisent la réplication DKIM dans toutes les régions prévues.
+ **Maintenir les identités parentes actives** : n'oubliez pas que vos identités de réplique héritent de la configuration de signature DKIM de l'identité parent. En raison de cette dépendance, vous ne pouvez pas supprimer d'identité parent tant que toutes les identités de réplique ne sont pas supprimées.
## Résolution des problèmes
Si vous rencontrez des problèmes avec DEED, prenez en compte les points suivants :
+ **Erreurs de vérification** : assurez-vous que vous disposez des autorisations nécessaires pour la réplication DKIM.
+ **Retards de réplication** — Prévoyez un certain temps pour que la réplication soit terminée, en particulier lors de la création de nouvelles identités de réplication.
+ **Problèmes liés au DNS** — Vérifiez que les enregistrements DNS de l'identité du parent sont correctement configurés et propagés.
# Fournissez votre propre jeton d'authentification DKIM (BYODKIM) dans Amazon SES
Comme alternative à l'utilisation d'[Easy DKIM](send-email-authentication-dkim-easy.md), vous pouvez configurer l'authentification DKIM en utilisant votre propre paire de clés publique-privée. Ce processus est connu sous le nom de *Bring Your Own DKIM (Fournissez votre propre DKIM)* (*BYODKIM*).
Avec BYODKIM, vous pouvez utiliser un registre DNS unique pour configurer l'authentification DKIM pour vos domaines, contrairement à Easy DKIM qui vous oblige à publier trois registres DNS distincts. En outre, avec BYODKIM, vous pouvez procéder à une rotation des clés DKIM de vos domaines aussi souvent que vous le souhaitez.
**Topics**
+ [Étape 1 : Créer la paire de clés](#send-email-authentication-dkim-bring-your-own-create-key-pair)
+ [Étape 2 : Ajouter la clé publique et le sélecteur à la configuration de domaine de votre fournisseur DNS](#send-email-authentication-dkim-bring-your-own-update-dns)
+ [Étape 3 : Configurer et vérifier un domaine pour utiliser BYODKIM](#send-email-authentication-dkim-bring-your-own-configure-identity)
**Avertissement**
Si Easy DKIM est actuellement activé et que vous passez à BYODKIM, sachez qu'Amazon SES n'utilisera pas Easy DKIM pour signer vos e-mails pendant la configuration de BYODKIM et que votre statut DKIM est en attente. Entre le moment où vous passez l'appel pour activer BYODKIM (via l'API ou la console) et le moment où SES peut confirmer votre configuration DNS, vos e-mails peuvent être envoyés par SES sans signature DKIM. Par conséquent, il est conseillé d'utiliser une étape intermédiaire pour migrer d'une méthode de signature DKIM à l'autre (par exemple, utiliser un sous-domaine de votre domaine avec Easy DKIM activé, puis la supprimer une fois la vérification BYODKIM passée), ou effectuer cette activité pendant les temps d'arrêt de votre application, le cas échéant.
## Étape 1 : Créer la paire de clés
Pour utiliser la fonction Bring Your Own DKIM (Fournissez votre propre DKIM), vous devez d'abord créer une paire de clés RSA.
La clé privée que vous générez doit être au format PKCS \$11 ou PKCS \$18, utiliser un chiffrement RSA d'au moins1024 bits et jusqu'à 2048 bits, et être encodée à l'aide du codage [(PEM)](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) base64. Voir [Longueur de la clé DKIM](send-email-authentication-dkim.md#send-email-authentication-dkim-1024-2048) pour en savoir plus sur les longueurs des clés de signature DKIM et sur la manière de les modifier.
**Note**
Vous pouvez utiliser des applications et des outils tiers pour générer des paires de clés RSA tant que la clé privée est générée avec un chiffrement RSA d'au moins 1 024 bits et jusqu'à 2 048 bits, et qu'elle est encodée à l’aide du codage [(PEM)](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) base64.
Dans la procédure suivante, l'exemple de code qui utilise la commande `openssl genrsa` intégrée à la plupart des systèmes d'exploitation Linux, macOS ou Unix pour créer la paire de clés utilisera automatiquement le codage [(PEM)](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) base64.
**Pour créer la paire de clés à partir de la ligne de commande Linux, macOS ou Unix**
1. Sur la ligne de commande, entrez la commande suivante pour générer la clé privée en la *nnnn* remplaçant par une longueur de bits d'au moins 1024 et jusqu'à 2048 :
```
openssl genrsa -f4 -out private.key nnnn
```
1. À partir de la ligne de commande, entrez la commande suivante pour générer la clé publique :
```
openssl rsa -in private.key -outform PEM -pubout -out public.key
```
## Étape 2 : Ajouter la clé publique et le sélecteur à la configuration de domaine de votre fournisseur DNS
Maintenant que vous avez créé une paire de clés, vous devez ajouter la clé publique à la configuration DNS pour votre domaine en tant qu'registre TXT.
**Pour ajouter la clé publique à la configuration DNS pour votre domaine**
1. Connectez-vous à la console de gestion de votre fournisseur DNS ou d'hébergement.
1. Ajoutez un nouvel registre texte à la configuration DNS pour votre domaine le registre doit utiliser le format suivant :
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/ses/latest/dg/send-email-authentication-dkim-bring-your-own.html)
Dans l’exemple précédent, apportez les modifications suivantes :
+ *selector*Remplacez-le par un nom unique identifiant la clé.
**Note**
Un petit nombre de fournisseurs DNS n'autorisent pas l'inclusion de traits de soulignement (\$1) dans les noms de registre. Cependant, les traits de soulignement dans les noms de registres DKIM sont obligatoires. Si votre fournisseur DNS ne vous permet pas de saisir un caractère de soulignement dans le nom de registre, contactez l'équipe de support client du fournisseur pour obtenir de l'aide.
+ Remplacez *example.com* par votre domaine.
+ *yourPublicKey*Remplacez-le par la clé publique que vous avez créée précédemment et incluez le `p=` préfixe comme indiqué dans la colonne *Valeur* ci-dessus.
**Note**
Lorsque vous publiez (ajoutez) votre clé publique à votre fournisseur DNS, elle doit être formatée comme suit :
Vous devez supprimer les première et dernière lignes (respectivement `-----BEGIN PUBLIC KEY-----` et `-----END PUBLIC KEY-----`) de la clé publique générée. En outre, vous devez supprimer les sauts de ligne dans la clé publique générée. La valeur résultante est une chaîne de caractères sans espace ni saut de ligne.
Vous devez inclure le préfixe `p=` comme indiqué dans la colonne *Value* (Valeur) dans le tableau ci-dessus.
Les différents fournisseurs ont des procédures différentes pour mettre à jour les registres DNS. Le tableau suivant comprend des liens vers de la documentation relative à quelques fournisseurs DNS courants. Cette liste n'est pas exhaustive et n’a pas valeur d’approbation. De même, si votre fournisseur DNS n'est pas répertorié, cela ne signifie pas que vous ne pouvez pas utiliser le domaine avec Amazon SES.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/ses/latest/dg/send-email-authentication-dkim-bring-your-own.html)
## Étape 3 : Configurer et vérifier un domaine pour utiliser BYODKIM
Vous pouvez configurer BYODKIM pour les nouveaux domaines (c'est-à-dire, les domaines que vous n'utilisez pas actuellement pour envoyer des e-mails via Amazon SES) et les domaines existants (c'est-à-dire, les domaines que vous avez déjà configurés pour utiliser avec Amazon SES) en utilisant la console ou AWS CLI. Avant d'utiliser les AWS CLI procédures décrites dans cette section, vous devez d'abord installer et configurer le AWS CLI. Pour plus d'informations, consultez le [guide de AWS Command Line Interface l'utilisateur](https://docs.aws.amazon.com/cli/latest/userguide/).
### Option 1 : Création d'une nouvelle identité de domaine utilisant BYODKIM
Cette section contient les procédures de création d'une identité de domaine utilisant BYODKIM. Une nouvelle identité de domaine est un domaine que vous n'avez pas précédemment configuré pour envoyer des e-mails via Amazon SES.
Si vous souhaitez configurer un domaine existant pour utiliser BYODKIM, effectuez plutôt la procédure décrite dans [Option 2 : Configuration d'une identité de domaine existante](#send-email-authentication-dkim-bring-your-own-configure-identity-existing-domain).
**Pour créer une identité à l'aide de BYODKIM depuis la console**
+ Suivez la procédure dans [Création d'une identité de domaine](creating-identities.md#verify-domain-procedure) et, lorsque vous arrivez à l'étape 8, suivez les instructions spécifiques à BYODKIM.
**Pour créer une identité à l'aide de BYODKIM à partir du AWS CLI**
Pour configurer un nouveau domaine, utilisez l'opération `CreateEmailIdentity` dans l'API Amazon SES.
1. Dans un éditeur de texte, collez le code suivant :
```
{
"EmailIdentity":"example.com",
"DkimSigningAttributes":{
"DomainSigningPrivateKey":"privateKey",
"DomainSigningSelector":"selector"
}
}
```
Dans l’exemple précédent, apportez les modifications suivantes :
+ *example.com*Remplacez-le par le domaine que vous souhaitez créer.
+ *privateKey*Remplacez-le par votre clé privée.
**Note**
Vous devez supprimer les première et dernière lignes (respectivement `-----BEGIN PRIVATE KEY-----` et `-----END PRIVATE KEY-----`) de la clé privée générée. En outre, vous devez supprimer les sauts de ligne dans la clé privée générée. La valeur résultante est une chaîne de caractères sans espace ni saut de ligne.
+ *selector*Remplacez-le par le sélecteur unique que vous avez spécifié lors de la création de l'enregistrement TXT dans la configuration DNS de votre domaine.
Lorsque vous avez terminé, enregistrez le fichier sous `create-identity.json`.
1. Sur la ligne de commande, entrez la commande suivante :
```
aws sesv2 create-email-identity --cli-input-json file://path/to/create-identity.json
```
Dans la commande précédente, remplacez *path/to/create-identity.json* par le chemin complet du fichier que vous avez créé à l'étape précédente.
### Option 2 : Configuration d'une identité de domaine existante
Cette section contient les procédures de mise à jour d'une identité de domaine existante pour utiliser BYODKIM. Une identité de domaine existante est un domaine que vous avez déjà configuré pour envoyer des e-mails via Amazon SES.
**Pour mettre à jour une identité de domaine en utilisant BYODKIM depuis la console**
1. Connectez-vous à la console Amazon SES AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Dans le panneau de navigation, sous **Configuration**, choisissez **Verified identities (Identités vérifiées)**.
1. Dans la liste des identités, choisissez une identité dans laquelle le **type d'identité** est le *Domaine*.
**Note**
Si vous devez créer ou vérifier un domaine, veuillez consulter [Création d'une identité de domaine](creating-identities.md#verify-domain-procedure).
1. Sous l'onglet **Authentification**, dans le volet **DomainKeys Identified Mail (DKIM)**, choisissez **Modifier**.
1. Dans le volet **Advanced DKIM settings (Paramètres avancés de DKIM)**, choisissez **Provide DKIM authentication token (BYODKIM) [Fournir un jeton d'authentification DKIM (BYODKIM)]** dans la zone **Identity type (Type d'identité)**.
1. Pour **Private key (Clé privée)**, collez la clé privée que vous avez générée précédemment.
**Note**
Vous devez supprimer les première et dernière lignes (respectivement `-----BEGIN PRIVATE KEY-----` et `-----END PRIVATE KEY-----`) de la clé privée générée. En outre, vous devez supprimer les sauts de ligne dans la clé privée générée. La valeur résultante est une chaîne de caractères sans espace ni saut de ligne.
1. Pour **Selector name (Nom du sélecteur**, entrez le nom du sélecteur que vous avez spécifié dans les paramètres DNS de votre domaine.
1. Dans **DKIM signatures (Signatures DKIM)**, cochez la case **Enabled (Activé)**.
1. Sélectionnez **Enregistrer les modifications**.
**Pour mettre à jour une identité de domaine à l'aide de BYODKIM à partir du AWS CLI**
Pour configurer un domaine existant, utilisez l'opération `PutEmailIdentityDkimSigningAttributes` dans l'API Amazon SES.
1. Dans un éditeur de texte, collez le code suivant :
```
{
"SigningAttributes":{
"DomainSigningPrivateKey":"privateKey",
"DomainSigningSelector":"selector"
},
"SigningAttributesOrigin":"EXTERNAL"
}
```
Dans l’exemple précédent, apportez les modifications suivantes :
+ *privateKey*Remplacez-le par votre clé privée.
**Note**
Vous devez supprimer les première et dernière lignes (respectivement `-----BEGIN PRIVATE KEY-----` et `-----END PRIVATE KEY-----`) de la clé privée générée. En outre, vous devez supprimer les sauts de ligne dans la clé privée générée. La valeur résultante est une chaîne de caractères sans espace ni saut de ligne.
+ *selector*Remplacez-le par le sélecteur unique que vous avez spécifié lors de la création de l'enregistrement TXT dans la configuration DNS de votre domaine.
Lorsque vous avez terminé, enregistrez le fichier sous `update-identity.json`.
1. Sur la ligne de commande, entrez la commande suivante :
```
aws sesv2 put-email-identity-dkim-signing-attributes --email-identity example.com --cli-input-json file://path/to/update-identity.json
```
Dans l’exemple précédent, apportez les modifications suivantes :
+ *path/to/update-identity.json*Remplacez-le par le chemin complet du fichier que vous avez créé à l'étape précédente.
+ *example.com*Remplacez-le par le domaine que vous souhaitez mettre à jour.
### Vérification du statut DKIM pour un domaine qui utilise BYODKIM
**Pour vérifier le statut DKIM d'un domaine depuis la console**
Après avoir configuré un domaine pour utiliser BYODKIM, vous pouvez utiliser la console SES pour confirmer que DKIM est correctement configuré.
1. Connectez-vous à la console Amazon SES AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Dans le panneau de navigation, sous **Configuration**, choisissez **Verified identities (Identités vérifiées)**.
1. Dans la liste des identités, choisissez l'identité pour laquelle vous souhaitez vérifier le statut DKIM.
1. La propagation des modifications des paramètres DNS peut prendre jusqu'à 72 heures. Dès qu'Amazon SES détecte tous les registres DKIM requis dans les paramètres DNS de votre domaine, le processus de vérification est terminé. Si tout a été correctement configuré, le champ de **configuration DKIM** de votre domaine affiche **Successful** dans le volet **DomainKeysIdentified Mail (DKIM)**, et le champ **Identity status** affiche **Vérifié** dans le volet **Résumé**.
**Pour vérifier l'état DKIM d'un domaine à l'aide du AWS CLI**
Après avoir configuré un domaine pour utiliser BYODKIM, vous pouvez utiliser l' GetEmailIdentityopération pour vérifier que DKIM est correctement configuré.
+ Sur la ligne de commande, entrez la commande suivante :
```
aws sesv2 get-email-identity --email-identity example.com
```
Dans la commande précédente, remplacez *example.com* par votre domaine.
Cette commande renvoie un objet JSON qui contient une section semblable à l'exemple suivant.
```
{
...
"DkimAttributes": {
"SigningAttributesOrigin": "EXTERNAL",
"SigningEnabled": true,
"Status": "SUCCESS",
"Tokens": [ ]
},
...
}
```
BYODKIM est correctement configuré pour le domaine si toutes les conditions suivantes sont remplies :
+ La valeur de la propriété `SigningAttributesOrigin` est `EXTERNAL`.
+ La valeur du paramètre `SigningEnabled` est `true`.
+ La valeur de `Status` est `SUCCESS`.
# Gestion d'Easy DKIM et de BYODKIM
Vous pouvez gérer les paramètres DKIM pour vos identités authentifiées à l'aide d'Easy DKIM ou de BYODKIM via la console Amazon SES basée sur le web, ou à l'aide de l'API Amazon SES. Vous pouvez utiliser l'une ou l'autre de ces méthodes pour obtenir les registres DKIM pour une identité, ou pour activer ou désactiver la signature DKIM pour une identité.
## Obtention des registres DKIM pour une identité
Vous pouvez obtenir les registres DKIM pour votre domaine ou votre adresse e-mail à tout moment à l'aide de la console Amazon SES.
**Pour obtenir les registres DKIM pour une identité à l'aide de la console**
1. Connectez-vous à la console Amazon SES AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Dans le panneau de navigation, sous **Configuration**, choisissez **Verified identities (Identités vérifiées)**.
1. Dans la liste des identités, choisissez l'identité pour laquelle vous souhaitez obtenir les registres DKIM.
1. Dans l'onglet **Authentification** de la page de détails de l'identité, développez **View DNS records (Afficher les registres DNS)**.
1. Copiez soit les trois registres CNAME si vous avez utilisé Easy DKIM, soit le registre TXT si vous avez utilisé BYODKIM, qui apparaissent dans cette section. Sinon, vous pouvez choisir **Download Record Set as CSV (Télécharger le jeu de registres au format .csv)** pour enregistrer une copie des registres sur votre ordinateur.
L'image suivante illustre un exemple de la section étendue **View DNS records** (Afficher les registres DNS) qui présente les registres CNAME associés à Easy DKIM.
![\[\]](http://docs.aws.amazon.com/fr_fr/ses/latest/dg/images/dkim_existing_dns.png)
Vous pouvez aussi obtenir les registres DKIM d'une identité à l'aide de l'API Amazon SES. Une méthode courante pour interagir avec l'API consiste à utiliser AWS CLI.
**Pour obtenir les enregistrements DKIM d'une identité à l'aide du AWS CLI**
1. Sur la ligne de commande, entrez la commande suivante :
```
aws ses get-identity-dkim-attributes --identities "example.com"
```
Dans l'exemple précédent, remplacez *example.com* par l'identité pour laquelle vous souhaitez obtenir des enregistrements DKIM. Vous pouvez spécifier une adresse e-mail ou un domaine.
1. La sortie de cette commande contient une section `DkimTokens`, comme illustré dans l'exemple suivant :
```
{
"DkimAttributes": {
"example.com": {
"DkimEnabled": true,
"DkimVerificationStatus": "Success",
"DkimTokens": [
"hirjd4exampled5477y22yd23ettobi",
"v3rnz522czcl46quexamplek3efo5o6x",
"y4examplexbhyhnsjcmtvzotfvqjmdqoj"
]
}
}
}
```
Vous pouvez utiliser les jetons pour créer les registres CNAME que vous ajoutez aux paramètres DNS de votre domaine. Pour créer les registres CNAME, utilisez le modèle suivant :
```
token1._domainkey.example.com CNAME token1.dkim.amazonses.com
token2._domainkey.example.com CNAME token2.dkim.amazonses.com
token3._domainkey.example.com CNAME token3.dkim.amazonses.com
```
Remplacez chaque instance de *token1* par le premier jeton de la liste que vous avez reçu lorsque vous avez exécuté la `get-identity-dkim-attributes` commande, remplacez toutes les instances de *token2* par le deuxième jeton de la liste et remplacez toutes les instances de *token3* par le troisième jeton de la liste.
Par exemple, l'application de ce modèle aux jetons présentés dans l'exemple précédent génère les registres suivants :
```
hirjd4exampled5477y22yd23ettobi._domainkey.example.com CNAME hirjd4exampled5477y22yd23ettobi.dkim.amazonses.com
v3rnz522czcl46quexamplek3efo5o6x._domainkey.example.com CNAME v3rnz522czcl46quexamplek3efo5o6x.dkim.amazonses.com
y4examplexbhyhnsjcmtvzotfvqjmdqoj._domainkey.example.com CNAME y4examplexbhyhnsjcmtvzotfvqjmdqoj.dkim.amazonses.com
```
**Note**
Tous n' Régions AWS utilisent pas le domaine DKIM SES par défaut. `dkim.amazonses.com` Pour voir si votre région utilise un domaine DKIM spécifique à une région, consultez le tableau des [domaines DKIM](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_dkim_domains) dans le. *Références générales AWS*
## Désactivation d'Easy DKIM pour une identité
Vous pouvez rapidement désactiver l'authentification DKIM pour une identité à l'aide de la console Amazon SES.
**Pour désactiver DKIM pour une identité**
1. Connectez-vous à la console Amazon SES AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Dans le panneau de navigation, sous **Configuration**, choisissez **Verified identities (Identités vérifiées)**.
1. Dans la liste des identités, choisissez l'identité pour laquelle vous souhaitez désactiver DKIM.
1. Sous l'onglet **Authentification**, dans le conteneur **DomainKeysIdentified Mail (DKIM)**, choisissez **Modifier**.
1. Dans **Advanced DKIM settings (Paramètres avancés de DKIM)**, cochez la case **Enabled (Activé)** dans le champ **DKIM signatures (Signatures DKIM)**.
Vous pouvez également désactiver DKIM pour une identité à l'aide de l'API Amazon SES. Une méthode courante pour interagir avec l'API consiste à utiliser AWS CLI.
**Pour désactiver le DKIM pour une identité à l'aide du AWS CLI**
+ Sur la ligne de commande, entrez la commande suivante :
```
aws ses set-identity-dkim-enabled --identity example.com --no-dkim-enabled
```
Dans l'exemple précédent, remplacez *example.com* par l'identité pour laquelle vous souhaitez désactiver DKIM. Vous pouvez spécifier une adresse e-mail ou un domaine.
## Activation d'Easy DKIM pour une identité
Si vous avez déjà désactivé DKIM pour une identité, vous pouvez l'activer à nouveau à l'aide de la console Amazon SES.
**Pour activer DKIM pour une identité**
1. Connectez-vous à la console Amazon SES AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Dans le panneau de navigation, sous **Configuration**, choisissez **Verified identities (Identités vérifiées)**.
1. Dans la liste des identités, choisissez l'identité pour laquelle vous souhaitez activer DKIM.
1. Sous l'onglet **Authentification**, dans le conteneur **DomainKeysIdentified Mail (DKIM)**, choisissez **Modifier**.
1. Dans **Advanced DKIM settings (Paramètres avancés de DKIM)**, cochez la case **Enabled (Activé)** dans la zone **DKIM signatures (Signatures DKIM)**.
Vous pouvez également activer DKIM pour une identité à l'aide de l'API Amazon SES. Une méthode courante pour interagir avec l'API consiste à utiliser AWS CLI.
**Pour activer le DKIM pour une identité à l'aide du AWS CLI**
+ Sur la ligne de commande, entrez la commande suivante :
```
aws ses set-identity-dkim-enabled --identity example.com --dkim-enabled
```
Dans l'exemple précédent, remplacez *example.com* par l'identité pour laquelle vous souhaitez activer DKIM. Vous pouvez spécifier une adresse e-mail ou un domaine.
## Remplacement de la signature DKIM héritée sur une identité d'adresse e-mail
Dans cette section, vous découvrirez comment remplacer (désactiver ou activer) les propriétés de signature DKIM héritées du domaine parent sur une identité d'adresse e-mail spécifique déjà vérifiée avec Amazon SES. Cette opération n'est possible que pour les identités d'adresses e-mail qui appartiennent à des domaines dont vous êtes déjà propriétaire, car les paramètres DNS sont configurés au niveau du domaine.
**Important**
Vous ne pouvez pas signer disable/enable DKIM pour les identités d'adresses e-mail...
sur des domaines dont vous n'êtes pas le propriétaire. Par exemple, vous ne pouvez pas activer la signature DKIM pour une adresse *gmail.com* ou *hotmail.com*,
sur des domaines dont vous êtes propriétaire, mais qui n'ont pas encore été vérifiés dans Amazon SES,
sur des domaines dont vous êtes propriétaire, mais qui n'ont pas activé la signature DKIM sur le domaine.
Cette section contient les rubriques suivantes :
+ [Comprendre les propriétés de signature DKIM héritées](#dkim-easy-setup-email-key-points-mng)
+ [Remplacement de la signature DKIM sur une identité d'adresse e-mail (console)](#override-dkim-email-console-mng)
+ [Remplacement de la signature DKIM sur une identité d'adresse e-mail (AWS CLI)](#override-dkim-email-cli-mng)
### Comprendre les propriétés de signature DKIM héritées
Il est important de comprendre d'abord qu'une identité d'adresse e-mail hérite de ses propriétés de signature DKIM de son domaine parent si ce domaine a été configuré avec DKIM, indépendamment du fait que Easy DKIM ou BYODKIM ait été utilisé. Par conséquent, la désactivation ou l'activation de la signature DKIM sur l'identité de l'adresse e-mail remplace les propriétés de signature DKIM du domaine sur la base de ces éléments clés :
+ Si vous avez déjà configuré DKIM pour le domaine auquel appartient une adresse e-mail, vous n'avez pas besoin d'activer la signature DKIM pour l'identité de l'adresse e-mail également.
+ Lorsque vous configurez DKIM pour un domaine, Amazon SES authentifie automatiquement chaque e-mail provenant de chaque adresse de ce domaine grâce aux propriétés DKIM héritées du domaine parent.
+ Les paramètres DKIM pour une identité d'adresse e-mail spécifique *remplacent automatiquement les paramètres du domaine ou du sous-domaine parent (le cas échéant)* auquel l'adresse appartient.
Étant donné que les propriétés de signature DKIM de l'identité d'adresse e-mail sont héritées du domaine parent, si vous envisagez de remplacer ces propriétés, vous devez garder à l'esprit les règles hiérarchiques de remplacement, comme expliqué dans le tableau ci-dessous.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/ses/latest/dg/send-email-authentication-dkim-easy-managing.html)
Il n'est généralement pas recommandé de désactiver la signature DKIM, car cela risque de ternir la réputation de l'expéditeur et d'augmenter le risque de voir les e-mails que vous envoyez aboutir dans les dossiers de courrier indésirable ou de spam, ou de voir votre domaine usurpé.
Toutefois, il existe la possibilité de remplacer les propriétés de signature DKIM héritées du domaine sur une identité d'adresse e-mail pour tout cas d'utilisation particulier ou décision commerciale externe pour lesquels vous pourriez avoir à désactiver la signature DKIM de façon permanente ou temporaire, ou à la réactiver ultérieurement.
### Remplacement de la signature DKIM sur une identité d'adresse e-mail (console)
La procédure suivante de la console SES explique comment remplacer (désactiver ou activer) les propriétés de signature DKIM héritées du domaine parent sur une identité d'adresse e-mail spécifique déjà vérifiée avec Amazon SES.
**Vers la signature disable/enable DKIM pour l'identité d'une adresse e-mail à l'aide de la console**
1. Connectez-vous à la console Amazon SES AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Dans le panneau de navigation, sous **Configuration**, choisissez **Verified identities (Identités vérifiées)**.
1. Dans la liste des identités, choisissez une identité dont l'**Identity type (Type d'identité)** est *Email address (Adresse e-mail)* et qui appartient à l'un de vos domaines vérifiés.
1. Sous l'onglet **Authentification**, dans le conteneur **DomainKeys Identified Mail (DKIM)**, choisissez **Modifier**.
**Note**
L'onglet **Authentification (Authentification)** n'est présent que si l'identité de l'adresse e-mail sélectionnée appartient à un domaine qui a déjà été vérifié par SES. Si vous n'avez pas encore vérifié votre domaine, voir [Création d'une identité de domaine](creating-identities.md#verify-domain-procedure).
1. Sous **Advanced DKIM settings (Paramètres avancés DKIM)**, dans le champ **DKIM signatures (Signatures DKIM)**, effacez la case **Enabled (Activé)** pour désactiver la signature DKIM ou sélectionnez-la pour réactiver la signature DKIM (si elle a été désactivée précédemment).
1. Sélectionnez **Enregistrer les modifications**.
### Remplacement de la signature DKIM sur une identité d'adresse e-mail (AWS CLI)
L'exemple suivant utilise la commande AWS CLI avec une API SES et des paramètres qui remplaceront (désactiveront ou activeront) les propriétés de signature DKIM héritées du domaine parent sur une identité d'adresse e-mail spécifique que vous avez déjà vérifiée auprès de SES.
**À la signature disable/enable DKIM pour l'identité d'une adresse e-mail à l'aide du AWS CLI**
+ En supposant que vous soyez propriétaire du domaine *exemple.com* et que vous souhaitiez désactiver la signature DKIM pour l'une des adresses e-mail du domaine, dans la ligne de commande, tapez la commande suivante :
```
aws sesv2 put-email-identity-dkim-attributes --email-identity marketing@example.com --no-signing-enabled
```
1. *marketing@example.com*Remplacez-le par l'identité de l'adresse e-mail pour laquelle vous souhaitez désactiver la signature DKIM.
1. `--no-signing-enabled` désactive la signature DKIM. Pour réactiver la signature DKIM, utilisez `--signing-enabled`.
# Signature DKIM manuelle dans Amazon SES
Au lieu d'utiliser Easy DKIM, vous pouvez aussi ajouter manuellement des signatures DKIM à vos messages, puis envoyer ces messages en utilisant Amazon SES. Si vous choisissez de signer manuellement vos messages, vous devez d'abord créer une signature DKIM. Après avoir créé le message et la signature DKIM, vous pouvez utiliser l'[SendRawEmail](https://docs.aws.amazon.com/ses/latest/APIReference/API_SendRawEmail.html)API pour l'envoyer.
Si vous décidez de signer manuellement vos e-mails, tenez compte des éléments suivants :
+ Chaque message que vous envoyez à l'aide d'Amazon SES contient un en-tête DKIM qui fait référence à un domaine de signature d'*amazonses.com* (c'est-à-dire qu'il contient la chaîne suivante : `d=amazonses.com`). Si vous signez manuellement vos messages, ces derniers doivent inclure *deux* en-têtes DKIM : un pour votre domaine, et et celui que Amazon SES crée automatiquement pour *amazonses.com*.
+ Amazon SES ne valide pas les signatures DKIM que vous ajoutez manuellement à vos messages. Si la signature DKIM d'un message contient des erreurs, il peut être rejeté par les fournisseurs de messagerie.
+ Lorsque vous signez vos messages, vous devez utiliser une longueur de bit d'au moins 1024 bits.
+ Ne signez pas les champs suivants : Message-ID, Date, Return-Path (Chemin de retour), Bounces-To.
**Note**
Si vous utilisez un client de messagerie pour envoyer des e-mails à l'aide de l'interface SMTP Amazon SES, votre client peut exécuter automatiquement la signature DKIM de vos messages. Certains clients peuvent signer certains de ces champs. Consultez la documentation de votre client de messagerie pour savoir quels sont les champs qui sont signés par défaut.
# Authentification d'e-mails avec SPF dans Amazon SES
*Sender Policy Framework* (SPF) est une norme de validation des e-mails conçue pour lutter contre l'usurpation de messagerie. Les propriétaires de domaine utilisent SPF pour indiquer aux fournisseurs de messagerie les serveurs autorisés à envoyer des e-mails à partir de leur domaine. SPF est défini dans [RFC 7208](https://tools.ietf.org/html/rfc7208).
Les messages que vous envoyez via Amazon SES utilisent automatiquement un sous-domaine `amazonses.com` en tant que domaine MAIL FROM. L'authentification SPF valide avec succès ces messages, parce que le domaine MAIL FROM par défaut correspond à l'application qui a envoyé l'e-mail, dans ce cas SES. Par conséquent, dans SES, le SPF est implicitement configuré pour vous.
Toutefois, si vous ne souhaitez pas utiliser le domaine MAIL FROM par défaut de SES, mais que vous préférez utiliser un sous-domaine d'un domaine que vous possédez, cela est appelé dans SES un domaine MAIL *FROM personnalisé*. Pour ce faire, vous devez publier votre propre enregistrement SPF pour votre domaine MAIL FROM personnalisé. En outre, SES requiert que vous configuriez un registre MX afin que votre domaine MAIL FROM personnalisé puisse recevoir les notifications de retour à l'expéditeur et de réclamation que les fournisseurs de messagerie vous envoient.
**Découvrez comment configurer l'authentification SPF**
Des instructions sont données pour configurer votre domaine avec SPF et pour publier les enregistrements MX et SPF (type TXT) dans. [Utilisation d'un domaine MAIL FROM personnalisé](mail-from.md)
# Utilisation d'un domaine MAIL FROM personnalisé
Lorsqu'un e-mail est envoyé, il possède deux adresses qui indiquent sa source : une adresse d'expédition qui s'affiche pour le destinataire du message et une adresse MAIL FROM qui indique l'origine du message. L'adresse MAIL FROM est parfois appelée *enveloppe d'expéditeur*, *enveloppe from*, *adresse de retour à l'expéditeur* ou adresse de *chemin de retour*. Les serveurs de messagerie utilisent l'adresse MAIL FROM pour renvoyer des messages de retour à l'expéditeur et d'autres notifications d'erreur. L'adresse MAIL FROM est généralement visible par les destinataires seulement s'ils affichent le code source du message.
Amazon SES définit une valeur de domaine MAIL FROM par défaut pour les messages que vous envoyez, sauf si vous spécifiez votre propre domaine (personnalisé). Cette section présente les avantages de la configuration d'un domaine MAIL FROM personnalisé et inclut les procédures de configuration.
## Pourquoi utiliser un domaine MAIL FROM personnalisé ?
Les messages que vous envoyez via Amazon SES utilisent automatiquement un sous-domaine `amazonses.com` en tant que domaine MAIL FROM. L'authentification SPF (Sender Policy Framework) valide avec succès ces messages, parce que le domaine MAIL FROM par défaut correspond à l'application qui a envoyé l'e-mail, dans ce cas SES.
Si vous ne souhaitez pas utiliser le domaine MAIL FROM par défaut de SES et que vous préférez utiliser un sous-domaine d'un domaine qui vous appartient, SES mentionne l'utilisation d'un domaine MAIL FROM *personnalisé*. Pour ce faire, vous devez publier votre propre enregistrement SPF pour votre domaine MAIL FROM personnalisé. En outre, SES requiert que vous configuriez un registre MX afin que votre domaine puisse recevoir les notifications de retour à l'expéditeur et de réclamation que les fournisseurs de messagerie vous envoient.
En utilisant un domaine MAIL FROM personnalisé, vous pouvez utiliser SPF, DKIM ou les deux pour obtenir la validation [DMARC (Domain-based Message Authentication, Reporting and Conformance)](send-email-authentication-dmarc.md). La spécification DMARC permet au domaine d'un expéditeur d'indiquer que les e-mails envoyés depuis le domaine sont protégés par un ou plusieurs systèmes d'authentification. Il existe deux façons de passer la validation DMARC : avec [Conformité à DMARC via SPF](send-email-authentication-dmarc.md#send-email-authentication-dmarc-spf) ou [Conformité à DMARC via DKIM](send-email-authentication-dmarc.md#send-email-authentication-dmarc-dkim).
## Choix d'un domaine MAIL FROM personnalisé
Dans ce qui suit, le terme *domaine MAIL FROM* fait toujours référence à un sous-domaine d'un domaine que vous possédez. Ce sous-domaine que vous utilisez pour votre domaine MAIL FROM personnalisé ne doit pas être utilisé pour autre chose et répondre aux exigences suivantes :
+ Le domaine MAIL FROM doit être un sous-domaine du domaine parent d'une identité vérifiée (adresse e-mail ou domaine).
+ Le domaine MAIL FROM ne doit pas être un sous-domaine que vous utilisez également pour envoyer des e-mails.
+ Le domaine MAIL FROM ne doit pas être un sous-domaine que vous utilisez pour recevoir des e-mails.
## Utilisation de SPF avec votre domaine MAIL FROM personnalisé
*Sender Policy Framework* (SPF) est une norme de validation des e-mails conçue pour lutter contre l'usurpation de messagerie. Vous pouvez configurer votre domaine MAIL FROM personnalisé avec SPF pour indiquer aux fournisseurs de messagerie quels serveurs sont autorisés à envoyer des e-mails à partir de votre domaine MAIL FROM personnalisé. SPF est défini dans [RFC 7208](https://tools.ietf.org/html/rfc7208).
Pour configurer SPF, vous publiez un registre TXT sur la configuration DNS de votre domaine MAIL FROM personnalisé. Cet registre contient une liste des serveurs que vous autorisez à envoyer des e-mails à partir de votre domaine MAIL FROM personnalisé. Lorsqu'un fournisseur de messagerie reçoit un message de votre domaine MAIL FROM personnalisé, il vérifie les registres DNS de votre domaine pour s'assurer que l'e-mail a été envoyé à partir d'un serveur autorisé.
Si vous souhaitez utiliser cet enregistrement SPF pour vous conformer à la norme DMARC, le domaine indiqué dans l'adresse de l'expéditeur doit correspondre au domaine MAIL FROM. Consultez [Conformité à DMARC via SPF](send-email-authentication-dmarc.md#send-email-authentication-dmarc-spf).
La section suivante, [Configuration de votre domaine MAIL FROM personnalisé](#mail-from-set), explique comment configurer SPF pour votre domaine MAIL FROM personnalisé.
## Configuration de votre domaine MAIL FROM personnalisé
Le processus de configuration d'un domaine MAIL FROM personnalisé nécessite que vous ajoutiez des registres à la configuration DNS du domaine. SES vous demande de publier un enregistrement MX afin que votre domaine puisse recevoir les notifications de rebond et de réclamation que les fournisseurs de messagerie vous envoient. Vous devez également publier un registre SPF (type TXT) afin de prouver qu'Amazon SES est autorisé à envoyer des e-mails à partir de votre domaine.
Vous pouvez configurer un domaine MAIL FROM personnalisé pour un domaine entier ou un sous-domaine, ainsi que pour des adresses e-mail individuelles. Les procédures suivantes montrent comment utiliser la console Amazon SES pour configurer un domaine MAIL FROM personnalisé. Vous pouvez également configurer un domaine MAIL FROM personnalisé à l'aide de l'opération [SetIdentityMailFromDomain](https://docs.aws.amazon.com/ses/latest/APIReference/API_SetIdentityMailFromDomain.html)API.
### Configuration d'un domaine MAIL FROM personnalisé pour un domaine vérifié
Ces procédures vous montrent comment configurer un domaine MAIL FROM personnalisé pour un domaine entier ou un sous-domaine afin que tous les messages envoyés depuis les adresses de ce domaine utilisent ce domaine MAIL FROM personnalisé.
**Pour configurer un domaine vérifié afin d'utiliser un domaine MAIL FROM personnalisé spécifié**
1. Ouvrez la console Amazon SES à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Dans le panneau de navigation de gauche, sous **Configuration**, sélectionnez **Identités**.
1. Dans la liste des identités, choisissez l'identité que vous souhaitez configurer pour laquelle **Identity type (Type d'identité)** est **Domain (Domaine)** et **Status (État)** est *Verified (Vérifié)*.
1. Si l'icône **Status (État)** est *Unverified (Non vérifié)*, complétez les procédures de la section [Vérification d’une identité de domaine DKIM auprès de votre fournisseur DNS](creating-identities.md#just-verify-domain-proc) pour vérifier le domaine de l'adresse e-mail.
1. Au bas de l'écran, dans le volet **Custom MAIL FROM domain**, choisissez **Modifier**.
1. Dans le panneau **General details (Informations générales)**, procédez de la façon suivante :
1. Cochez la case **Use a custom MAIL FROM domain (Utiliser un domaine MAIL FROM personnalisé)**.
1. Pour **MAIL FROM domain (Domaine MAIL FROM)**, entrez le sous-domaine que vous souhaitez utiliser en tant que domaine MAIL FROM.
1. Pour **Behavior on MX failure (Comportement en cas d'échec MX)**, choisissez l'une des options suivantes :
+ **Use default MAIL FROM domain (Utiliser le domaine MAIL FROM par défaut)** – Si l'enregistrement MX du domaine MAIL FROM personnalisé n'est pas configuré correctement, Amazon SES utilise un sous-domaine de `amazonses.com`. Le sous-domaine varie en fonction du domaine dans Région AWS lequel vous utilisez Amazon SES.
+ **Reject message (Message rejeté)** – Si le registre MX du domaine MAIL FROM personnalisé n'est pas configuré correctement, Amazon SES retourne une erreur `MailFromDomainNotVerified`. Les e-mails que vous essayez d'envoyer à partir de ce domaine sont automatiquement rejetés.
1. Choisissez **Save changes (Enregistrer les modifications)** ; vous reviendrez à l'écran précédent.
1. Publiez les enregistrements MX et SPF (type TXT) sur le serveur DNS du domaine MAIL FROM personnalisé.
Dans le volet **Custom MAIL FROM domain (Domaine MAIL FROM personnalisé)**, le tableau **Publish DNS records (Publier les enregistrements DNS)** affiche maintenant les enregistrements MX et SPF (type TXT) que vous devez publier (ajouter) à la configuration DNS de votre domaine. Ces registres utilisent les formats indiqués dans le tableau suivant.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/ses/latest/dg/mail-from.html)
Dans les enregistrements précédents,
+ *subdomain*. *domain*. *com*sera renseigné avec votre sous-domaine MAIL FROM
+ *region*sera renseigné avec le nom de l' Région AWS endroit où vous souhaitez vérifier le domaine MAIL FROM (tel que `us-west-2``us-east-1`,`eu-west-1`, ou, etc.)
+ Le nombre *10* en regard de la valeur MX est l'ordre de préférence du serveur de messagerie et devra être entré dans un champ de valeur distinct tel que spécifié par l'interface graphique de votre fournisseur DNS ;
+ La valeur d'enregistrement TXT du SPF doit généralement inclure les guillemets, mais certains fournisseurs DNS n'en ont pas besoin.
À partir du tableau **Publish DNS records (Publier les enregistrements DNS)**, copiez les enregistrements MX et SPF (type TXT) en choisissant l'icône de copie en regard de chaque valeur et collez-les dans les champs correspondants de l'interface graphique de votre fournisseur DNS. Sinon, vous pouvez choisir **Download Record Set as CSV (Télécharger le jeu de registres au format .csv)** pour enregistrer une copie des registres sur votre ordinateur.
**Important**
Les procédures spécifiques de publication des enregistrements MX et SPF (type TXT) dépendent de votre DNS ou de votre fournisseur d'hébergement. Consultez la documentation de votre fournisseur ou contactez-le pour obtenir des informations sur l'ajout de ces enregistrements à la configuration DNS de votre domaine.
Pour configurer correctement un domaine MAIL FROM personnalisé avec Amazon SES, vous devez publier un seul registre MX sur le serveur DNS de votre domaine MAIL FROM. Si le domaine MAIL FROM a plusieurs registres MX, la configuration MAIL FROM personnalisée avec Amazon SES échoue.
Si Route 53 fournit le service DNS pour votre domaine MAIL FROM et que vous êtes connecté au même compte que AWS Management Console celui que vous utilisez pour Route 53, choisissez **Publier les enregistrements à l'aide de Route 53**. Les registres DNS sont automatiquement appliqués à la configuration DNS de votre domaine.
Si vous utilisez un autre fournisseur DNS, vous devez publier manuellement les registres DNS sur le serveur DNS du domaine MAIL FROM. La procédure d'ajout de registres DNS au serveur DNS de votre domaine varie en fonction de votre service d'hébergement web ou de votre fournisseur DNS.
Les procédures de publication des registres DNS de votre domaine varient en fonction du fournisseur DNS que vous utilisez. Le tableau suivant comprend des liens vers de la documentation relative à quelques fournisseurs DNS courants. Cette liste n'est pas exhaustive et n’a pas valeur d'approbation. De même, si votre fournisseur DNS n'est pas répertorié, cela ne signifie pas qu'il ne prend pas en charge la configuration du domaine MAIL FROM.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/ses/latest/dg/mail-from.html)
Quand Amazon SES détecte que les registres sont en place, vous recevez un e-mail vous informant que votre domaine MAIL FROM personnalisé a été configuré avec succès. En fonction de votre fournisseur DNS, il peut y avoir un délai de 72 heures avant qu'Amazon SES ne détecte le registre MX.
### Configuration d'un domaine MAIL FROM personnalisé pour une adresse e-mail vérifiée
Vous pouvez également configurer un domaine MAIL FROM personnalisé pour une adresse e-mail spécifique. Pour configurer un domaine MAIL FROM personnalisé pour une adresse e-mail, vous devez modifier les registres DNS pour le domaine auquel l'adresse e-mail est associée.
**Note**
Vous ne pouvez pas configurer un domaine MAIL FROM personnalisé pour les adresses d'un domaine qui ne vous appartient pas (par exemple, vous ne pouvez pas créer un domaine MAIL FROM personnalisé pour une adresse sur le domaine `gmail.com`, car vous ne pouvez pas ajouter les registres DNS nécessaires au domaine).
**Pour configurer une adresse e-mail vérifiée afin qu'elle utilise un domaine MAIL FROM spécifié**
1. Ouvrez la console Amazon SES à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Dans le panneau de navigation de gauche, sous **Configuration**, sélectionnez **Identités**.
1. Dans la liste des identités, choisissez l'identité que vous souhaitez configurer pour laquelle **Identity type (Type d'identité)** est **Email address (Adresse e-mail)** et **Status (État)** est *Verified (Vérifié)*.
1. Si l'icône **Status (État)** est *Unverified (Non vérifié)*, complétez les procédures de la section [Vérification d'une identité d'adresse e-mail](creating-identities.md#just-verify-email-proc) pour vérifier le domaine de l'adresse e-mail.
1. Sous l'onglet **MAIL FROM Domain (Domaine MAIL FROM)**, choisissez **Edit (Modifier)** dans le panneau **Custom MAIL FROM domain (Domaine MAIL FROM personnalisé)**.
1. Dans le panneau **General details (Informations générales)**, procédez de la façon suivante :
1. Cochez la case **Use a custom MAIL FROM domain (Utiliser un domaine MAIL FROM personnalisé)**.
1. Pour **MAIL FROM domain (Domaine MAIL FROM)**, entrez le sous-domaine que vous souhaitez utiliser en tant que domaine MAIL FROM.
1. Pour **Behavior on MX failure (Comportement en cas d'échec MX)**, choisissez l'une des options suivantes :
+ **Use default MAIL FROM domain (Utiliser le domaine MAIL FROM par défaut)** – Si l'enregistrement MX du domaine MAIL FROM personnalisé n'est pas configuré correctement, Amazon SES utilise un sous-domaine de `amazonses.com`. Le sous-domaine varie en fonction du domaine dans Région AWS lequel vous utilisez Amazon SES.
+ **Reject message (Message rejeté)** – Si le registre MX du domaine MAIL FROM personnalisé n'est pas configuré correctement, Amazon SES retourne une erreur `MailFromDomainNotVerified`. Les e-mails que vous essayez d'envoyer à partir de cette adresse sont automatiquement rejetés.
1. Choisissez **Save changes (Enregistrer les modifications)** ; vous reviendrez à l'écran précédent.
1. Publiez les enregistrements MX et SPF (type TXT) sur le serveur DNS du domaine MAIL FROM personnalisé.
Dans le volet **Custom MAIL FROM domain (Domaine MAIL FROM personnalisé)**, le tableau **Publish DNS records (Publier les enregistrements DNS)** affiche maintenant les enregistrements MX et SPF (type TXT) que vous devez publier (ajouter) à la configuration DNS de votre domaine. Ces registres utilisent les formats indiqués dans le tableau suivant.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/ses/latest/dg/mail-from.html)
Dans les enregistrements précédents,
+ *subdomain*. *domain*. *com*sera renseigné avec votre sous-domaine MAIL FROM
+ *region*sera renseigné avec le nom de l' Région AWS endroit où vous souhaitez vérifier le domaine MAIL FROM (tel que `us-west-2``us-east-1`,`eu-west-1`, ou, etc.)
+ Le nombre *10* en regard de la valeur MX est l'ordre de préférence du serveur de messagerie et devra être entré dans un champ de valeur distinct tel que spécifié par l'interface graphique de votre fournisseur DNS ;
+ La valeur d’enregistrement TXT SPF doit inclure des guillemets.
À partir du tableau **Publish DNS records (Publier les enregistrements DNS)**, copiez les enregistrements MX et SPF (type TXT) en choisissant l'icône de copie en regard de chaque valeur et collez-les dans les champs correspondants de l'interface graphique de votre fournisseur DNS. Sinon, vous pouvez choisir **Download Record Set as CSV (Télécharger le jeu de registres au format .csv)** pour enregistrer une copie des registres sur votre ordinateur.
**Important**
Pour configurer correctement un domaine MAIL FROM personnalisé avec Amazon SES, vous devez publier un seul registre MX sur le serveur DNS de votre domaine MAIL FROM. Si le domaine MAIL FROM a plusieurs registres MX, la configuration MAIL FROM personnalisée avec Amazon SES échoue.
Si Route 53 fournit le service DNS pour votre domaine MAIL FROM et que vous êtes connecté au même compte que AWS Management Console celui que vous utilisez pour Route 53, choisissez **Publier les enregistrements à l'aide de Route 53**. Les registres DNS sont automatiquement appliqués à la configuration DNS de votre domaine.
Si vous utilisez un autre fournisseur DNS, vous devez publier manuellement les registres DNS sur le serveur DNS du domaine MAIL FROM. La procédure d'ajout de registres DNS au serveur DNS de votre domaine varie en fonction de votre service d'hébergement web ou de votre fournisseur DNS.
Les procédures de publication des registres DNS de votre domaine varient en fonction du fournisseur DNS que vous utilisez. Le tableau suivant comprend des liens vers de la documentation relative à quelques fournisseurs DNS courants. Cette liste n'est pas exhaustive et n’a pas valeur d'approbation. De même, si votre fournisseur DNS n'est pas répertorié, cela ne signifie pas qu'il ne prend pas en charge la configuration du domaine MAIL FROM.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/ses/latest/dg/mail-from.html)
Quand Amazon SES détecte que les registres sont en place, vous recevez un e-mail vous informant que votre domaine MAIL FROM personnalisé a été configuré avec succès. En fonction de votre fournisseur DNS, il peut y avoir un délai de 72 heures avant qu'Amazon SES ne détecte le registre MX.
## États de configuration du domaine MAIL FROM personnalisé avec Amazon SES
Une fois que vous avez configuré une identité pour qu'elle utilise un domaine MAIL FROM personnalisé, l'état de la configuration est « pending » (« en attente ») tandis qu'Amazon SES tente de détecter le registre MX requis dans vos paramètres DNS. L'état est alors modifié selon qu'Amazon SES détecte le registre MX. Le tableau suivant décrit le comportement d'envoi d'e-mails, ainsi que les actions Amazon SES associées à chaque état. Chaque fois que l'état change, Amazon SES envoie une notification à l'adresse e-mail associée à votre Compte AWS.
****
| State | Comportement d'envoi d'e-mails | Actions Amazon SES |
| --- | --- | --- |
| En attente | Utilise le paramètre de rechange MAIL FROM personnalisé | Amazon SES tente de détecter le registre MX requis pendant 72 heures. En cas d'échec, l'état devient « Failed ». |
| Réussite | Utilise le domaine MAIL FROM personnalisé | Amazon SES vérifie continuellement que le registre MX requis est en place. |
| TemporaryFailure | Utilise le paramètre de rechange MAIL FROM personnalisé | Amazon SES tente de détecter le registre MX requis pendant 72 heures. En cas d'échec, l'état devient « Failed » ; en cas de succès, l'état devient « Success ». |
| Échec | Utilise le paramètre de rechange MAIL FROM personnalisé | Amazon SES ne tente plus de détecter le registre MX requis. Pour utiliser un domaine MAIL FROM personnalisé, vous devez redémarrer le processus de configuration dans [Configuration de votre domaine MAIL FROM personnalisé](#mail-from-set). |
# Mise en conformité au protocole d'authentification DMARC dans Amazon SES
L'authentification, le reporting et la conformité des messages basés sur le domaine (DMARC) est un protocole d'authentification des e-mails qui utilise le Sender Policy Framework (SPF) et le courrier DomainKeys identifié (DKIM) pour détecter l'usurpation d'e-mail et le phishing. Pour être conformes au DMARC, les messages doivent être authentifiés par le biais du SPF ou du DKIM, mais idéalement, lorsque les deux sont utilisés avec le DMARC, vous garantissez le plus haut niveau de protection possible pour l'envoi de vos e-mails.
Passons brièvement en revue ce que fait chacun d'eux et comment le DMARC les lie tous ensemble :
+ **SPF** — Identifie les serveurs de messagerie autorisés à envoyer des e-mails au nom de votre domaine MAIL FROM personnalisé via un enregistrement DNS TXT utilisé par le DNS. Les systèmes de messagerie des destinataires se réfèrent à l'enregistrement TXT SPF pour déterminer si un message provenant de votre domaine personnalisé provient d'un serveur de messagerie autorisé. Fondamentalement, le SPF est conçu pour aider à prévenir l'usurpation d'identité, mais il existe des techniques d'usurpation auxquelles le SPF est susceptible d'être utilisé dans la pratique. C'est pourquoi vous devez également utiliser le DKIM en même temps que le DMARC.
+ **DKIM** — Ajoute une signature numérique à vos messages sortants dans l'en-tête de l'e-mail. Les systèmes de réception de courrier électronique peuvent utiliser cette signature numérique pour vérifier si le courrier entrant est signé par une clé appartenant au domaine. Toutefois, lorsqu'un système de courrier électronique de réception transmet un message, l'enveloppe du message est modifiée de manière à invalider l'authentification SPF. Comme la signature numérique est conservée dans le message électronique parce qu'elle fait partie de l'en-tête du message, DKIM fonctionne même lorsqu'un message a été transféré entre les serveurs de messagerie (tant que le contenu du message n'a pas été modifié).
+ **DMARC** — Garantit l'alignement du domaine avec au moins l'un des formats SPF et DKIM. L'utilisation du SPF et du DKIM à elle seule ne garantit pas que l'adresse d'expéditeur est authentifiée (il s'agit de l'adresse e-mail que votre destinataire voit dans son client de messagerie). SPF vérifie uniquement le domaine spécifié dans l'adresse MAIL FROM (non vu par votre destinataire). DKIM vérifie uniquement le domaine spécifié dans la signature DKIM (également invisible pour votre destinataire). Le DMARC résout ces deux problèmes en exigeant que l'alignement des domaines soit correct sur le SPF ou sur le DKIM :
+ Pour que le SPF passe l'alignement DMARC, le domaine de l'adresse d'origine doit correspondre au domaine de l'adresse MAIL FROM (également appelé chemin de retour et adresse d'enveloppe d'origine). Cela est rarement possible avec le courrier transféré parce qu'il est supprimé ou lorsque le courrier est envoyé par le biais de fournisseurs de messagerie groupés tiers, car le chemin de retour (MAIL FROM) est utilisé pour les rebonds et les plaintes que le fournisseur (SES) suit à l'aide d'une adresse qu'il possède.
+ Pour que le DKIM passe l'alignement DMARC, le domaine spécifié dans la signature DKIM doit correspondre au domaine indiqué dans l'adresse d'origine. Si vous utilisez des expéditeurs ou des services tiers qui envoient du courrier en votre nom, vous pouvez le faire en vous assurant que l'expéditeur tiers est correctement configuré pour la signature DKIM et que vous avez ajouté les enregistrements DNS appropriés dans votre domaine. Les serveurs de messagerie de réception seront alors en mesure de vérifier le courrier électronique qui leur est envoyé par votre tiers comme s'il s'agissait d'un e-mail envoyé par une personne autorisée à utiliser une adresse du domaine.
**Tout mettre en place avec le DMARC**
Les contrôles d'alignement DMARC dont nous avons parlé ci-dessus montrent comment SPF, DKIM et DMARC fonctionnent tous ensemble pour renforcer la confiance dans votre domaine et la livraison de vos e-mails dans les boîtes de réception. Pour ce faire, le DMARC s'assure que l'adresse de provenance, vue par le destinataire, est authentifiée par le SPF ou le DKIM :
+ Un message passe le DMARC si l'un ou les deux contrôles SPF ou DKIM décrits sont réussis.
+ Un message échoue au DMARC si les deux contrôles SPF ou DKIM décrits échouent.
Par conséquent, le SPF et le DKIM sont tous deux nécessaires pour que le DMARC ait les meilleures chances d'authentifier votre courrier électronique envoyé, et en utilisant les trois, vous contribuerez à garantir un domaine d'envoi entièrement protégé.
Le DMARC vous permet également d'indiquer aux serveurs de messagerie comment traiter les e-mails lorsqu'ils échouent à l'authentification DMARC grâce à des politiques que vous définissez. Cela sera expliqué dans la section suivante[Configuration de la stratégie DMARC sur votre domaine](#send-email-authentication-dmarc-dns), qui contient des informations sur la façon de configurer vos domaines SES afin que les e-mails que vous envoyez soient conformes au protocole d'authentification DMARC via SPF et DKIM.
## Configuration de la stratégie DMARC sur votre domaine
Pour configurer DMARC, vous devez modifier les paramètres DNS de votre domaine. Les paramètres DNS de votre domaine doivent inclure un registre TXT qui spécifie les paramètres DMARC du domaine. Les procédures d'ajout de registres TXT à votre configuration DNS dépendent du fournisseur DNS ou d'hébergement que vous utilisez. Si vous utilisez Route 53, veuillez consulter [Utilisation des registres](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html) dans le *Guide du développeur Amazon Route 53*. Si vous utilisez un autre fournisseur, consultez la documentation de configuration DNS de celui-ci.
Le nom de le registre TXT que vous créez doit être `_dmarc.example.com`, où `example.com` est votre domaine. La valeur de le registre TXT contient la stratégie DMARC qui s'applique à votre domaine. Voici un exemple de registre TXT qui contient une stratégie DMARC :
| Nom | Type | Value |
| --- | --- | --- |
| \$1dmarc.example.com | TXT | "v=DMARC1;p=quarantine;rua=mailto:my\$1dmarc\$1report@example.com" |
Dans l'exemple de politique DMARC précédent, cette politique indique aux fournisseurs de messagerie de faire ce qui suit :
+ Pour tous les messages dont l'authentification échoue, envoyez-les dans le dossier Spam comme indiqué par le paramètre de politique,`p=quarantine`. Les autres options incluent le fait de ne rien faire en utilisant`p=none`, ou de rejeter purement et simplement le message en utilisant`p=reject`.
+ La section suivante explique comment et quand utiliser ces trois paramètres de politique. Si *vous utilisez le mauvais paramètre au mauvais moment, votre e-mail ne sera pas livré,* voir[Bonnes pratiques pour la mise en œuvre du DMARC](#send-email-authentication-dmarc-implement).
+ Envoyez des rapports sur tous les e-mails dont l'authentification a échoué dans un résumé (c'est-à-dire un rapport qui agrège les données pour une certaine période, plutôt que d'envoyer des rapports individuels pour chaque événement) comme spécifié par le paramètre de rapport `rua=mailto:my_dmarc_report@example.com` (*rua* signifie Reporting URI for Aggregate reports). En règle générale, les fournisseurs de messagerie envoient ces rapports consolidés une fois par jour, même si ces stratégies diffèrent d'un fournisseur à l'autre.
Pour en savoir plus sur la configuration DMARC pour votre domaine, consultez sa [présentation](https://dmarc.org/overview/) sur le site web DMARC.
Pour les spécifications complètes du système DMARC, voir le projet DMARC de l'[Internet Engineering Task Force (IETF).](https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/)
## Bonnes pratiques pour la mise en œuvre du DMARC
Il est préférable de mettre en œuvre l'application de votre politique DMARC de manière progressive et progressive afin de ne pas interrompre le reste de votre flux de messagerie. Créez et mettez en œuvre un plan de déploiement qui suit ces étapes. Effectuez chacune de ces étapes d'abord avec chacun de vos sous-domaines, puis avec le domaine de premier niveau de votre organisation avant de passer à l'étape suivante.
1. Surveillez l'impact de la mise en œuvre du DMARC (p=none).
+ Commencez par un simple enregistrement en mode surveillance pour un sous-domaine ou un domaine qui demande aux organisations de réception de courrier de vous envoyer des statistiques sur les messages qu'elles voient en utilisant ce domaine. Un enregistrement en mode surveillance est un enregistrement TXT DMARC dont la politique est définie sur aucune. `p=none`
+ Les rapports générés par le biais du DMARC indiqueront les numéros et les sources des messages qui passent ces contrôles, par rapport à ceux qui ne le sont pas. Vous pouvez facilement voir quelle part de votre trafic légitime est ou n'est pas couverte par eux. Vous verrez des signes de transfert, car les messages transférés échoueront au SPF et au DKIM si le contenu est modifié. Vous commencerez également à voir combien de messages frauduleux sont envoyés et d'où ils proviennent.
+ Les objectifs de cette étape sont de savoir quels e-mails seront affectés lorsque vous mettrez en œuvre l'une des deux étapes suivantes, et de faire en sorte que les expéditeurs tiers ou autorisés alignent leurs politiques SPF ou DKIM.
+ Idéal pour les domaines existants.
1. Demandez aux systèmes de messagerie externes de mettre en quarantaine les messages qui ne répondent pas au DMARC (p=quarantine).
+ Lorsque vous pensez que la totalité ou la majeure partie de votre trafic légitime est envoyée par un domaine correspondant au SPF ou au DKIM, et que vous comprenez l'impact de la mise en œuvre du DMARC, vous pouvez mettre en œuvre une politique de quarantaine. Une politique de quarantaine est un enregistrement TXT DMARC dont la politique est définie pour être mise en quarantaine`p=quarantine`. Ce faisant, vous demandez aux destinataires du DMARC de placer les messages de votre domaine qui ne répondent pas au DMARC dans l'équivalent local d'un dossier de spam plutôt que dans les boîtes de réception de vos clients.
+ Idéal pour les domaines de transition qui ont analysé les rapports DMARC au cours de l'étape 1.
1. Demandez aux systèmes de messagerie externes de ne pas accepter les messages qui ne répondent pas au DMARC (p=reject).
+ La mise en œuvre d'une politique de rejet est généralement la dernière étape. Une politique de rejet est un enregistrement TXT DMARC dont la politique est définie pour rejeter`p=reject`. Ce faisant, vous demandez aux destinataires du DMARC de ne pas accepter les messages qui échouent aux vérifications DMARC. Cela signifie qu'ils ne seront même pas placés en quarantaine dans un dossier de spam ou de courrier indésirable, mais qu'ils seront purement et simplement rejetés.
+ Lorsque vous utilisez une politique de rejet, vous saurez exactement quels messages ne sont pas conformes à la politique DMARC, car le rejet entraînera un rebond SMTP. Dans le cas de la quarantaine, les données agrégées fournissent des informations sur les pourcentages d'e-mails réussis ou échoués aux contrôles SPF, DKIM et DMARC.
+ Idéal pour les nouveaux domaines ou les domaines existants qui ont suivi les deux étapes précédentes.
## Conformité à DMARC via SPF
Pour qu'un e-mail soit conforme à DMARC basé sur SPF, les deux conditions suivantes doivent être remplies :
+ Le message doit passer une vérification SPF basée sur un enregistrement SPF (type TXT) valide que vous devez publier dans la configuration DNS de votre domaine MAIL FROM personnalisé.
+ Le domaine indiqué dans l'adresse From de l'en-tête de l'e-mail doit correspondre au domaine, ou à un sous-domaine de, spécifié dans l'adresse MAIL FROM. Pour que le SPF soit aligné sur SES, la politique DMARC du domaine ne doit pas spécifier de politique SPF stricte (aspf=s).
Pour se conformer à ces exigences, complétez les étapes suivantes :
+ Configurez un domaine MAIL FROM personnalisé en exécutant les procédures de [Utilisation d'un domaine MAIL FROM personnalisé](mail-from.md).
+ Assurez-vous que votre domaine d'envoi utilise une stratégie souple pour SPF. Si vous n'avez pas modifié l'alignement des politiques de votre domaine, celui-ci utilise une politique souple par défaut, comme le fait SES.
**Note**
Vous pouvez déterminer l'alignement DMARC de votre domaine pour SPF en tapant la commande suivante sur la ligne de commande et en remplaçant `example.com` par votre domaine :
```
dig TXT _dmarc.example.com
```
Dans le résultat de la commande, sous **Non-authoritative answer**, recherchez un registre qui commence par `v=DMARC1`. Si cet registre inclut la chaîne `aspf=r`, ou si la chaîne `aspf` n'est pas du tout présente, votre domaine utilise l'alignement souple pour SPF. Si le registre inclut la chaîne `aspf=s`, votre domaine utilise l'alignement strict pour SPF. Votre administrateur système doit supprimer cette balise de le registre TXT DMARC dans la configuration DNS de votre domaine.
Vous pouvez également utiliser un outil de recherche DMARC basé sur le Web, tel que le [DMARC Inspector](https://dmarcian.com/dmarc-inspector/) du site Web de dmarcian ou l'[outil de vérification DMARC](https://mxtoolbox.com/dmarc.aspx) du site MxToolBox Web, pour déterminer l'alignement des politiques de votre domaine en matière de SPF.
## Conformité à DMARC via DKIM
Pour qu'un e-mail soit conforme à DMARC basé sur DKIM, les deux conditions suivantes doivent être remplies :
+ Le message doit comporter une signature DKIM valide et réussir le contrôle DKIM.
+ Le domaine spécifié dans la signature DKIM doit être aligné (correspondre) au domaine indiqué dans l'adresse d'origine. Si la politique DMARC du domaine spécifie un alignement strict pour le DKIM, ces domaines doivent correspondre exactement (SES utilise une politique DKIM stricte par défaut).
Pour se conformer à ces exigences, complétez les étapes suivantes :
+ Configurez Easy DKIM en effectuant les procédures d' [Easy DKIM dans Amazon SES](send-email-authentication-dkim-easy.md). Lorsque vous utilisez Easy DKIM, Amazon SES signe automatiquement vos e-mails.
**Note**
Plutôt que d'utiliser Easy DKIM, vous pouvez également [signer manuellement vos messages](send-email-authentication-dkim-manual.md). Cependant, vous devez être prudent si vous choisissez de le faire, car Amazon SES ne valide pas la signature DKIM que vous construisez. Pour cette raison, nous recommandons vivement d'utiliser Easy DKIM.
+ Assurez-vous que le domaine spécifié dans la signature DKIM est aligné sur le domaine indiqué dans l'adresse d'origine. Ou, si vous envoyez depuis un sous-domaine du domaine indiqué dans l'adresse d'origine, assurez-vous que votre politique DMARC est définie de manière à assouplir l'alignement.
**Note**
Vous pouvez déterminer l'alignement DMARC de votre domaine pour DKIM en tapant la commande suivante sur la ligne de commande et en remplaçant `example.com` par votre domaine :
```
dig TXT _dmarc.example.com
```
Dans le résultat de la commande, sous **Non-authoritative answer**, recherchez un registre qui commence par `v=DMARC1`. Si cet registre inclut la chaîne `adkim=r`, ou si la chaîne `adkim` n'est pas du tout présente, votre domaine utilise l'alignement souple pour DKIM. Si le registre inclut la chaîne `adkim=s`, votre domaine utilise l'alignement strict pour DKIM. Votre administrateur système doit supprimer cette balise de le registre TXT DMARC dans la configuration DNS de votre domaine.
Vous pouvez également utiliser un outil de recherche DMARC basé sur le Web, tel que le [DMARC Inspector](https://dmarcian.com/dmarc-inspector/) sur le site Web de dmarcian ou l'[outil de vérification DMARC](https://mxtoolbox.com/dmarc.aspx) sur le site MxToolBox Web, pour déterminer l'alignement des politiques de votre domaine pour le DKIM.
# Utilisation de BIMI dans Amazon SES
BIMI (Brand Indicators for Message Identification, indicateurs de marque pour l'identification des messages) est une spécification de messagerie électronique qui permet aux boîtes de réception d'e-mail d'afficher le logo d'une marque en regard des e-mails authentifiés de la marque dans les clients de messagerie compatibles.
En dépit de son lien direct avec l'authentification, la spécification de messagerie électronique BIMI n'est pas un protocole d'authentification de courrier électronique autonome dans le sens où elle exige que tous vos e-mails soient conformes à l'authentification [DMARC](send-email-authentication-dmarc.md).
Alors que le BIMI nécessite le DMARC, le DMARC exige que votre domaine comporte des enregistrements SPF ou DKIM pour s'aligner, mais il est préférable d'inclure à la fois des enregistrements SPF et DKIM pour plus de sécurité, et parce que certains fournisseurs de services de messagerie () ESPs exigent les deux lorsqu'ils utilisent BIMI. La section suivante passe en revue les étapes d'implémentation de BIMI dans Amazon SES.
## Configuration de BIMI dans SES
Vous pouvez configurer BIMI pour un domaine de messagerie qui vous appartient – dans la terminologie de SES, il s'agit d'un domaine MAIL FROM *personnalisé*. Une fois la configuration effectuée, tous les messages que vous enverrez depuis ce domaine afficheront votre logo BIMI dans les [clients de messagerie qui prennent en charge BIMI](https://bimigroup.org/bimi-infographic/).
Avant de pouvoir afficher un logo BIMI dans vos e-mails, vous devez cependant veiller à mettre en place certains éléments prérequis dans SES – dans la procédure suivante, ces prérequis sont généralisés et font référence à des sections dédiées qui traitent en détail ces sujets. Les étapes propres à BIMI et les éléments nécessaires à sa configuration dans SES sont détaillés ici.
**Pour configurer BIMI sur un domaine MAIL FROM personnalisé**
1. Vous devez disposer d'un domaine MAIL FROM personnalisé et l'avoir configuré dans SES avec des enregistrements SPF (de type TXT) et MX publiés pour ce même domaine. Si vous n'avez pas de domaine MAIL FROM personnalisé ou si vous souhaitez en créer un pour votre logo BIMI, consultez [Utilisation d'un domaine MAIL FROM personnalisé](mail-from.md).
1. Configurez votre domaine avec Easy DKIM. Consultez [Easy DKIM dans Amazon SES](send-email-authentication-dkim-easy.md).
1. Configurez votre domaine avec DMARC en publiant un enregistrement TXT auprès de votre fournisseur DNS avec les spécificités de politique d'application suivantes requises pour le BIMI, comme dans l'un des deux exemples :
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/ses/latest/dg/send-email-authentication-bimi.html)
Dans l'exemple de politique DMARC précédent, comme l'exige BIMI :
+ `example.com` doit être remplacé par votre nom de domaine ou de sous-domaine.
+ La valeur de `p=` peut être :
+ *quarantine* avec une valeur de *pct* définie sur *100*, comme indiqué, ou
+ *reject* comme indiqué.
+ Si vos envois partent d'un sous-domaine, BIMI exige que le domaine parent intègre également cette politique d'application. Les sous-domaines seront soumis à la politique du domaine parent. Toutefois, si vous ajoutez un enregistrement DMARC pour votre sous-domaine en plus de ce que vous avez publié pour le domaine parent, votre sous-domaine doit également intégrer la même politique d'application pour être éligible à BIMI.
+ Si vous n'avez jamais configuré de politique DMARC pour votre domaine, consultez [Mise en conformité au protocole d'authentification DMARC dans Amazon SES](send-email-authentication-dmarc.md) en veillant à n'utiliser que les valeurs de politique DMARC propres à BIMI, comme indiqué.
1. Produisez votre logo BIMI sous forme de `.svg` fichier SVG (Scalable Vector Graphics). Le profil SVG spécifique requis par BIMI est défini comme SVG ( Portable/Secure SVG P/S). Pour que votre logo s'affiche dans le client de messagerie, il doit être parfaitement conforme à ces spécifications. Reportez-vous aux conseils de [BIMI Group](https://bimigroup.org/) concernant la [création de fichiers de logo SVG](https://bimigroup.org/creating-bimi-svg-logo-files/) et les [outils de conversion SVG](https://bimigroup.org/svg-conversion-tools-released/) recommandés.
1. (Facultatif) Procurez-vous un certificat VMC (Verified Mark Certificate). Certains ESPs, tels que Gmail et Apple, exigent qu'une VMC prouve que vous êtes propriétaire de la marque et du contenu de votre logo BIMI. Même s'il ne s'agit pas d'une condition absolue pour implémenter BIMI sur votre domaine, si l'ESP auquel vous envoyez des e-mails applique la conformité VMC, votre logo BIMI ne s'affichera pas dans le client de messagerie. Consultez les informations de référence de BIMI Group pour savoir auprès de quelles [autorités de certification](https://bimigroup.org/verified-mark-certificates-vmc-and-bimi/) vous pouvez vous procurer un VMC pour votre logo.
1. Hébergez le fichier SVG de votre logo BIMI sur un serveur auquel vous avez accès pour le rendre accessible au public via HTTPS. Par exemple, vous pouvez le charger dans un [compartiment Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-buckets-s3.html).
1. Créez et publiez un enregistrement DNS BIMI qui comporte l'URL de votre logo. Lors de la vérification de votre enregistrement DMARC, un [ESP qui prendre en charge BIMI](https://bimigroup.org/bimi-infographic/) recherchera également un enregistrement BIMI contenant l'URL du fichier `.svg` de votre logo, ainsi que l'URL du fichier `.pem` de votre VMC (si vous l'avez configuré). Si les enregistrements correspondent, votre logo BIMI s'affichera.
Configurez votre domaine avec BIMI en publiant un enregistrement TXT auprès de votre fournisseur DNS avec les valeurs suivantes, comme indiqué – l'envoi depuis un domaine est représenté dans le premier exemple ; l'envoi depuis un sous-domaine est représenté dans le deuxième exemple :
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/ses/latest/dg/send-email-authentication-bimi.html)
Dans les exemples d'enregistrements BIMI précédents :
+ La valeur de nom doit textuellement spécifier `default._bimi.` en tant que sous-domaine de `example.com` ou `marketing.example.com` qui doit être remplacé par votre nom de domaine ou de sous-domaine.
+ La valeur de `v=` correspond à la *version* de l'enregistrement BIMI.
+ La valeur de `l=` correspond au *logo* représentant l'URL qui pointe vers le fichier `.svg` de votre image.
+ La valeur de `a=` correspond à l'*autorité* représentant l'URL qui pointe vers le fichier `.pem` de votre certificat.
Vous pouvez valider votre enregistrement BIMI à l'aide d'un outil tel que [BIMI Inspector](https://bimigroup.org/bimi-generator/) de BIMI Group.
La dernière étape de ce processus consiste à avoir un modèle d'envoi régulier ESPs qui supporte le placement du logo BIMI. Votre domaine doit avoir une cadence de livraison régulière et doit avoir une bonne réputation auprès du ESPs destinataire. Le placement du logo BIMI peut prendre du temps à s'afficher ESPs là où vous n'avez pas une réputation établie ou une cadence d'envoi.
Vous trouverez des informations et des ressources supplémentaires sur BIMI via l'organisation [BIMI Group](https://bimigroup.org/).
# Configuration de notifications d'événement pour Amazon SES
Afin d'envoyer des e-mails avec Amazon SES, vous devez mettre en place un système de gestion des retours à l'expéditeur et des réclamations. Amazon SES peut vous informer des événements de retour à l'expéditeur ou de réclamation de trois manières : en envoyant un e-mail de notification, par notification dans une rubrique Amazon SNS ou en publiant des événements d'envoi. Cette section contient des informations sur la configuration d'Amazon SES pour envoyer certains types de notifications par e-mail ou notifier une rubrique Amazon SNS. Pour en savoir plus sur la publication d'événements d'envoi, consultez [Surveillance de l'envoi d'e-mails à l'aide de la publication d'événements Amazon SES](monitor-using-event-publishing.md).
Vous pouvez configurer les notifications à l'aide de la console Amazon SES ou de l'API Amazon SES.
**Topics**
+ [Considérations importantes](#monitor-sending-activity-using-notifications-considerations)
+ [Réception des notifications Amazon SES par e-mail](monitor-sending-activity-using-notifications-email.md)
+ [Réception des notifications Amazon SES à l'aide d'Amazon SNS](monitor-sending-activity-using-notifications-sns.md)
## Considérations importantes
Il y a plusieurs points importants à prendre en compte lorsque vous configurez Amazon SES pour envoyer des notifications :
+ Les notifications par e-mail et Amazon SNS s'appliquent aux identités individuelles (les adresses e-mail ou les domaines vérifiés que vous utilisez pour l'envoi des e-mails). Lorsque vous activez les notifications pour une identité, Amazon SES envoie uniquement des notifications pour les e-mails envoyés depuis cette identité, et uniquement dans la AWS région dans laquelle vous avez configuré les notifications.
+ Vous devez activer une méthode de réception des notifications de retour à l'expéditeur ou de réclamation. Vous pouvez envoyer des notifications à l'adresse de domaine ou e-mail qui a généré le retour à l'expéditeur ou la réclamation, ou à une rubrique Amazon SNS. Vous pouvez également utiliser la [publication d'événements](monitor-using-event-publishing.md) pour envoyer des notifications concernant différents types d'événements (notamment les rebonds, les plaintes, les livraisons, etc.) sur une rubrique Amazon SNS ou un stream Firehose.
Si vous ne configurez pas l'une de ces méthodes de notifications de retour à l'expéditeur ou de réclamation, Amazon SES vous fait suivre automatiquement les notifications de retour à l'expéditeur et de réclamation par e-mail à l'adresse indiquée dans le champ Return-Path (Chemin de retour) (ou le champ Source, si vous n'avez pas spécifié d'adresse Return-Path (Chemin de retour)) du message qui a entraîné l'événement de retour à l'expéditeur ou de réclamation, même si vous avez désactivé le transfert de commentaires par e-mail.
Si vous désactivez le transfert de commentaires par e-mail et que vous activiez la publication d'événements, vous devez également appliquer le jeu de configurations qui contient la règle de publication d'événements à chaque e-mail que vous envoyez. Dans ce cas, si vous n'utilisez pas le jeu de configurations, Amazon SES vous fait suivre automatiquement les notifications de retour à l'expéditeur et de réclamation à l'adresse Return-Path (Chemin de retour) ou Source de l'e-mail qui a entraîné l'événement de retour à l'expéditeur ou de réclamation.
+ Si vous configurez Amazon SES pour envoyer des événements de retour à l'expéditeur et de réclamation à l'aide de plusieurs méthodes (par exemple, en envoyant des notifications par e-mail et en utilisant les événements d'envoi), vous pouvez recevoir plus d'une notification pour le même événement.
# Réception des notifications Amazon SES par e-mail
Amazon SES peut vous envoyer un e-mail lorsque vous recevez des retours à l'expéditeur et des réclamations à l'aide d'un processus nommé *transfert de commentaires par e-mail*.
Afin d'envoyer des e-mails à l'aide d'Amazon SES, vous devez le configurer pour envoyer les notifications de retour à l'expéditeur et de réclamation à l'aide de l'une des méthodes suivantes :
+ En activant le transfert de commentaires par e-mail. La procédure de configuration de ce type de notification est incluse dans cette section.
+ En envoyant des notifications à une rubrique Amazon SNS. Pour de plus amples informations, veuillez consulter [Réception des notifications Amazon SES à l'aide d'Amazon SNS](monitor-sending-activity-using-notifications-sns.md).
+ En publiant des notifications d'événement. Pour de plus amples informations, veuillez consulter [Surveillance de l'envoi d'e-mails à l'aide de la publication d'événements Amazon SES](monitor-using-event-publishing.md).
**Important**
Pour prendre connaissance de plusieurs points importants relatifs aux notifications, consultez [Configuration de notifications d'événement pour Amazon SES](monitor-sending-activity-using-notifications.md).
**Topics**
+ [Activation du transfert de commentaires par e-mail](#monitor-sending-activity-using-notifications-email-enabling)
+ [Désactivation du transfert de commentaires par e-mail](#monitor-sending-activity-using-notifications-email-disabling)
+ [Destination du transfert de commentaires par e-mail](#monitor-sending-activity-using-notifications-email-destination)
## Activation du transfert de commentaires par e-mail
Le transfert de commentaires par e-mail est activé par défaut. Si vous l'avez désactivé précédemment, vous pouvez l'activer à l'aide des procédures de cette section.
**Pour activer le transfert des notifications de retour à l'expéditeur et de réclamation par e-mail à l'aide de la console Amazon SES**
1. Connectez-vous à la console Amazon SES AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Dans le panneau de navigation, sous **Configuration**, choisissez **Verified identities (Identités vérifiées)**.
1. Dans la liste des adresses e-mail ou domaines vérifiés, choisissez l'adresse e-mail ou le domaine pour lequel vous souhaitez configurer des notifications de retour à l'expéditeur et de réclamation.
1. Dans le volet des détails, développez la section **Notifications**.
1. Choisissez **Edit Configuration (Modifier la configuration)**.
1. Sous **Email Feedback Forwarding (Destination du transfert de commentaires par e-mail)**, choisissez **Enabled (Activé)**.
**Note**
Il peut se passer quelques minutes avant que les changements effectués sur cette page prennent effet.
Vous pouvez également activer les notifications de rebond et de réclamation par e-mail à l'aide de l'opération [ SetIdentityFeedbackForwardingEnabled](https://docs.aws.amazon.com/ses/latest/APIReference/API_SetIdentityFeedbackForwardingEnabled.html)API.
## Désactivation du transfert de commentaires par e-mail
Si vous configurez une autre méthode pour fournir les notifications de retour à l'expéditeur et de réclamation, vous pouvez désactiver le transfert de commentaires par e-mail afin de ne pas recevoir plusieurs notifications lorsqu'un événement de retour à l'expéditeur ou de réclamation se produit.
**Pour désactiver le transfert des notifications de retour à l'expéditeur et de réclamation par e-mail à l'aide de la console Amazon SES**
1. Connectez-vous à la console Amazon SES AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Dans le panneau de navigation, sous **Configuration**, choisissez **Verified identities (Identités vérifiées)**.
1. Dans la liste des adresses e-mail ou domaines vérifiés, choisissez l'adresse e-mail ou le domaine pour lequel vous souhaitez configurer des notifications de retour à l'expéditeur et de réclamation.
1. Dans le volet des détails, développez la section **Notifications**.
1. Choisissez **Edit Configuration (Modifier la configuration)**.
1. Sous **Email Feedback Forwarding (Destination du transfert de commentaires par e-mail)**, choisissez **Disabled (Désactivé)**.
**Note**
Vous devez configurer une méthode de réception des notifications de retour à l'expéditeur et de réclamation pour envoyer des e-mails via Amazon SES. [Si vous désactivez le transfert des commentaires par e-mail, vous devez activer les notifications envoyées par Amazon SNS, ou publier les événements de rebond et de plainte sur une rubrique Amazon SNS ou un stream Firehose en utilisant la publication d'événements.](monitor-using-event-publishing.md) Si vous utilisez la publication d'événements, vous devez également appliquer le jeu de configurations qui contient la règle de publication d'événements à chaque e-mail que vous envoyez. Si vous n'avez pas configuré de méthode de réception des notifications de retour à l'expéditeur et de réclamation, Amazon SES vous fait suivre automatiquement les notifications de commentaires par e-mail à l'adresse indiquée dans le champ Return-Path (Chemin de retour) (Chemin de retour) (ou le champ Source si vous n'avez pas spécifié d'adresse Return-Path (Chemin de retour) (Chemin de retour)) du message qui a entraîné l'événement de retour à l'expéditeur ou de réclamation. Dans ce cas, Amazon SES transfère les notifications de retour à l'expéditeur et de réclamation, même si vous avez désactivé les notifications de commentaires par e-mail.
1. Choisissez **Save Config (Enregistrer la configuration)** pour enregistrer votre configuration de notifications.
**Note**
Il peut se passer quelques minutes avant que les changements effectués sur cette page prennent effet.
Vous pouvez également désactiver les notifications de rebond et de plainte par e-mail à l'aide de l'opération [SetIdentityFeedbackForwardingEnabled](https://docs.aws.amazon.com/ses/latest/APIReference/API_SetIdentityFeedbackForwardingEnabled.html)API.
## Destination du transfert de commentaires par e-mail
Lorsque vous recevez des notifications par e-mail, Amazon SES réécrit l'en-tête `From` et vous envoie la notification. L'adresse à laquelle Amazon SES transfère la notification dépend du moyen utilisé pour envoyer le message d'origine.
Si vous avez utilisé l'interface SMTP pour envoyer le message, les notifications sont remises selon les règles suivantes :
+ Si vous avez spécifié un en-tête `Return-Path` dans la section `SMTP DATA`, les notifications sont envoyées à cette adresse.
+ Sinon, les notifications sont envoyées à l'adresse que vous avez spécifiée lorsque vous avez émis la commande MAIL FROM.
Si vous avez utilisé l'opération d'API `SendEmail` pour envoyer le message, les notifications sont remises selon les règles suivantes :
+ Si vous avez spécifié le paramètre `ReturnPath` facultatif dans votre appel à l'API `SendEmail`, les notifications sont envoyées à cette adresse.
+ Sinon, les notifications sont envoyées à l'adresse définie dans le paramètre `Source` obligatoire de `SendEmail`.
Si vous avez utilisé l'opération d'API `SendRawEmail` pour envoyer le message, les notifications sont remises selon les règles suivantes :
+ Si vous avez spécifié un en-tête `Return-Path` dans le message brut, les notifications sont envoyées à cette adresse.
+ Sinon, si vous avez spécifié un paramètre `Source` dans votre appel à l'API `SendRawEmail`, les notifications sont envoyées à cette adresse.
+ Sinon, les notifications sont envoyées à l'adresse indiquée dans l'en-tête `From` du message brut.
**Note**
Lorsque vous spécifiez une adresse `Return-Path` dans un e-mail, vous recevez les notifications à cette adresse. Toutefois, la version du message que le destinataire reçoit contient un en-tête `Return-Path` qui inclut une adresse e-mail anonyme (comme *a0b1c2d3e4f5a6b7-c8d9e0f1-a2b3-c4d5-e6f7-a8b9c0d1e2f3-000000@amazonses.com*). Cette anonymisation se produit, quelle que soit la façon dont vous avez envoyé l'e-mail.
# Réception des notifications Amazon SES à l'aide d'Amazon SNS
Vous pouvez configurer Amazon SES de façon à notifier une rubrique Amazon SNS lorsque vous recevez des retours à l'expéditeur ou des réclamations, ou lorsque les e-mails sont remis. Les notifications Amazon SNS sont au format [JSON (JavaScript Object Notation)](http://www.json.org), ce qui vous permet de les traiter par programmation.
Afin d'envoyer des e-mails à l'aide d'Amazon SES, vous devez le configurer pour envoyer les notifications de retour et de réclamation à l'aide de l'une des méthodes suivantes :
+ En envoyant des notifications à une rubrique Amazon SNS. La procédure de configuration de ce type de notification est incluse dans cette section.
+ En activant le transfert de commentaires par e-mail. Pour plus d'informations, consultez [Réception des notifications Amazon SES par e-mail](monitor-sending-activity-using-notifications-email.md).
+ En publiant des notifications d'événement. Pour plus d'informations, consultez [Surveillance de l'envoi d'e-mails à l'aide de la publication d'événements Amazon SES](monitor-using-event-publishing.md).
**Important**
Consultez [Configuration de notifications d'événement pour Amazon SES](monitor-sending-activity-using-notifications.md) pour obtenir des informations importantes sur les notifications.
**Topics**
+ [Configuration des notifications Amazon SNS pour Amazon SES](configure-sns-notifications.md)
+ [Contenu des notifications Amazon SNS pour Amazon SES](notification-contents.md)
+ [Exemples de notification Amazon SNS pour Amazon SES](notification-examples.md)
# Configuration des notifications Amazon SNS pour Amazon SES
Amazon SES peut vous informer de vos retours à l'expéditeur, réclamations et remises via [Amazon Simple Notification Service (Amazon SNS)](https://aws.amazon.com/sns).
Vous pouvez configurer des notifications dans la console Amazon SES ou à l'aide de l'API Amazon SES.
**Topics**
+ [Conditions préalables](#configure-feedback-notifications-prerequisites)
+ [Configuration de notifications à l'aide de la console Amazon SES](#configure-feedback-notifications-console)
+ [Configuration de notifications à l'aide de l'API Amazon SES](#configure-feedback-notifications-api)
+ [Dépannage des notifications de commentaire](#configure-feedback-notifications-troubleshooting)
## Conditions préalables
Complétez les étapes suivantes avant de configurer des notifications Amazon SNS dans Amazon SES :
1. Créez une rubrique dans Amazon SNS. Pour en savoir plus, consultez [Création d'une rubrique](https://docs.aws.amazon.com/sns/latest/dg/CreateTopic.html) dans le *Manuel du développeur d'Amazon Simple Notification Service*.
**Important**
Lorsque vous créez votre rubrique à l'aide d'Amazon SNS, pour **Type**, choisissez uniquement **Standard**. (SES ne prend pas en charge les rubriques de type FIFO.)
Que vous créiez une nouvelle rubrique SNS ou sélectionniez une rubrique existante, vous devez donner un accès à SES pour publier des notifications sur la rubrique.
Pour donner à Amazon SES la permission de publier des notifications sur la rubrique, sur l'écran **Edit topic (Modifier la rubrique)** de la console SNS, développez **Access policy (Stratégie d'accès)** et dans **JSON editor (Éditeur JSON)**, ajoutez la stratégie de l'autorisation suivante :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "notification-policy",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ses.amazonaws.com"
},
"Action": "sns:Publish",
"Resource": "arn:aws:sns:us-east-1:111122223333:topic_name",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "111122223333",
"AWS:SourceArn": "arn:aws:ses:topic_region:111122223333:identity/identity_name"
}
}
}
]
}
```
------
Dans l'exemple précédent, apportez les modifications suivantes :
+ *topic\$1region*Remplacez-le par la AWS région dans laquelle vous avez créé le sujet SNS.
+ Remplacez *111122223333* par votre ID de compte AWS .
+ *topic\$1name*Remplacez-le par le nom de votre rubrique SNS.
+ Remplacez *identity\$1name* par l'identité vérifiée (adresse e-mail ou domaine) à laquelle vous êtes abonné à la rubrique SNS.
1. Abonnez au moins un point de terminaison pour la rubrique. Par exemple, si vous voulez recevoir des notifications par SMS, abonnez un point de terminaison SMS (c'est-à-dire, un numéro de téléphone portable) à la rubrique. Pour recevoir des notifications par e-mail, abonnez un point de terminaison de messagerie (une adresse e-mail) à la rubrique.
Pour en savoir plus, consultez [Mise en route](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html) dans le *Guide du développeur Amazon Simple Notification Service*.
1. (Facultatif) Si votre rubrique Amazon SNS utilise AWS Key Management Service (AWS KMS) pour le chiffrement côté serveur, vous devez ajouter des autorisations à la politique clé. AWS KMS Vous pouvez ajouter des autorisations en joignant la politique suivante à la politique AWS KMS clé :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSESToUseKMSKey",
"Effect": "Allow",
"Principal": {
"Service": "ses.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*"
}
]
}
```
------
## Configuration de notifications à l'aide de la console Amazon SES
**Pour configurer des notifications à l'aide de la console Amazon SES**
1. Ouvrez la console Amazon SES à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Dans le volet de navigation, sous **Configuration**, choisissez **Identities**.
1. Dans le conteneur **Identities (Identités)**, sélectionnez l'identité vérifiée pour laquelle vous souhaitez recevoir des notifications de commentaires lorsqu'un message envoyé à partir de cette identité entraîne un retour à l'expéditeur, une réclamation ou une remise.
**Important**
Les paramètres de notification de domaine vérifié s'appliquent à tous les e-mails envoyés depuis les adresses de ce domaine, à l'*exception* des adresses qui sont également vérifiées.
1. Dans l'écran de détails de l'identité vérifiée que vous avez sélectionnée, choisissez l'onglet **Notifications (Notifications)** et sélectionnez **Edit (Modifier)** dans le conteneur **Feedback notifications (Notifications de commentaire)**.
1. Développez la zone de liste des rubriques SNS de chaque type de commentaires pour lequel vous souhaitez recevoir des notifications et sélectionnez soit une rubrique SNS dont vous êtes propriétaire, soit **No SNS topic (Aucun sujet SNS)**, ou **SNS topic you don't own (Sujet SNS dont vous n'êtes pas propriétaire)**.
1. Si vous avez choisi **SNS topic you don't own (Sujet SNS dont vous n'êtes pas propriétaire)**, le champ **ARN de rubrique SNS** sera présenté et vous devrez entrer l'ARN de la rubrique SNS partagé avec vous par votre expéditeur délégué. (Seul l'expéditeur délégué recevra ces notifications, car il est propriétaire de la rubrique SNS. Pour en savoir plus sur l'envoi des délégués, consultez [Présentation de l'autorisation d'envoi](sending-authorization-overview.md).)
**Important**
Les rubriques Amazon SNS que vous utilisez pour les notifications de rebond, de réclamation et de livraison doivent être identiques à celles dans Région AWS lesquelles vous utilisez Amazon SES.
De plus, vous devez abonner un ou plusieurs points de terminaison à la rubrique afin de recevoir des notifications. Par exemple, si vous voulez que des notifications soient envoyées à une adresse e-mail, vous devez abonner un point de terminaison de messagerie à la rubrique. Pour en savoir plus, consultez [Mise en route](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html) dans le *Guide du développeur Amazon Simple Notification Service*.
1. (Facultatif) Si vous souhaitez que votre notification de rubrique inclue les en-têtes de l'e-mail d'origine, cochez la case **Include original email headers (Incluez les en-têtes d'e-mail d'origine)** située directement sous le nom de rubrique SNS de chaque type de commentaires. Cette option est disponible uniquement si vous avez affecté une rubrique Amazon SNS au type de notification associé. Pour en savoir plus sur le contenu des en-têtes de l'e-mail d'origine, consultez l'objet `mail` dans [Contenu des notifications ](notification-contents.md).
1. Sélectionnez **Enregistrer les modifications**. L'application des modifications que vous apportez à vos paramètres de notification peut prendre quelques minutes.
1. (Facultatif) Si vous avez choisi les notifications de rubriques Amazon SNS à la fois pour les retours à l'expéditeur et les réclamations, vous pouvez désactiver entièrement les notifications par e-mail afin de ne pas recevoir de doubles notifications par e-mail et par SNS. Pour désactiver les notifications par e-mail pour les retours à l'expéditeur et les réclamations, sous l'onglet **Notifications (Notifications)** sur l'écran de détails de l'identité vérifiée, dans le conteneur **Email Feedback Forwarding (Transfert de commentaires par e-mail)**, choisissez **Edit (Modifier)**, décochez la case **Enabled (Activé)**, et choisissez **Save changes (Enregistrer les modifications)**.
Une fois que vous avez configuré vos paramètres, vous allez commencer à recevoir des notifications de retour à l'expéditeur, de réclamation et/ou de remise, dans vos rubriques Amazon SNS. Ces notifications sont au format JSON ( JavaScriptObject Notation) et suivent la structure décrite dans[Contenu des notifications ](notification-contents.md).
Vous serez facturé selon les tarifs Amazon SNS standard pour les notifications de retour à l'expéditeur, de réclamation et de remise. Pour en savoir plus, consultez la page [Tarification d'Amazon SNS](https://aws.amazon.com/sns/pricing).
**Note**
Si une tentative de publication sur votre rubrique Amazon SNS échoue parce que la rubrique a été supprimée ou que vous Compte AWS n'êtes plus autorisé à publier sur cette rubrique, Amazon SES supprime la configuration de cette rubrique si elle a été configurée pour les rebonds ou les réclamations (et non pour les livraisons. Pour les notifications de livraison, SES ne supprimera pas le paramètre de configuration de la rubrique SNS). De plus, Amazon SES réactive les notifications par e-mail de retour à l'expéditeur et de réclamation pour l'identité, et vous recevez une notification de modification par e-mail. Si plusieurs identités sont configurées pour utiliser la rubrique, la configuration de rubrique de chaque identité est modifiée lorsque l'identité ne parvient pas à publier dans la rubrique.
## Configuration de notifications à l'aide de l'API Amazon SES
Vous pouvez également configurer des notifications de retour à l'expéditeur, de réclamation et de remise à l'aide de l'API Amazon SES. Utilisez les opérations suivantes pour configurer des notifications :
+ [SetIdentityNotificationTopic](https://docs.aws.amazon.com/ses/latest/APIReference/API_SetIdentityNotificationTopic.html)
+ [SetIdentityFeedbackForwardingEnabled](https://docs.aws.amazon.com/ses/latest/APIReference/API_SetIdentityFeedbackForwardingEnabled.html)
+ [GetIdentityNotificationAttributes](https://docs.aws.amazon.com/ses/latest/APIReference/API_GetIdentityNotificationAttributes.html)
+ [SetIdentityHeadersInNotificationsEnabled](https://docs.aws.amazon.com/ses/latest/APIReference/API_SetIdentityHeadersInNotificationsEnabled.html)
Vous pouvez utiliser ces actions d'API pour écrire une application frontale personnalisée pour les notifications. Pour une description complète des actions d'API liées aux notifications, consultez le document [Amazon Simple Email Service API Reference](https://docs.aws.amazon.com/ses/latest/APIReference/).
## Dépannage des notifications de commentaire
**Pas de réception de notifications**
Si vous ne recevez pas de notifications, vérifiez que vous avez abonné un point de terminaison à la rubrique via laquelle les notifications sont envoyées. Lorsque vous abonnez un point de terminaison de messagerie à une rubrique, vous recevez un e-mail vous demandant de confirmer votre abonnement. Vous devez confirmer votre abonnement avant de commencer à recevoir des notifications par e-mail. Pour en savoir plus, consultez [Mise en route](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html) dans le *Guide du développeur Amazon Simple Notification Service*.
**`InvalidParameterValue`Erreur lors du choix d'une rubrique**
Si vous recevez une erreur indiquant qu'une erreur `InvalidParameterValue` s'est produite, vérifiez la rubrique Amazon SNS pour voir si elle est chiffrée via AWS KMS. Si c'est le cas, vous devez modifier la politique de la AWS KMS clé. Consultez [Conditions préalables](#configure-feedback-notifications-prerequisites) pour obtenir un exemple de stratégie.
# Contenu des notifications Amazon SNS pour Amazon SES
Les notifications de rebond, de réclamation et de livraison sont publiées dans les rubriques [Amazon Simple Notification Service (Amazon SNS) au format JSON ( JavaScript Object Notation)](https://aws.amazon.com/sns). L'objet JSON de premier niveau contient une chaîne `notificationType`, un objet `mail` et un objet `bounce`, `complaint` ou `delivery`.
Consultez les sections suivantes Pour en savoir plus sur les différents types d'objets :
+ [Objet JSON de niveau supérieur](#top-level-json-object)
+ [Objet `mail` ](#mail-object)
+ [Objet `bounce` ](#bounce-object)
+ [Objet `complaint` ](#complaint-object)
+ [Objet `delivery`](#delivery-object)
Voici quelques remarques importantes sur le contenu des notifications Amazon SNS pour Amazon SES :
+ Pour un type de notification donné, vous pouvez recevoir une notification Amazon SNS pour plusieurs destinataires, ou vous pouvez recevoir une seule notification Amazon SNS par destinataire. Votre code doit être capable d'analyser la notification Amazon SNS et de gérer les deux cas ; SES ne garantit pas les commandes ou les lots pour les notifications envoyées via Amazon SNS. Cependant, différents types de notification Amazon SNS (par exemple, retours à l'expéditeur et réclamations) ne sont pas combinés dans une même notification.
+ Vous pouvez recevoir plusieurs types de notifications Amazon SNS pour un destinataire. Par exemple, le serveur de messagerie de réception peut accepter l'e-mail (déclenchement d'une notification de message livré), mais après le traitement de l'e-mail, le serveur de messagerie de réception peut déterminer que l'e-mail se traduit de fait par un retour à l'expéditeur (déclenchement d'une notification de retour à l'expéditeur). Cependant, ces notifications sont toujours distinctes, car ce sont des types de notification différents.
+ SES se réserve le droit d'ajouter des champs supplémentaires aux notifications. À ce titre, les applications qui analysent ces notifications doivent être suffisamment flexible pour gérer les champs inconnus.
+ SES remplace les en-têtes du message lors de l'envoi de l'e-mail. Vous trouverez les en-têtes du message d'origine dans les champs `headers` et `commonHeaders` de l'objet `mail`.
## Objet JSON de niveau supérieur
L'objet JSON de niveau supérieur d'une notification SES contient les champs suivants.
| Nom de champ | Description |
| --- | --- |
| notificationType | Chaîne qui contient le type de notification représenté par l'objet JSON. Les valeurs possibles sont `Bounce`, `Complaint` ou `Delivery`. Si vous [configurez la publication d'événements](monitor-sending-using-event-publishing-setup.md), ce champ est nommé `eventType`. |
| mail | Objet JSON qui contient les informations sur l'e-mail d'origine auquel la notification s'applique. Pour plus d'informations, consultez [Objet de l'e-mail](#mail-object). |
| bounce | Ce champ est disponible uniquement si le `notificationType` est `Bounce` et qu'il contient un objet JSON qui inclut les informations sur le retour à l'expéditeur. Pour plus d'informations, consultez [Objet bounce](#bounce-object). |
| complaint | Ce champ est disponible uniquement si le `notificationType` est `Complaint` et qu'il contient un objet JSON qui inclut les informations sur la réclamation. Pour plus d'informations, consultez [Objet de réclamation](#complaint-object). |
| delivery | Ce champ est disponible uniquement si le `notificationType` est `Delivery` et qu'il contient un objet JSON qui inclut les informations sur le message livré. Pour plus d'informations, consultez [Objet Delivery](#delivery-object). |
## Objet de l'e-mail
Chaque notification de retour à l'expéditeur, réclamation ou message délivré contient des informations sur l'e-mail d'origine dans l'objet `mail`. L'objet JSON qui contient les informations sur un objet `mail` comporte les champs suivants.
| Nom de champ | Description |
| --- | --- |
| timestamp | Heure à laquelle le message original a été envoyé (au ISO8601 format). |
| messageId | Identifiant unique attribué par SES au message. SES vous a renvoyé cette valeur lorsque vous avez envoyé le message. Cet identifiant de message a été attribué par SES. Vous trouverez l'ID de message de l'e-mail d'origine dans le champ `headers` de l'objet `mail`. |
| source | Adresse e-mail à partir de laquelle l'e-mail d'origine a été envoyé (adresse MAIL FROM de l'enveloppe). |
| sourceArn | ARN (Amazon Resource Name) de l'identité qui a été utilisée pour envoyer l'e-mail. Dans le cas d'une autorisation d'envoi, `sourceArn` correspond à l'ARN de l'identité dont le propriétaire a autorisé l'utilisation pour l'envoi de l'e-mail par l'expéditeur délégué. Pour en savoir plus sur l'autorisation d'envoi, consultez [Méthodes d'authentification d'e-mailUtilisation de l'autorisation d'envoi](sending-authorization.md). |
| sourceIp | Adresse IP publique d'origine du client qui a effectué la demande d'envoi d'e-mail à SES. |
| sendingAccountId | L' Compte AWS ID du compte qui a été utilisé pour envoyer l'e-mail. Dans le cas de l'autorisation d'envoi, `sendingAccountId` correspond à l'ID de compte de l'expéditeur délégué. |
| callerIdentity | L'identité IAM de l'utilisateur SES qui a envoyé l'e-mail. |
| destination | Liste des adresses e-mail destinataires de l'e-mail original. |
| headersTruncated | Cet objet ne s'affiche que si vous avez configuré les paramètres de notification en vue d'inclure les en-têtes de l'e-mail d'origine. Indique si les en-têtes sont tronqués dans la notification. SES tronque les en-têtes de la notification lorsque les en-têtes du message d'origine ont une taille supérieure ou égale à 10 Ko. Les valeurs possibles sont `true` et `false`. |
| headers | Cet objet ne s'affiche que si vous avez configuré les paramètres de notification en vue d'inclure les en-têtes de l'e-mail d'origine. Liste des en-têtes d'origine de l'e-mail. Chaque en-tête de la liste a un champ `name` et un champ `value`. Tout identifiant de message contenu dans l'`headers`objet provient du message d'origine que vous avez transmis à SES. L'ID du message que SES a ensuite attribué au message se trouve dans le `messageId` champ de l'`mail`objet. |
| commonHeaders | Cet objet ne s'affiche que si vous avez configuré les paramètres de notification en vue d'inclure les en-têtes de l'e-mail d'origine. Comprend des informations sur les en-têtes d'e-mails courants dans l'e-mail d'origine, y compris les champs From (De), To (À) et Subject (Objet). Dans cet objet, chaque en-tête est une clé. Les champs From (De) et To (À) sont représentés par des tableaux qui peuvent contenir plusieurs valeurs. Pour les événements, tout ID de message contenu dans le champ `commonHeaders` correspond à l'ID de message qu'Amazon SES a par la suite affecté au message dans le champ `messageId` de l'objet mail. Les notifications contiendront l'ID de message de l'e-mail d'origine. |
L'exemple suivant est un exemple d'objet `mail` qui contient les en-têtes de l'e-mail d'origine. Lorsque ce type de notification n'est pas configuré pour inclure les en-têtes de l'e-mail d'origine, l'objet `mail` n'inclut pas les champs `headersTruncated`, `headers` et `commonHeaders`.
```
{
"timestamp":"2018-10-08T14:05:45 +0000",
"messageId":"000001378603177f-7a5433e7-8edb-42ae-af10-f0181f34d6ee-000000",
"source":"sender@example.com",
"sourceArn": "arn:aws:ses:us-east-1:888888888888:identity/example.com",
"sourceIp": "127.0.3.0",
"sendingAccountId":"123456789012",
"destination":[
"recipient@example.com"
],
"headersTruncated":false,
"headers":[
{
"name":"From",
"value":"\"Sender Name\" "
},
{
"name":"To",
"value":"\"Recipient Name\" "
},
{
"name":"Message-ID",
"value":"custom-message-ID"
},
{
"name":"Subject",
"value":"Hello"
},
{
"name":"Content-Type",
"value":"text/plain; charset=\"UTF-8\""
},
{
"name":"Content-Transfer-Encoding",
"value":"base64"
},
{
"name":"Date",
"value":"Mon, 08 Oct 2018 14:05:45 +0000"
}
],
"commonHeaders":{
"from":[
"Sender Name "
],
"date":"Mon, 08 Oct 2018 14:05:45 +0000",
"to":[
"Recipient Name "
],
"messageId":" custom-message-ID",
"subject":"Message sent using SES"
}
}
```
## Objet bounce
L'objet JSON qui contient les informations sur les retours à l'expéditeur comporte les champs suivants.
| Nom de champ | Description |
| --- | --- |
| bounceType | Le type de rebond, tel que déterminé par SES. Pour de plus amples informations, veuillez consulter [Types de retour à l'expéditeur](#bounce-types). |
| bounceSubType | Sous-type du rebond, tel que déterminé par SES. Pour de plus amples informations, veuillez consulter [Types de retour à l'expéditeur](#bounce-types). |
| bouncedRecipients | Liste qui contient les informations sur les destinataires de l'e-mail d'origine ayant fait l'objet d'un retour à l'expéditeur. Pour de plus amples informations, veuillez consulter [Destinataires à l'origine d'un retour à l'expéditeur](#bounced-recipients). |
| timestamp | Date et heure auxquelles le rebond a été envoyé (au ISO8601 format). Notez qu'il s'agit de l'heure à laquelle la notification a été envoyée par le fournisseur de services Internet, et non de l'heure à laquelle elle a été reçue par SES. |
| feedbackId | ID unique du retour à l'expéditeur. |
Si SES a pu contacter l'autorité de transfert de messages (MTA) distante, le champ suivant est également présent.
| Nom de champ | Description |
| --- | --- |
| remoteMtaIp | Adresse IP du MTA auquel SES a tenté d'envoyer l'e-mail. |
Si une notification de statut de remise (DSN) a été attachée au retour à l'expéditeur, le champ suivant est également présent.
| Nom de champ | Description |
| --- | --- |
| reportingMTA | Valeur du champ `Reporting-MTA` du DSN. Il s'agit de la valeur de la MTA qui a tenté d'effectuer l'opération de remise, de relais ou de passerelle décrite dans le DSN. |
Voici un exemple d'objet `bounce`.
```
{
"bounceType":"Permanent",
"bounceSubType": "General",
"bouncedRecipients":[
{
"status":"5.0.0",
"action":"failed",
"diagnosticCode":"smtp; 550 user unknown",
"emailAddress":"recipient1@example.com"
},
{
"status":"4.0.0",
"action":"delayed",
"emailAddress":"recipient2@example.com"
}
],
"reportingMTA": "example.com",
"timestamp":"2012-05-25T14:59:38.605Z",
"feedbackId":"000001378603176d-5a4b5ad9-6f30-4198-a8c3-b1eb0c270a1d-000000",
"remoteMtaIp":"127.0.2.0"
}
```
### Destinataires à l'origine d'un retour à l'expéditeur
Une notification de retour à l'expéditeur peut se rapporter à un seul destinataire ou à plusieurs destinataires. Le champ `bouncedRecipients` contient une liste d'objets (un objet par destinataire auquel la notification de retour à l'expéditeur s'applique), ainsi que le champ suivant.
| Nom de champ | Description |
| --- | --- |
| emailAddress | Adresse e-mail du destinataire. Si un DSN est disponible, l'adresse correspond à la valeur du champ `Final-Recipient` du DSN. |
En outre, si un DSN est attaché au retour à l'expéditeur, les champs suivants peuvent également être présents.
| Nom de champ | Description |
| --- | --- |
| action | Valeur du champ `Action` du DSN. Cette valeur indique l'action effectuée par la MTA de suivi comme résultat de sa tentative de remettre le message à ce destinataire. |
| status | Valeur du champ `Status` du DSN. Il s'agit du code de statut indépendant du transport par destinataire qui indique le statut de remise du message. |
| diagnosticCode | Code de statut émis par la MTA de suivi. Il s'agit de la valeur du champ `Diagnostic-Code` du DSN. Ce champ peut être absent du DSN (et donc également absent du JSON). |
Voici un exemple d'objet qui pourrait être dans la liste `bouncedRecipients`.
```
{
"emailAddress": "recipient@example.com",
"action": "failed",
"status": "5.0.0",
"diagnosticCode": "X-Postfix; unknown user"
}
```
### Types de retour à l'expéditeur
L'objet de rebond contient un type de `Undetermined` rebond `Permanent` *(dur)* ou `Transient` *(doux*). Les types de rebond `Permanent` *`Transient`(dur)* *et (doux)* peuvent également contenir l'un des nombreux sous-types de rebond.
Lorsque vous recevez une notification de rebond avec un type de rebond `Transient` *(souple)*, vous pourrez peut-être envoyer un e-mail à ce destinataire à l'avenir si le problème à l'origine du rebond du message est résolu.
Lorsque vous recevez une notification de rebond avec un type de rebond `Permanent` *(dur)*, il est peu probable que vous puissiez envoyer un e-mail à ce destinataire à l'avenir. Pour cette raison, vous devez supprimer immédiatement de vos listes de diffusion le destinataire dont l'adresse a généré le retour à l'expéditeur.
**Note**
Lorsqu'un *soft bounce* (un rebond lié à un problème temporaire, tel que la boîte de réception du destinataire est pleine) se produit, SES tente de redistribuer l'e-mail pendant un certain temps. À la fin de cette période, si SES ne parvient toujours pas à délivrer l'e-mail, il arrête d'essayer.
SES fournit des notifications pour les rebonds durs et pour les rebonds souples qu'il a cessé d'essayer de délivrer. Si vous souhaitez recevoir une notification chaque fois qu'un message d'erreur temporaire se produit, [activez la publication d'événements](monitor-sending-using-event-publishing-setup.md) et configurez-la pour envoyer des notifications lorsque des événements de retard de livraison se produisent.
| bounceType | bounceSubType | Description |
| --- | --- | --- |
| Undetermined | Undetermined | Le fournisseur de messagerie du destinataire a envoyé un message de retour à l'expéditeur. Le message de rebond ne contenait pas suffisamment d'informations pour que SES puisse déterminer la raison du rebond. L'e-mail de retour à l'expéditeur, qui a été envoyé à l'adresse indiquée dans l'en-tête Return-Path (Chemin de retour) de l'e-mail à l'origine du retour à l'expéditeur, peut contenir des informations supplémentaires sur le problème qui a entraîné le retour de l'e-mail à l'expéditeur. |
| Permanent | General | Le fournisseur de messagerie du destinataire a envoyé un message d'erreur définitif. Lorsque vous recevez ce type de notification de retour à l'expéditeur, vous devez aussitôt supprimer l'adresse e-mail du destinataire de votre liste de diffusion. L'envoi de messages à des adresses qui produisent des messages d'erreur définitifs peut avoir un impact négatif sur votre réputation d'expéditeur. Si vous continuez d'envoyer des e-mails à des adresses qui produisent des messages d'erreur définitifs, nous pouvons suspendre votre capacité à envoyer de nouveaux e-mails. Consultez [Utilisation de la liste de suppression au niveau du compte Amazon SES](sending-email-suppression-list.md). |
| Permanent | NoEmail | Il n'a pas été possible de récupérer l'adresse e-mail du destinataire dans le message de retour. |
| Permanent | Suppressed | L'adresse e-mail du destinataire figure sur la liste de suppression de SES car elle a récemment produit des hard bounces. Pour remplacer la liste de suppression globale, consultez [Utilisation de la liste de suppression au niveau du compte Amazon SES](sending-email-suppression-list.md). |
| Permanent | OnAccountSuppressionList | SES a supprimé l'envoi à cette adresse car celle-ci figure sur la liste de [suppression au niveau du compte](sending-email-suppression-list.md). Cela n'est pas pris en compte dans votre métrique de taux de retours à l'expéditeur. |
| Permanent | UnsubscribedRecipient | Ce type de rebond se produit lorsque le contact destinataire s'est désinscrit du sujet et qu'un e-mail lui est envoyé à l'aide [des options de gestion de liste](sending-email-list-management.md#configuring-list-management-list-contacts). SES respecte les préférences de contact et ne tente pas de livrer. De plus, ce rebond n'a aucun impact sur la réputation de l'expéditeur puisque la livraison n'a pas été tentée et que le contact du destinataire n'est pas ajouté à une liste de suppression en raison du rebond. Il est recommandé de vous abonner aux UnsubscribedRecipient événements pour éviter de continuer à envoyer des messages à des destinataires non abonnés. Tenez compte[Utilisation de la gestion des listes](sending-email-list-management.md). La gestion des listes doit être la source de vérité de votre liste d'abonnés. Du point de vue de l'application du SES, si vous continuez à envoyer à des destinataires supprimés ou désabonnés, vous aurez la réputation de ne pas respecter les meilleures pratiques en matière d'envoi d'e-mails. |
| Transient | General | Le fournisseur de messagerie du destinataire a envoyé un message de retour à l'expéditeur général. Il se peut que vous soyez en mesure d'envoyer à l'avenir un message au même destinataire si le problème qui a provoqué le retour du message à l'expéditeur est résolu. Si vous envoyez un e-mail à un destinataire qui possède une règle de réponse automatique active (comme un message « Absent du bureau » message), vous pouvez recevoir ce type de notification. Même si la réponse est de type notification`Bounce`, SES ne prend pas en compte les réponses automatiques lorsqu'il calcule le taux de rebond de votre compte. |
| Transient | MailboxFull | Le fournisseur de messagerie du destinataire a envoyé un message de retour à l'expéditeur, car la boîte de réception du destinataire était pleine. Il se peut que vous puissiez à l'avenir envoyer le message au même destinataire lorsque la boîte de réception ne sera plus pleine. |
| Transient | MessageTooLarge | Le fournisseur de messagerie du destinataire a envoyé un message de retour à l'expéditeur, car le message envoyé était trop volumineux. Vous pouvez réessayer l'envoi à ce destinataire si vous réduisez la taille du message. |
| Transient | ContentRejected | Le fournisseur de messagerie du destinataire a envoyé un message de retour à l'expéditeur, car le message que vous avez envoyé comporte un contenu que le fournisseur n'autorise pas. Vous pouvez réessayer l'envoi du message au destinataire si vous modifiez le contenu du message. |
| Transient | AttachmentRejected | Le fournisseur de messagerie du destinataire a envoyé un message de retour à l'expéditeur, car le message contenait une pièce jointe indésirable. Par exemple, certains fournisseurs de messagerie peuvent rejeter des messages avec des pièces jointes d'un certain type de fichier ou des messages avec pièces jointes très volumineuses. Vous pouvez réessayer l'envoi du message au destinataire si vous supprimez ou modifiez le contenu de la pièce jointe. |
## Objet de réclamation
L'objet JSON qui contient les informations sur les réclamations comporte les champs suivants.
| Nom de champ | Description |
| --- | --- |
| complainedRecipients | Liste contenant des informations sur les destinataires qui sont responsables de la réclamation. Pour plus d'informations, consultez [Destinataires à l'origine d'une réclamation](#complained-recipients). |
| timestamp | Date et heure auxquelles le fournisseur de services Internet a envoyé la notification de réclamation, au format ISO8601. La date et l'heure indiquées dans ce champ peuvent être différentes de la date et de l'heure auxquelles SES a reçu la notification. |
| feedbackId | ID unique associé à la réclamation. |
| complaintSubType | La valeur du champ `complaintSubType` peut être null ou `OnAccountSuppressionList`. Si la valeur est positive`OnAccountSuppressionList`, SES a accepté le message, mais n'a pas tenté de l'envoyer car il figurait sur la liste de [suppression au niveau du compte](sending-email-suppression-list.md). |
De plus, si un rapport de commentaire est attaché à la réclamation, les champs suivants peuvent être présents.
| Nom de champ | Description |
| --- | --- |
| userAgent | Valeur du champ `User-Agent` du rapport de commentaires. Cette valeur indique le nom et la version du système ayant généré le rapport. |
| complaintFeedbackType | Valeur du champ `Feedback-Type` du rapport de commentaires reçu de l'ISP. La valeur contient le type de commentaires. |
| arrivalDate | La valeur du `Received-Date` champ `Arrival-Date` ou du rapport de commentaires (au ISO8601 format). Le champ peut être absent du rapport (et donc également absent du JSON). |
Voici un exemple d'objet `complaint`.
```
{
"userAgent":"ExampleCorp Feedback Loop (V0.01)",
"complainedRecipients":[
{
"emailAddress":"recipient1@example.com"
}
],
"complaintFeedbackType":"abuse",
"arrivalDate":"2009-12-03T04:24:21.000-05:00",
"timestamp":"2012-05-25T14:59:38.623Z",
"feedbackId":"000001378603177f-18c07c78-fa81-4a58-9dd1-fedc3cb8f49a-000000"
}
```
### Destinataires à l'origine d'une réclamation
Le champ `complainedRecipients` contient la liste des destinataires susceptibles d'avoir déposé la réclamation. Vous devez utiliser ces informations pour déterminer quel destinataire a soumis la plainte, puis supprimer immédiatement ce destinataire de vos listes de diffusion.
**Important**
La plupart ISPs suppriment l'adresse e-mail du destinataire qui a soumis la plainte de leur notification de plainte. Pour cette raison, la liste contient les informations sur les destinataires susceptibles d'avoir envoyé la réclamation, en fonction des destinataires du message d'origine et du FAI duquel la réclamation a été reçue. SES effectue une recherche par rapport au message d'origine pour déterminer cette liste de destinataires.
Les objets JSON de cette liste contiennent le champ suivant.
| Nom de champ | Description |
| --- | --- |
| emailAddress | Adresse e-mail du destinataire. |
Voici un exemple d'objet destinataire à l'origine d'une réclamation.
```
{ "emailAddress": "recipient1@example.com" }
```
**Note**
En raison de ce comportement, vous êtes plus à même de savoir quelles adresses e-mail ont porté réclamation contre votre message si vous limitez l'envoi à un message par destinataire (plutôt que d'envoyer un message avec 30 adresses différentes dans la ligne Cci).
#### Types de réclamation
Vous pouvez voir les types de réclamation suivants dans le champ `complaintFeedbackType` tels qu'attribués par l'ISP du rapport, selon le [site web IANA (Internet Assigned Numbers)](http://www.iana.org/assignments/marf-parameters/marf-parameters.xml#marf-parameters-2) :
+ `abuse` – Indique un e-mail indésirable ou autre type d'e-mail malveillant.
+ `auth-failure` – Rapport d'échec d'authentification d'e-mail.
+ `fraud` – Indique certains types de fraude ou d'activité d'hameçonnage.
+ `not-spam` – Indique que l'entité qui fournit le rapport ne considère pas le message en tant que courrier indésirable. Cette option permet de corriger un message qui a été mal balisé ou classé à tort comme courrier indésirable.
+ `other` – Indique tout autre commentaire ne pouvant être classé dans les autres types enregistrés.
+ `virus` – Signale qu'un virus a été détecté dans le message d'origine.
## Objet Delivery
L'objet JSON qui contient les informations sur les messages remis comporte les champs suivants.
| Nom de champ | Description |
| --- | --- |
| timestamp | Heure à laquelle SES a envoyé l'e-mail au serveur de messagerie du destinataire (au ISO8601 format). |
| processingTimeMillis | Le délai en millisecondes entre le moment où SES a accepté la demande de l'expéditeur et la transmission du message au serveur de messagerie du destinataire. |
| recipients | Liste des destinataires prévus de l'e-mail auxquels la notification de remise s'applique. |
| smtpResponse | Le message de réponse SMTP du fournisseur de services Internet distant qui a accepté l'e-mail de SES. Ce message varie selon l'e-mail, le serveur de messagerie de réception et l'ISP de réception. |
| reportingMTA | Le nom d'hôte du serveur de messagerie SES qui a envoyé le message. |
| remoteMtaIp | Adresse IP du MTA auquel SES a envoyé l'e-mail. |
Voici un exemple d'objet `delivery`.
```
{
"timestamp":"2014-05-28T22:41:01.184Z",
"processingTimeMillis":546,
"recipients":["success@simulator.amazonses.com"],
"smtpResponse":"250 ok: Message 64111812 accepted",
"reportingMTA":"a8-70.smtp-out.amazonses.com",
"remoteMtaIp":"127.0.2.0"
}
```
# Exemples de notification Amazon SNS pour Amazon SES
Les sections suivantes fournissent des exemples pour les trois types de notification :
+ Pour des exemples de notification de retour à l'expéditeur, consultez [Exemples de notification de retour à l'expéditeur Amazon SNS](#notification-examples-bounce).
+ Pour des exemples de notification de réclamation, consultez [Exemples de notification de réclamation Amazon SNS](#notification-examples-complaint).
+ Pour des exemples de notification de remise, consultez [Exemple de notification de remise Amazon SNS](#notification-examples-delivery).
## Exemples de notification de retour à l'expéditeur Amazon SNS
Cette section contient des exemples de notification de retour à l'expéditeur avec et sans notification de statut de remise (DSN) fourni par le destinataire de l'e-mail ayant envoyé le commentaire.
### Notification de retour à l'expéditeur avec une DSN
L'exemple suivant illustre une notification de retour à l'expéditeur qui contient une DSN et les en-têtes de l'e-mail d'origine. Lorsque les notifications de retour à l'expéditeur ne sont pas configurées pour inclure les en-têtes de l'e-mail d'origine, l'objet `mail` des notifications n'inclut pas les champs `headersTruncated`, `headers` et `commonHeaders`.
```
{
"notificationType":"Bounce",
"bounce":{
"bounceType":"Permanent",
"reportingMTA":"dns; email.example.com",
"bouncedRecipients":[
{
"emailAddress":"jane@example.com",
"status":"5.1.1",
"action":"failed",
"diagnosticCode":"smtp; 550 5.1.1 ... User"
}
],
"bounceSubType":"General",
"timestamp":"2016-01-27T14:59:38.237Z",
"feedbackId":"00000138111222aa-33322211-cccc-cccc-cccc-ddddaaaa068a-000000",
"remoteMtaIp":"127.0.2.0"
},
"mail":{
"timestamp":"2016-01-27T14:59:38.237Z",
"source":"john@example.com",
"sourceArn": "arn:aws:ses:us-east-1:888888888888:identity/example.com",
"sourceIp": "127.0.3.0",
"sendingAccountId":"123456789012",
"callerIdentity": "IAM_user_or_role_name",
"messageId":"00000138111222aa-33322211-cccc-cccc-cccc-ddddaaaa0680-000000",
"destination":[
"jane@example.com",
"mary@example.com",
"richard@example.com"],
"headersTruncated":false,
"headers":[
{
"name":"From",
"value":"\"John Doe\" "
},
{
"name":"To",
"value":"\"Jane Doe\" , \"Mary Doe\" , \"Richard Doe\" "
},
{
"name":"Message-ID",
"value":"custom-message-ID"
},
{
"name":"Subject",
"value":"Hello"
},
{
"name":"Content-Type",
"value":"text/plain; charset=\"UTF-8\""
},
{
"name":"Content-Transfer-Encoding",
"value":"base64"
},
{
"name":"Date",
"value":"Wed, 27 Jan 2016 14:05:45 +0000"
}
],
"commonHeaders":{
"from":[
"John Doe "
],
"date":"Wed, 27 Jan 2016 14:05:45 +0000",
"to":[
"Jane Doe , Mary Doe , Richard Doe "
],
"messageId":"custom-message-ID",
"subject":"Hello"
}
}
}
```
### Notification de retour à l'expéditeur sans DSN
L'exemple suivant illustre une notification de retour à l'expéditeur qui contient les en-têtes de l'e-mail d'origine, mais pas de DSN. Lorsque les notifications de retour à l'expéditeur ne sont pas configurées pour inclure les en-têtes de l'e-mail d'origine, l'objet `mail` des notifications n'inclut pas les champs `headersTruncated`, `headers` et `commonHeaders`.
```
{
"notificationType":"Bounce",
"bounce":{
"bounceType":"Permanent",
"bounceSubType": "General",
"bouncedRecipients":[
{
"emailAddress":"jane@example.com"
},
{
"emailAddress":"richard@example.com"
}
],
"timestamp":"2016-01-27T14:59:38.237Z",
"feedbackId":"00000137860315fd-869464a4-8680-4114-98d3-716fe35851f9-000000",
"remoteMtaIp":"127.0.2.0"
},
"mail":{
"timestamp":"2016-01-27T14:59:38.237Z",
"messageId":"00000137860315fd-34208509-5b74-41f3-95c5-22c1edc3c924-000000",
"source":"john@example.com",
"sourceArn": "arn:aws:ses:us-east-1:888888888888:identity/example.com",
"sourceIp": "127.0.3.0",
"sendingAccountId":"123456789012",
"callerIdentity": "IAM_user_or_role_name",
"destination":[
"jane@example.com",
"mary@example.com",
"richard@example.com"
],
"headersTruncated":false,
"headers":[
{
"name":"From",
"value":"\"John Doe\" "
},
{
"name":"To",
"value":"\"Jane Doe\" , \"Mary Doe\" , \"Richard Doe\" "
},
{
"name":"Message-ID",
"value":"custom-message-ID"
},
{
"name":"Subject",
"value":"Hello"
},
{
"name":"Content-Type",
"value":"text/plain; charset=\"UTF-8\""
},
{
"name":"Content-Transfer-Encoding",
"value":"base64"
},
{
"name":"Date",
"value":"Wed, 27 Jan 2016 14:05:45 +0000"
}
],
"commonHeaders":{
"from":[
"John Doe "
],
"date":"Wed, 27 Jan 2016 14:05:45 +0000",
"to":[
"Jane Doe , Mary Doe , Richard Doe "
],
"messageId":"custom-message-ID",
"subject":"Hello"
}
}
}
```
## Exemples de notification de réclamation Amazon SNS
Cette section contient des exemples de notification de réclamation avec et sans rapport de commentaire fourni par le destinataire de l'e-mail ayant envoyé le commentaire.
### Notification de réclamation avec un rapport de commentaire
L'exemple suivant illustre une notification de réclamation qui contient un rapport de commentaire et les en-têtes de l'e-mail d'origine. Lorsque les notifications de réclamation ne sont pas configurées pour inclure les en-têtes de l'e-mail d'origine, l'objet `mail` des notifications n'inclut pas les champs `headersTruncated`, `headers` et `commonHeaders`.
```
{
"notificationType":"Complaint",
"complaint":{
"userAgent":"AnyCompany Feedback Loop (V0.01)",
"complainedRecipients":[
{
"emailAddress":"richard@example.com"
}
],
"complaintFeedbackType":"abuse",
"arrivalDate":"2016-01-27T14:59:38.237Z",
"timestamp":"2016-01-27T14:59:38.237Z",
"feedbackId":"000001378603177f-18c07c78-fa81-4a58-9dd1-fedc3cb8f49a-000000"
},
"mail":{
"timestamp":"2016-01-27T14:59:38.237Z",
"messageId":"000001378603177f-7a5433e7-8edb-42ae-af10-f0181f34d6ee-000000",
"source":"john@example.com",
"sourceArn": "arn:aws:ses:us-east-1:888888888888:identity/example.com",
"sourceIp": "127.0.3.0",
"sendingAccountId":"123456789012",
"callerIdentity": "IAM_user_or_role_name",
"destination":[
"jane@example.com",
"mary@example.com",
"richard@example.com"
],
"headersTruncated":false,
"headers":[
{
"name":"From",
"value":"\"John Doe\" "
},
{
"name":"To",
"value":"\"Jane Doe\" , \"Mary Doe\" , \"Richard Doe\" "
},
{
"name":"Message-ID",
"value":"custom-message-ID"
},
{
"name":"Subject",
"value":"Hello"
},
{
"name":"Content-Type",
"value":"text/plain; charset=\"UTF-8\""
},
{
"name":"Content-Transfer-Encoding",
"value":"base64"
},
{
"name":"Date",
"value":"Wed, 27 Jan 2016 14:05:45 +0000"
}
],
"commonHeaders":{
"from":[
"John Doe "
],
"date":"Wed, 27 Jan 2016 14:05:45 +0000",
"to":[
"Jane Doe , Mary Doe , Richard Doe "
],
"messageId":"custom-message-ID",
"subject":"Hello"
}
}
}
```
### Notification de réclamation sans rapport de commentaire
L'exemple suivant illustre une notification de réclamation qui contient les en-têtes de l'e-mail d'origine, mais pas de rapport de commentaire. Lorsque les notifications de réclamation ne sont pas configurées pour inclure les en-têtes de l'e-mail d'origine, l'objet `mail` des notifications n'inclut pas les champs `headersTruncated`, `headers` et `commonHeaders`.
```
{
"notificationType":"Complaint",
"complaint":{
"complainedRecipients":[
{
"emailAddress":"richard@example.com"
}
],
"timestamp":"2016-01-27T14:59:38.237Z",
"feedbackId":"0000013786031775-fea503bc-7497-49e1-881b-a0379bb037d3-000000"
},
"mail":{
"timestamp":"2016-01-27T14:59:38.237Z",
"messageId":"0000013786031775-163e3910-53eb-4c8e-a04a-f29debf88a84-000000",
"source":"john@example.com",
"sourceArn": "arn:aws:ses:us-east-1:888888888888:identity/example.com",
"sourceIp": "127.0.3.0",
"sendingAccountId":"123456789012",
"callerIdentity": "IAM_user_or_role_name",
"destination":[
"jane@example.com",
"mary@example.com",
"richard@example.com"
],
"headersTruncated":false,
"headers":[
{
"name":"From",
"value":"\"John Doe\" "
},
{
"name":"To",
"value":"\"Jane Doe\" , \"Mary Doe\" , \"Richard Doe\" "
},
{
"name":"Message-ID",
"value":"custom-message-ID"
},
{
"name":"Subject",
"value":"Hello"
},
{
"name":"Content-Type",
"value":"text/plain; charset=\"UTF-8\""
},
{
"name":"Content-Transfer-Encoding",
"value":"base64"
},
{
"name":"Date",
"value":"Wed, 27 Jan 2016 14:05:45 +0000"
}
],
"commonHeaders":{
"from":[
"John Doe "
],
"date":"Wed, 27 Jan 2016 14:05:45 +0000",
"to":[
"Jane Doe , Mary Doe , Richard Doe "
],
"messageId":"custom-message-ID",
"subject":"Hello"
}
}
}
```
## Exemple de notification de remise Amazon SNS
L'exemple suivant illustre une notification de remise qui contient les en-têtes de l'e-mail d'origine. Lorsque les notifications de remise ne sont pas configurées pour inclure les en-têtes de l'e-mail d'origine, l'objet `mail` des notifications n'inclut pas les champs `headersTruncated`, `headers` et `commonHeaders`.
```
{
"notificationType":"Delivery",
"mail":{
"timestamp":"2016-01-27T14:59:38.237Z",
"messageId":"0000014644fe5ef6-9a483358-9170-4cb4-a269-f5dcdf415321-000000",
"source":"john@example.com",
"sourceArn": "arn:aws:ses:us-east-1:888888888888:identity/example.com",
"sourceIp": "127.0.3.0",
"sendingAccountId":"123456789012",
"callerIdentity": "IAM_user_or_role_name",
"destination":[
"jane@example.com"
],
"headersTruncated":false,
"headers":[
{
"name":"From",
"value":"\"John Doe\" "
},
{
"name":"To",
"value":"\"Jane Doe\" "
},
{
"name":"Message-ID",
"value":"custom-message-ID"
},
{
"name":"Subject",
"value":"Hello"
},
{
"name":"Content-Type",
"value":"text/plain; charset=\"UTF-8\""
},
{
"name":"Content-Transfer-Encoding",
"value":"base64"
},
{
"name":"Date",
"value":"Wed, 27 Jan 2016 14:58:45 +0000"
}
],
"commonHeaders":{
"from":[
"John Doe "
],
"date":"Wed, 27 Jan 2016 14:58:45 +0000",
"to":[
"Jane Doe "
],
"messageId":"custom-message-ID",
"subject":"Hello"
}
},
"delivery":{
"timestamp":"2016-01-27T14:59:38.237Z",
"recipients":["jane@example.com"],
"processingTimeMillis":546,
"reportingMTA":"a8-70.smtp-out.amazonses.com",
"smtpResponse":"250 ok: Message 64111812 accepted",
"remoteMtaIp":"127.0.2.0"
}
}
```
# Utilisation de l'autorisation d'identité dans Amazon SES
Les stratégies d'autorisation des identités définissent comment les identités individuelles vérifiées peuvent utiliser Amazon SES en spécifiant quelles actions de l'API SES sont autorisées ou refusées pour l'identité et dans quelles conditions.
Grâce à l'utilisation de ces stratégies d'autorisation, vous pouvez garder le contrôle de vos identités en modifiant ou en révoquant les autorisations à tout moment. Vous pouvez même autoriser d'autres utilisateurs à utiliser les identités que vous possédez (domaines ou adresses e-mail) avec leurs propres comptes SES.
**Topics**
+ [Anatomie de la stratégie Amazon SES](policy-anatomy.md)
+ [Création d'une stratégie d'autorisation d'identité dans Amazon SES](identity-authorization-policies-creating.md)
+ [Exemples de politiques d'identité dans Amazon SES](identity-authorization-policy-examples.md)
+ [Gestion de vos stratégies d'autorisation d'identité dans Amazon SES](managing-policies.md)
# Anatomie de la stratégie Amazon SES
Les stratégies respectent une structure spécifique, contiennent des éléments et doivent répondre à certaines exigences.
## Structure d’une politique
Chaque stratégie d'autorisation est un document JSON attaché à une identité. Chaque stratégie comprend les sections suivantes :
+ Les informations à l'échelle de la stratégie en haut du document.
+ Une ou plusieurs instructions individuelles, chacune décrivant un ensemble d'autorisations.
*L'exemple de politique suivant accorde à l'ID de AWS compte *123456789012* les autorisations spécifiées dans la section *Action pour le domaine vérifié exemple.com*.*
------
#### [ JSON ]
****
```
{
"Id":"ExampleAuthorizationPolicy",
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AuthorizeAccount",
"Effect":"Allow",
"Resource":"arn:aws:ses:us-east-1:123456789012:identity/example.com",
"Principal":{
"AWS":[
"123456789012"
]
},
"Action":[
"ses:GetEmailIdentity",
"ses:UpdateEmailIdentityPolicy",
"ses:ListRecommendations",
"ses:CreateEmailIdentityPolicy",
"ses:DeleteEmailIdentity"
]
}
]
}
```
------
Vous pouvez trouver d'autres exemples de stratégie d'autorisation dans la rubrique [Exemples de politique d'identité](identity-authorization-policy-examples.md).
## Éléments de stratégie
Cette section décrit les éléments contenus dans les stratégies d'autorisation d'identité. Nous décrivons dans un premier temps les éléments à l'échelle de la stratégie, puis ceux qui s'appliquent uniquement à l'instruction dans laquelle ils sont inclus. Nous poursuivons avec une présentation sur la façon d'ajouter des conditions à vos instructions.
Pour obtenir des informations spécifiques sur la syntaxe des éléments, consultez [Syntaxe du langage de stratégie IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies-grammar.html) dans le *Guide de l'utilisateur IAM*.
### Informations à l'échelle de la stratégie
Il existe deux éléments à l'échelle de la stratégie : `Id` et `Version`. Le tableau suivant fournit des informations sur ces éléments.
****
| Nom | Description | Obligatoire | Valeurs valides |
| --- | --- | --- | --- |
| `Id` | Identifie la stratégie de façon unique. | Non | Toute chaîne |
| `Version` | Spécifie la version du langage d'accès aux stratégies. | Non | Toute chaîne. À titre de bonne pratique, nous vous recommandons d'inclure ce champ avec la valeur « 2012-10-17 ». |
### Déclarations propres à la stratégie
Les stratégies d'autorisation d'identité nécessitent au moins une instruction. Chaque instruction peut inclure les éléments décrits dans le tableau suivant.
****
| Nom | Description | Obligatoire | Valeurs valides |
| --- | --- | --- | --- |
| `Sid` | Identifie l'instruction de façon unique. | Non | Toute chaîne. |
| `Effect` | Indique le résultat que vous voulez que l'instruction de la stratégie renvoie au moment de l'évaluation. | Oui | « Allow » ou « Deny ». |
| `Resource` | Indique l'identité à laquelle la stratégie s'applique. (Pour [l'autorisation d'envoi](sending-authorization-identity-owner-tasks-policy.md), il s'agit de l'e-mail ou du domaine que le propriétaire de l'identité autorise l'expéditeur délégué à utiliser). | Oui | Amazon Resource Name (ARN) de l'identité. |
| `Principal` | Spécifie Compte AWS l'utilisateur ou le AWS service qui reçoit l'autorisation dans l'instruction. | Oui | Un Compte AWS identifiant, un ARN utilisateur ou un AWS service valide. Compte AWS IDs et l'utilisateur ARNs sont spécifiés à l'aide de `"AWS"` (par exemple, `"AWS": ["123456789012"]` ou`"AWS": ["arn:aws:iam::123456789012:root"]`). AWS les noms de service sont spécifiés à l'aide de `"Service"` (par exemple,`"Service": ["cognito-idp.amazonaws.com"]`). Pour des exemples de format utilisateur ARNs, consultez le [Références générales AWS](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-iam.html). |
| `Action` | Indique l'action à laquelle s'applique l'instruction. | Oui | « ses : BatchGetMetricData », « ses : CancelExportJob », « ses : CreateDeliverabilityTestReport », CreateEmailIdentityPolicy « ses : », CreateExportJob « ses : », DeleteEmailIdentity « ses : », DeleteEmailIdentityPolicy « ses : « ses : GetDomainStatisticsReport «, GetEmailIdentity « ses : « ses : GetEmailIdentityPolicies «, « ses : GetExportJob « ses : ListExportJobs « ses : « ses : ListRecommendations «, « ses : PutEmailIdentityConfigurationSetAttributes « ses : PutEmailIdentityDkimAttributes «, « ses : PutEmailIdentityDkimSigningAttributes «, « ses : PutEmailIdentityFeedbackAttributes « ses : PutEmailIdentityMailFromAttributes «, « ses : TagResource « « ses : UntagResource », « ses : UpdateEmailIdentityPolicy » ([Envoi d'actions d'autorisation](sending-authorization-identity-owner-tasks-policy.md) : SendEmail « ses : », « ses : SendRawEmail «, « ses : SendTemplatedEmail «, « ses : SendBulkTemplatedEmail «) Vous pouvez spécifier une ou plusieurs de ces opérations. |
| `Condition` | Indique les restrictions éventuelles ou des détails sur l'autorisation. | Non | Consultez les informations sur les conditions à la suite de ce tableau. |
### Conditions
Une *condition* est une restriction qui s'applique à l'autorisation contenue dans l'instruction. La partie de l'instruction qui spécifie les conditions peut être la plus détaillée. Une *clé* est une caractéristique spécifique qui constitue la base pour une restriction d'accès (par exemple, la date et l'heure de la demande).
Vous utilisez à la fois les conditions et les clés afin d'exprimer la restriction. Par exemple, si vous voulez empêcher l'expéditeur délégué d'effectuer des demandes à Amazon SES en votre nom après le 30 juillet 2019, vous devez utiliser la condition appelée `DateLessThan`. Vous utilisez la clé appelée `aws:CurrentTime` et la définissez sur la valeur `2019-07-30T00:00:00Z`.
SES implémente uniquement les clés AWS de politique générales suivantes :
+ `aws:CurrentTime`
+ `aws:EpochTime`
+ `aws:SecureTransport`
+ `aws:SourceIp`
+ `aws:SourceVpc`
+ `aws:SourceVpce`
+ `aws:UserAgent`
+ `aws:VpcSourceIp`
Pour en savoir plus sur ces clés, consultez le [guide de l'utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_ElementDescriptions.html#Condition).
## Exigences des stratégies
Les stratégies doivent répondre à toutes les exigences suivantes :
+ Chaque stratégie doit inclure au moins une instruction.
+ Chaque stratégie doit inclure au moins un mandataire valide.
+ Chaque stratégie doit spécifier une ressource, et cette ressource doit être l'ARN de l'identité à laquelle la stratégie est attachée.
+ Les propriétaires d'identité peuvent associer jusqu'à 20 stratégies à chaque identité.
+ La taille d'une stratégie ne doit pas dépasser 4 kilo-octets (Ko).
+ Le nom d'une stratégie ne doit pas dépasser 64 caractères. De plus, il ne peut inclure que des caractères alphanumériques, des tirets et des traits de soulignement.
# Création d'une stratégie d'autorisation d'identité dans Amazon SES
Une stratégie d'autorisation d'identité est composée de déclarations spécifiant quelles actions API sont autorisées ou refusées pour une identité et sous quelles conditions.
Pour autoriser une identité de domaine ou d'adresse e-mail Amazon SES que vous possédez, vous créez une stratégie d'autorisation, puis vous attachez cette politique à l'identité. Une identité peut avoir zéro, une ou plusieurs stratégies. Toutefois, une stratégie ne peut être associée qu'à une seule identité.
Pour obtenir une liste des actions API pouvant être utilisées dans une stratégie d'autorisation d'identité, consultez la ligne *Action* du tableau [Déclarations propres à la stratégie](policy-anatomy.md#identity-authorization-policy-statements).
Vous pouvez créer une stratégie d'autorisation d'identité de différentes manières :
+ **En utilisant le générateur de stratégies** : vous pouvez créer une stratégie simple à l'aide du générateur de stratégies de la console SES. En plus d'autoriser ou de refuser les autorisations sur les actions de l'API SES, vous pouvez limiter les actions avec des conditions. Vous pouvez également utiliser le générateur de stratégies pour créer rapidement la structure de base d'une stratégie, puis la personnaliser ultérieurement en modifiant la stratégie.
+ **En créant une politique personnalisée** : si vous souhaitez inclure des conditions plus avancées ou utiliser un AWS service comme principal, vous pouvez créer une politique personnalisée et l'associer à l'identité à l'aide de la console SES ou de l'API SES.
**Topics**
+ [Utilisation du Générateur de stratégies](using-policy-generator.md)
+ [Création d'une stratégie personnalisée](creating-custom-policy.md)
# Utilisation du Générateur de stratégies
Vous pouvez utiliser le générateur de politique pour créer une politique d'autorisation simple en suivant la procédure ci-dessous.
**Pour créer une stratégie à l'aide du Générateur de stratégies**
1. Connectez-vous à la console Amazon SES AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Dans le volet de navigation, sous **Configuration**, choisissez **Identities**.
1. Dans le conteneur **Identités** de l'écran **Identités**, sélectionnez l'identité vérifiée pour laquelle vous souhaitez créer une politique d'autorisation.
1. Dans l'écran des détails de l'identité vérifiée que vous avez sélectionnée à l'étape précédente, choisissez l'onglet **Authorization (Autorisation)**.
1. Dans le panneau **Authorization policies** (Stratégies d'autorisation), choisissez **Create policy** (Créer une stratégie), puis sélectionnez **Use policy generator** (Utiliser le générateur de stratégie) depuis le menu déroulant.
1. Dans le panneau **Create statement (Créer une instruction)**, choisissez **Allow (Autoriser)** dans le champ **Effect (Effet)**. [Si vous voulez créer une stratégie pour restreindre cette identité, choisissez plutôt **Deny** (Refuser)].
1. **Dans le champ **Principaux**, entrez l'*Compte AWS ID*, l'*ARN de l'utilisateur IAM* ou le AWS service pour recevoir les autorisations que vous souhaitez autoriser pour cette identité, puis choisissez Ajouter.** (Si vous souhaitez en autoriser plus d'un, répétez cette étape pour chacun d'eux).
1. Dans le champ **Actions**, cochez la case de chaque action que vous souhaitez autoriser pour vos principaux.
1. (Facultatif) Développez **Specify conditions** (Spécifier les conditions) si vous souhaitez ajouter une instruction qualificative à l'autorisation.
1. Sélectionnez un opérateur dans la liste déroulante **Operator (Opérateur)**.
1. Sélectionnez un type dans la liste déroulante **Key (Clé)**.
1. En fonction du type de clé que vous avez sélectionné, saisissez sa valeur dans le champ **Value (Valeur)**. (Si vous souhaitez ajouter d'autres conditions, choisissez **Add new condition (Ajouter une nouvelle condition)** et répétez cette étape pour chaque condition supplémentaire.)
1. Choisissez **Save statement (Enregistrer l'instruction)**.
1. (Facultatif) Développez **Create another statement (Créer une autre instruction)** si vous souhaitez ajouter d'autres instructions à votre politique et répétez les étapes 6 à 10.
1. Choisissez **Next (Suivant)** et sur l'écran **Customize policy (Personnaliser la politique)**, le conteneur **Edit policy details (Modifier les détails de la politique)** contient des champs où vous pouvez modifier ou personnaliser le **Name (Nom)** de la politique et le **Policy document (Document de la politique)** proprement dit.
1. Choisissez **Next** (Suivant) et sur l'écran **Review and apply** (Vérifier et appliquer), le conteneur **Overview** (Présentation) affiche l'identité vérifiée que vous autorisez ainsi que le nom de cette stratégie. Dans le panneau **Policy document (Document de politique)**, vous trouverez la politique que vous venez de rédiger ainsi que toutes les conditions que vous avez ajoutées ; vérifiez la politique et si elle semble correcte, choisissez **Apply policy (Appliquer la stratégie)**. (Si vous avez besoin de modifier ou corriger quelque chose, choisissez **Previous (Précédent)** et travaillez dans le conteneur **Edit policy details (Modification des détails de la politique)**.)
# Création d'une stratégie personnalisée
Si vous souhaitez créer une stratégie personnalisée et l'attacher à une identité, voici les possibilités qui s'offrent à vous :
+ **Utilisation de l'API Amazon SES** – Créez une stratégie dans un éditeur de texte, puis attachez-la à l'identité à l'aide de l'API `PutIdentityPolicy` décrite dans le document [Référence d'API Amazon Simple Email Service](https://docs.aws.amazon.com/ses/latest/APIReference/).
+ **Utilisation de la console Amazon SES** – Créez une stratégie dans un éditeur de texte et attachez-la à une identité en la collant dans l'éditeur de stratégie personnalisée de la console Amazon SES. La procédure suivante décrit cette méthode.
**Pour créer une stratégie personnalisée à l'aide de l'éditeur de stratégie personnalisée**
1. Connectez-vous à la console Amazon SES AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Dans le volet de navigation, sous **Configuration**, choisissez **Identities**.
1. Dans le conteneur **Identités** de l'écran **Identités**, sélectionnez l'identité vérifiée pour laquelle vous souhaitez créer une politique d'autorisation.
1. Dans l'écran des détails de l'identité vérifiée que vous avez sélectionnée à l'étape précédente, choisissez l'onglet **Authorization (Autorisation)**.
1. Dans le panneau **Authorization policies** (Stratégies d'autorisation), choisissez **Create policy** (Créer une stratégie), puis sélectionnez **Create custom policy** (Créer une stratégie personnalisée) depuis le menu déroulant.
1. Dans le volet **Policy document** (Document de la stratégie), saisissez ou collez le texte de votre stratégie au format JSON. Vous pouvez également utiliser le générateur de stratégies pour créer rapidement la structure de base d'une stratégie, puis la personnaliser ici.
1. Choisissez **Apply Policy (Appliquer la stratégie)**. (Si vous avez besoin de modifier votre politique personnalisée, il suffit de cocher sa case à cocher sous l'onglet **Authorization (Autorisation)**, choisir **Edit (Modifier)**, et effectuer vos modifications dans le panneau **Document de politique** pour finir par **Save changes (Enregistrer les modifications)**).
# Exemples de politiques d'identité dans Amazon SES
L'autorisation de l'identité vous permet de spécifier les conditions précises dans lesquelles vous autorisez ou refusez les actions de l'API pour une identité.
**Topics**
+ [Spécifier le principal](#identity-authorization-policy-example-delegate-user)
+ [Restriction de l'action](#sending-authorization-policy-example-restricting-action)
+ [Utilisation de plusieurs instructions](#identity-authorization-policy-example-multiple-statements)
## Spécifier le principal
Le *principal*, qui est l'entité à laquelle vous accordez l'autorisation Compte AWS, peut être un utilisateur Gestion des identités et des accès AWS (IAM) ou un AWS service appartenant au même compte.
*L'exemple suivant montre une politique simple qui permet à l' AWS ID *123456789012* de contrôler l'identité vérifiée *exemple.com*, qui appartient également à 123456789012. Compte AWS *
------
#### [ JSON ]
****
```
{
"Id":"SampleAuthorizationPolicy",
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AuthorizeMarketer",
"Effect":"Allow",
"Resource":"arn:aws:ses:us-east-1:123456789012:identity/example.com",
"Principal":{
"AWS":[
"123456789012"
]
},
"Action":[
"ses:DeleteEmailIdentity",
"ses:PutEmailIdentityDkimSigningAttributes"
]
}
]
}
```
------
L'exemple de stratégie suivant accorde des autorisations à deux utilisateurs pour contrôler l'identité vérifiée *example.com*. Les utilisateurs sont spécifiés par leur Amazon Resource Name (ARN).
------
#### [ JSON ]
****
```
{
"Id":"ExampleAuthorizationPolicy",
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AuthorizeIAMUser",
"Effect":"Allow",
"Resource":"arn:aws:ses:us-east-1:123456789012:identity/example.com",
"Principal":{
"AWS":[
"arn:aws:iam::123456789012:user/John",
"arn:aws:iam::123456789012:user/Jane"
]
},
"Action":[
"ses:DeleteEmailIdentity",
"ses:PutEmailIdentityDkimSigningAttributes"
]
}
]
}
```
------
## Restriction de l'action
Il existe plusieurs actions qui peuvent être spécifiées dans une stratégie d'autorisation d'identité en fonction du niveau de contrôle que vous souhaitez autoriser :
```
1. "BatchGetMetricData",
2. "ListRecommendations",
3. "CreateDeliverabilityTestReport",
4. "CreateEmailIdentityPolicy",
5. "DeleteEmailIdentity",
6. "DeleteEmailIdentityPolicy",
7. "GetDomainStatisticsReport",
8. "GetEmailIdentity",
9. "GetEmailIdentityPolicies",
10. "PutEmailIdentityConfigurationSetAttributes",
11. "PutEmailIdentityDkimAttributes",
12. "PutEmailIdentityDkimSigningAttributes",
13. "PutEmailIdentityFeedbackAttributes",
14. "PutEmailIdentityMailFromAttributes",
15. "TagResource",
16. "UntagResource",
17. "UpdateEmailIdentityPolicy"
```
Les stratégies d'autorisation d'identité vous permettent également de restreindre le principal à une seule de ces actions.
------
#### [ JSON ]
****
```
{
"Id": "ExamplePolicy",
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ControlAction",
"Effect": "Allow",
"Resource": "arn:aws:ses:us-east-1:123456789012:identity/example.com",
"Principal": {
"AWS": [
"123456789012"
]
},
"Action": [
"ses:PutEmailIdentityMailFromAttributes"
]
}
]
}
```
------
## Utilisation de plusieurs instructions
Votre stratégie d'autorisation d'identité peut inclure plusieurs instructions. L'exemple de stratégie suivant comporte deux instructions. La première déclaration interdit à deux utilisateurs d'accéder à `getemailidentity` à partir de *sender@example.com* au sein du même compte `123456789012`. La deuxième déclaration refuse l'accès à `UpdateEmailIdentityPolicy` au principal, *Jack*, dans le même compte `123456789012`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"DenyGet",
"Effect":"Deny",
"Resource":"arn:aws:ses:us-east-1:123456789012:identity/sender@example.com",
"Principal":{
"AWS":[
"arn:aws:iam::123456789012:user/John",
"arn:aws:iam::123456789012:user/Jane"
]
},
"Action":[
"ses:GetEmailIdentity"
]
},
{
"Sid":"DenyUpdate",
"Effect":"Deny",
"Resource":"arn:aws:ses:us-east-1:123456789012:identity/sender@example.com",
"Principal":{
"AWS":"arn:aws:iam::123456789012:user/Jack"
},
"Action":[
"ses:UpdateEmailIdentityPolicy"
]
}
]
}
```
------
# Gestion de vos stratégies d'autorisation d'identité dans Amazon SES
En plus de créer des stratégies et de les attacher à des identités, vous pouvez modifier, supprimer, répertorier et récupérer les stratégies d'une identité, comme indiqué dans les sections suivantes.
## Gestion des stratégies à l'aide de la console Amazon SES
La gestion des politiques Amazon SES implique d'afficher, de modifier ou de supprimer une politique attachée à une identité à l'aide de la console Amazon SES.
**Pour gérer les politiques à l'aide de la console Amazon SES**
1. Connectez-vous à la console Amazon SES AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Dans le panneau de navigation, sous Configuration, choisissez **Verified identities (Identités vérifiées)**.
1. Dans la liste des identités, choisissez l'identité que vous souhaitez gérer.
1. Sur la page de détails de l'identité, accédez à l'onglet **Authorization (Autorisation)**. Vous trouverez ici une liste de toutes les stratégies attachées à cette identité.
1. Sélectionnez la politique que vous souhaitez gérer en cochant sa case à cocher.
1. En fonction de la tâche de gestion souhaitée, choisissez le bouton correspondant comme suit :
1. Pour afficher la politique, choisissez **View policy (Afficher la politique)**. Si vous avez besoin d'une copie de ce document, cliquez sur le bouton **Copy** (Copier) et il sera copié dans votre presse-papiers.
1. Pour modifier la politique, choisissez **Edit (Modifier)**. Dans le panneau **Policy document (Document de politique)**, modifiez la politique, puis choisissez **Save changes (Enregistrer les modifications)**.
**Note**
Pour révoquer des autorisations, vous pouvez soit modifier une stratégie, soit la supprimer.
1. Pour supprimer la politique, choisissez **Delete (Supprimer)**.
**Important**
La suppression d'une stratégie est permanente. Avant de supprimer une stratégie, nous vous recommandons de la sauvegarder en la copiant-collant dans un fichier texte.
## Gestion des stratégies à l'aide de l'API Amazon SES
La gestion des politiques Amazon SES implique d'afficher, de modifier ou de supprimer une politique attachée à une identité à l'aide de l'API Amazon SES.
**Pour répertorier et afficher des stratégies à l'aide de l'API Amazon SES**
+ Vous pouvez répertorier les politiques associées à une identité à l'aide de l'[opération ListIdentityPolicies d'API](https://docs.aws.amazon.com/ses/latest/APIReference/API_ListIdentityPolicies.html). Vous pouvez également récupérer les politiques elles-mêmes à l'aide de l'[opération GetIdentityPolicies API](https://docs.aws.amazon.com/ses/latest/APIReference/API_GetIdentityPolicies.html).
**Pour modifier une politique à l'aide de l'API Amazon SES**
+ Vous pouvez modifier une politique attachée à une identité à l'aide de l'[opération PutIdentityPolicy d'API](https://docs.aws.amazon.com/ses/latest/APIReference/API_PutIdentityPolicy.html).
**Pour supprimer une politique à l'aide de l'API Amazon SES**
+ Vous pouvez supprimer une politique attachée à une identité à l'aide de l'[opération DeleteIdentityPolicy API](https://docs.aws.amazon.com/ses/latest/APIReference/API_DeleteIdentityPolicy.html).
# Utilisation de l'autorisation d'envoi avec Amazon SES
Vous pouvez configurer Amazon SES pour autoriser d'autres utilisateurs à envoyer des e-mails à partir des identités que vous possédez (domaines ou adresses e-mail) en utilisant leurs propres comptes Amazon SES. Grâce à la fonction d'*autorisation d'envoi*, vous pouvez garder le contrôle de vos identités pour pouvoir modifier ou révoquer les autorisations à tout moment. Par exemple, si vous êtes propriétaire d'une entreprise, vous pouvez utiliser l'autorisation d'envoi pour permettre à un tiers (une société de marketing par e-mail, par exemple) d'envoyer des e-mails à partir d'un domaine que vous possédez.
Ce chapitre couvre les spécificités de l'autorisation d'envoi qui remplace l'ancienne fonction de notifications inter-comptes. Vous devez d'abord comprendre les bases de l'autorisation basée sur l'identité à l'aide de stratégies d'autorisation, comme expliqué dans le document [Utilisation de l'autorisation d'identité dans Amazon SES](identity-authorization-policies.md), qui couvre des sujets importants tels que l'anatomie d'une stratégie d'autorisation et la façon de gérer vos stratégies.
## Prise en charge de l'héritage des notifications entre comptes
Les notifications de commentaires pour les retours à l'expéditeur, les réclamations et les remises associées aux e-mails envoyés par un expéditeur délégué qui a été autorisé par un propriétaire d'identité à envoyer à partir d'une de ses identités vérifiées, ont traditionnellement été configurées à l'aide de notifications entre comptes où l'expéditeur délégué associerait une rubrique avec une identité dont il n’est pas propriétaire (c'est-à-dire le compte croisé). Toutefois, les notifications entre comptes ont été remplacées par l'utilisation de jeux de configuration et d'identités vérifiées, combinée à l'envoi délégué pour lequel l'expéditeur délégué a été autorisé par le propriétaire de l'identité à utiliser l'une de ses identités vérifiées pour envoyer des e-mails. Cette nouvelle méthode donne la flexibilité nécessaire pour configurer les notifications de retour à l'expéditeur, de réclamation, de remise et d'autres événements par les deux constructions suivantes selon que vous êtes l'expéditeur délégué ou le propriétaire de l'identité vérifiée :
+ **Jeux de configurations** – L'expéditeur délégué peut configurer la publication d'événements dans son propre jeu de configurations qu'il peut spécifier lors de l'envoi d'un e-mail à partir d'une identité vérifiée dont il n'est pas propriétaire, mais qu'il a été autorisé à envoyer par le propriétaire de l'identité via une politique d'autorisation. La publication d'événements permet de publier des notifications de rebond, de réclamation, de livraison et autres sur Amazon CloudWatch, Amazon Data Firehose, Amazon Pinpoint et Amazon SNS. Consultez [Créer des destination d'évenement](event-destinations-manage.md).
+ **Identités vérifiées** – Outre que le propriétaire de l'identité autorise l'expéditeur délégué à utiliser l'une de ses identités vérifiées pour envoyer des e-mails, il peut également, à la demande de l'expéditeur délégué, configurer des notifications de commentaires sur l'identité partagée pour utiliser les rubriques SNS appartenant à l'expéditeur délégué. Seul l'expéditeur délégué recevra ces notifications, car il est propriétaire de la rubrique SNS. Voir l'étape 14 pour savoir comment [configurer une « rubrique SNS que vous ne possédez pas »](sending-authorization-identity-owner-tasks-policy.md#configure-sns-topic-you-dont-own) dans les procédures de politique d'autorisation.
**Note**
Pour des raisons de compatibilité, les notifications entre comptes sont prises en charge pour les notifications entre comptes héritées actuellement utilisées dans votre compte. Cette prise en charge se limite à la possibilité de modifier et d'utiliser tous les comptes croisés que vous avez créés dans la console classique Amazon SES. Toutefois, vous ne pouvez plus créer de *nouvelles* notifications entre comptes. Pour en créer de nouvelles dans la nouvelle console Amazon SES, utilisez les nouvelles méthodes d'envoi délégué avec des jeux de configurations utilisant [publication d'événement](event-destinations-manage.md), ou avec des identités vérifiées [configurées avec vos propres rubriques SNS](sending-authorization-identity-owner-tasks-policy.md#configure-sns-topic-you-dont-own).
**Topics**
+ [Prise en charge de l'héritage des notifications entre comptes](#sending-authorization-cross-account-sunsetting)
+ [Présentation de l'autorisation d'envoi Amazon SES](sending-authorization-overview.md)
+ [Tâches de propriétaire d'identité pour l'autorisation d'envoi Amazon SES](sending-authorization-identity-owner-tasks.md)
+ [Tâches d'expéditeur délégué pour l'autorisation d'envoi Amazon SES](sending-authorization-delegate-sender-tasks.md)
# Présentation de l'autorisation d'envoi Amazon SES
Cette rubrique offre une présentation du processus d'autorisation d'envoi et explique comment les fonctions d'envoi d'e-mails d'Amazon SES, telles que les quotas d'envoi et les notifications, fonctionnent avec l'autorisation d'envoi.
Cette section utilise les termes suivants :
+ **Identité** – Adresse e-mail ou domaine dont se servent les utilisateurs Amazon SES pour envoyer un e-mail.
+ **Propriétaire d'identité** – Utilisateur Amazon SES dont la propriété d'une adresse e-mail ou d'un domaine a été vérifiée selon les procédures décrites dans [Identités vérifiées](verify-addresses-and-domains.md).
+ **Expéditeur délégué** : AWS compte, utilisateur Gestion des identités et des accès AWS (IAM) ou AWS service autorisé par le biais d'une politique d'autorisation à envoyer des e-mails au nom du propriétaire de l'identité.
+ **Stratégie d'autorisation d'envoi** – Document que vous attachez à une identité pour spécifier les personnes habilitées à effectuer des envois pour cette identité et sous quelles conditions.
+ **Amazon Resource Name (ARN)** : méthode standardisée permettant d'identifier de manière unique une AWS ressource dans tous les AWS services. Pour l'autorisation d'envoi, la ressource est l'identité que le propriétaire de l'identité veut que l'expéditeur délégué utilise. Voici un exemple d'ARN : *arn:aws:ses:us-east-1:123456789012:identity/example.com*.
## Processus d'autorisation d'envoi
L'autorisation d'envoi repose sur des stratégies d'autorisation d'envoi. Si vous souhaitez permettre à un expéditeur délégué d'effectuer un envoi en votre nom, vous devez créer une stratégie d'autorisation d'envoi et l'associer à votre identité à l'aide de la console Amazon SES ou de l'API Amazon SES. Lorsque l'expéditeur délégué tente d'envoyer un e-mail via Amazon SES en votre nom, il transmet l'ARN de votre identité dans la demande ou dans l'en-tête de l'e-mail.
Lorsqu'Amazon SES reçoit la demande d'envoi de l'e-mail et qu'une stratégie existe pour votre identité, cette dernière est vérifiée pour déterminer si vous avez autorisé l'expéditeur délégué à effectuer un envoi au nom de l'identité. Si l'expéditeur délégué est autorisé, Amazon SES accepte l'e-mail ; dans le cas contraire, Amazon SES renvoie un message d'erreur.
Le schéma suivant illustre la relation globale entre les concepts d'autorisation d'envoi :
![\[Présentation de l'autorisation d'envoi\]](http://docs.aws.amazon.com/fr_fr/ses/latest/dg/images/sending_authorization_overview.png)
Le processus d'autorisation d'envoi se compose des trois étapes suivantes :
1. Le propriétaire d'identité sélectionne une identité vérifiée que l'expéditeur délégué doit utiliser. (Si vous n'avez pas vérifié d'identité, consultez [Identités vérifiées](verify-addresses-and-domains.md).)
**Note**
Aucun [jeu de configurations par défaut](managing-configuration-sets.md#default-config-sets) ne doit être affecté à l'identité vérifiée que vous choisissez pour votre expéditeur délégué.
1. L'expéditeur délégué indique au propriétaire de l'identité l'ID de AWS compte ou l'ARN de l'utilisateur IAM qu'il souhaite utiliser pour l'envoi.
1. Si le propriétaire de l'identité accepte d'autoriser l'expéditeur délégué à effectuer des envois à partir de l'un des comptes du propriétaire, celui-ci crée une politique d'autorisation d'envoi et l'attache à l'identité choisie en utilisant la console Amazon SES ou l'API Amazon SES.
1. Le propriétaire de l'identité donne à l'expéditeur délégué l'ARN de l'identité autorisée afin que l'expéditeur délégué puisse fournir l'ARN à Amazon SES au moment de l'envoi de l'e-mail.
1. L'expéditeur délégué peut configurer des notifications de retour à l'expéditeur et de réclamation via la [publication d'événement](monitor-using-event-publishing.md) activée dans un jeu de configurations spécifié lors de l'envoi délégué. Le propriétaire de l'identité peut également configurer des notifications de commentaires par e-mail pour les événements de retour à l'expéditeur et de réclamation à envoyer aux rubriques Amazon SNS de l'expéditeur délégué.
**Note**
Si le propriétaire de l'identité désactive l'envoi de notifications d'événements, l'expéditeur délégué doit configurer la publication d'événements pour publier les événements de rebond et de plainte sur une rubrique Amazon SNS ou un stream Firehose. L'expéditeur doit également appliquer le jeu de configurations qui contient la règle de publication d'événements à chaque e-mail qu'il envoie. Si ni le propriétaire d'identité ni l'expéditeur délégué ne configure une méthode d'envoi de notifications d'événements de retour à l'expéditeur et de réclamation, ou si l'expéditeur n'applique pas le jeu de configurations qui utilise la règle de publication d'événements, Amazon SES envoie automatiquement les notifications d'événements par e-mail à l'adresse indiquée dans le champ Return-Path (Chemin de retour) de l'e-mail (ou à l'adresse du champ Source si vous n'avez pas spécifié d'adresse Return-Path (Chemin de retour)), même si le propriétaire d'identité a désactivé le transfert de commentaires par e-mail.
1. L'expéditeur délégué tente d'envoyer un e-mail via Amazon SES au nom du propriétaire d'identité en transmettant l'ARN de l'identité de son propriétaire dans la demande ou dans l'en-tête de l'e-mail. L'expéditeur délégué peut envoyer l'e-mail à partir de l'interface SMTP Amazon SES ou de l'API Amazon SES. À réception de la demande, Amazon SES examine les stratégies éventuellement attachées à l'identité et accepte l'e-mail si l'expéditeur délégué est autorisé à utiliser les adresses d'expédition et de chemin de retour spécifiées ; sinon, Amazon SES renvoie une erreur et n'accepte pas le message.
**Important**
Le AWS compte de l'expéditeur délégué doit être supprimé du sandbox avant de pouvoir être utilisé pour envoyer des e-mails à des adresses non vérifiées.
1. Si le propriétaire d'identité doit annuler l'autorisation accordée à l'expéditeur délégué, il modifie simplement la stratégie d'autorisation d'envoi ou la supprime entièrement. Le propriétaire d'identité peut effectuer l'une ou l'autre de ces actions à l'aide de la console Amazon SES ou de l'API Amazon SES.
Pour en savoir plus sur la façon dont le propriétaire d'identité ou l'expéditeur délégué effectue ces tâches, consultez respectivement [Tâches de propriétaire d'identité](sending-authorization-identity-owner-tasks.md) ou [Tâches d'expéditeur délégué](sending-authorization-delegate-sender-tasks.md).
## Attribution des fonctions d'envoi d'e-mail
Il est important de comprendre le rôle de l'expéditeur délégué et du propriétaire d'identité par rapport aux fonctions d'envoi de courrier électronique Amazon SES, telles que le quota d'envoi quotidien, les retours à l'expéditeur et les réclamations, la signature DKIM, le transfert de commentaires, etc. L'attribution est la suivante :
+ **Quotas d'envoi** – Les e-mails envoyés à partir d'identités de propriétaire d'identité sont comptabilisés par rapport au quota de l'expéditeur délégué.
+ **Retours à l'expéditeur et réclamations** – Les événements de retour à l'expéditeur et de réclamation sont enregistrés par rapport au compte Amazon SES de l'expéditeur délégué et peuvent donc influer sur la réputation de l'expéditeur délégué.
+ **Signature DKIM** – Si le propriétaire d'identité a activé la signature Easy DKIM pour une identité, tous les e-mails envoyés à partir de cette identité sont signés par DKIM, y compris ceux envoyés par l'expéditeur délégué. Le propriétaire d'identité est le seul à pouvoir contrôler que les e-mails ont une signature DKIM.
+ **Notifications** – Le propriétaire d'identité et l'expéditeur délégué peuvent configurer des notifications de retours à l'expéditeur et de réclamations. Le propriétaire d'identité des e-mails peut aussi activer le transfert de commentaires par e-mail. Pour en savoir plus sur la configuration des notifications, consultez [Surveillance de votre activité d'envoi Amazon SES](monitor-sending-activity.md).
+ **Vérification** – Les propriétaires d'identité sont tenus de suivre la procédure décrite dans [Identités vérifiées](verify-addresses-and-domains.md) pour vérifier qu'ils sont propriétaires des adresses e-mail et des domaines qu'ils autorisent les expéditeurs délégués à utiliser. Les expéditeurs délégués n'ont pas besoin de vérifier les adresses e-mail ou les domaines précisément pour l'autorisation d'envoi.
**Important**
Le AWS compte de l'expéditeur délégué doit être supprimé du sandbox avant de pouvoir être utilisé pour envoyer des e-mails à des adresses non vérifiées.
+ **AWS Régions** — L'expéditeur délégué doit envoyer les e-mails depuis la AWS région dans laquelle l'identité du titulaire de l'identité est vérifiée. La stratégie d'autorisation d'envoi qui donne l'autorisation à l'expéditeur délégué doit être attachée à l'identité de cette région.
+ **Facturation** – Tous les messages envoyés à partir du compte de l'expéditeur délégué, y compris les e-mails que l'expéditeur délégué envoie à l'aide des adresses du propriétaire d'identité, sont facturés à l'expéditeur délégué.
# Tâches de propriétaire d'identité pour l'autorisation d'envoi Amazon SES
Cette section décrit les étapes que les propriétaires d'identité doivent effectuer lors de la configuration d'une autorisation d'envoi.
**Topics**
+ [Vérification d'une identité pour l'autorisation d'envoi Amazon SES](sending-authorization-identity-owner-tasks-verification.md)
+ [Configuration des notifications du propriétaire d'identité pour l'autorisation d'envoi Amazon SES](sending-authorization-identity-owner-tasks-notifications.md)
+ [Obtention d'informations auprès de l'expéditeur délégué pour l'autorisation d'envoi Amazon SES](sending-authorization-identity-owner-tasks-information.md)
+ [Création d'une stratégie pour l'autorisation d'envoi Amazon SES](sending-authorization-identity-owner-tasks-policy.md)
+ [Exemples de stratégies d'envoi](sending-authorization-policy-examples.md)
+ [Communication des informations d'identité à l'expéditeur délégué pour l'autorisation d'envoi Amazon SES](sending-authorization-identity-owner-tasks-identity.md)
# Vérification d'une identité pour l'autorisation d'envoi Amazon SES
La première étape de configuration de l'autorisation d'envoi consiste à prouver que vous êtes le propriétaire de l'adresse e-mail ou du domaine à partir duquel l'expéditeur délégué enverra des e-mails. La procédure de vérification est décrite dans [Identités vérifiées](verify-addresses-and-domains.md).
Vous pouvez confirmer qu'une adresse e-mail ou un domaine est vérifié en vérifiant son statut dans la section Identités vérifiées du [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)ou en utilisant l'opération `GetIdentityVerificationAttributes` API.
Avant que vous ou l'expéditeur délégué puissiez envoyer des e-mails à des adresses e-mail non vérifiées, vous devez soumettre une demande pour que votre compte soit supprimé de l'environnement de test (sandbox) Amazon SES. Pour de plus amples informations, veuillez consulter [Demande d'accès à la production (sortie du sandbox d'Amazon SES)](request-production-access.md).
**Important**
L' Compte AWS expéditeur délégué doit être supprimé du sandbox avant de pouvoir être utilisé pour envoyer des e-mails à destination ou en provenance d'adresses non vérifiées.
Si votre compte est en sandbox, vous ne pouvez pas envoyer à des adresses e-mail qui ne sont pas vérifiées dans votre compte, même si ces domaines ou adresses e-mail ont été vérifiés dans le compte d'identité
# Configuration des notifications du propriétaire d'identité pour l'autorisation d'envoi Amazon SES
Si vous autorisez un expéditeur délégué à envoyer des e-mails en votre nom, Amazon SES comptabilise tous les retours à l'expéditeur et les réclamations générés par ces e-mails dans les métriques de retours à l'expéditeur et de réclamations de l'expéditeur délégué et non dans les vôtres. Toutefois, si votre adresse IP apparaît sur des listes Blackhole (DNSBLs) antispam tierces basées sur le DNS à la suite de messages envoyés par un expéditeur délégué, la réputation de votre identité peut être entachée. C'est pourquoi, si vous êtes propriétaire d'une identité, vous devez configurer le transfert des retours d'e-mail pour toutes vos identités, y compris celles que vous avez autorisées pour l'envoi délégué. Pour plus d'informations, consultez [Réception des notifications Amazon SES par e-mail](monitor-sending-activity-using-notifications-email.md).
Les expéditeurs délégués peuvent et doivent configurer leurs propres notifications de retour à l'expéditeur et de réclamation pour les identités que vous les avez autorisés à utiliser. Ils peuvent configurer la [publication d'événements](monitor-using-event-publishing.md) pour publier les événements de rebond et de plainte sur une rubrique Amazon SNS ou un stream Firehose.
Si ni le propriétaire d'identité ni l'expéditeur délégué ne configure une méthode d'envoi de notifications d'événements de retour à l'expéditeur et de réclamation, ou si l'expéditeur n'applique pas le jeu de configurations qui utilise la règle de publication d'événements, Amazon SES envoie automatiquement les notifications d'événements par e-mail à l'adresse indiquée dans le champ Return-Path (Chemin de retour) de l'e-mail (ou à l'adresse du champ Source si vous n'avez pas spécifié d'adresse Return-Path (Chemin de retour)), même si vous avez désactivé le transfert de commentaires par e-mail. Ce processus est illustré à l'image suivante.
![\[Flowchart showing notification paths for bounce/complaint events based on various settings.\]](http://docs.aws.amazon.com/fr_fr/ses/latest/dg/images/feedback_forwarding.png)
# Obtention d'informations auprès de l'expéditeur délégué pour l'autorisation d'envoi Amazon SES
Votre politique d'autorisation d'envoi doit spécifier au moins un *principal*, qui est l'entité de votre expéditeur délégué à laquelle vous accordez l'accès afin qu'il puisse effectuer des envois au nom de l'une de vos identités vérifiées. Pour les politiques d'autorisation d'envoi d'Amazon SES, le principal peut être soit le AWS compte de votre expéditeur délégué, soit l'ARN de l'utilisateur Gestion des identités et des accès AWS (IAM), soit un AWS service.
Une manière facile d'y penser est que le *principal*(expéditeur délégué) est le bénéficiaire, et vous (propriétaire de l'identité) êtes le concédant dans la politique d'autorisation dans laquelle vous lui accordez l'*autorisation* d'envoyer n'importe quelle combinaison d'e-mails, d'e-mails bruts, de modèles d'e-mails ou modèles d'e-mails groupés à partir de la *ressource* (identité vérifiée) que vous possédez.
Si vous souhaitez un contrôle plus précis, demandez à l'expéditeur délégué de configurer un utilisateur IAM afin qu'un seul expéditeur délégué puisse envoyer pour vous plutôt que n'importe quel utilisateur du compte AWS de l'expéditeur délégué. L'expéditeur délégué peut trouver des informations sur la configuration d'un utilisateur IAM dans la section [Création d'un utilisateur IAM dans votre compte AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/Using_SettingUpUser.html) dans le *Guide de l'utilisateur IAM*.
Demandez à votre expéditeur délégué l'ID du AWS compte ou le nom de ressource Amazon (ARN) de l'utilisateur IAM afin de pouvoir l'inclure dans votre politique d'autorisation d'envoi. Vous pouvez renvoyer l'expéditeur délégué aux instructions permettant de trouver ces informations dans [Communication d'informations au propriétaire d'identité](sending-authorization-delegate-sender-tasks-information.md). Si l'expéditeur délégué est un AWS service, consultez la documentation de ce service pour déterminer le nom du service.
L'exemple de politique suivant illustre les éléments de base de ce qui est nécessaire dans une politique créée par le propriétaire de l'identité pour autoriser l'expéditeur délégué à envoyer depuis la ressource du propriétaire de l'identité. Le propriétaire de l'identité se rendrait dans le flux des identités vérifiées et, sous la rubrique autorisation, utiliserait le générateur de politiques pour créer, dans sa forme la plus simple, la politique de base suivante autorisant l'expéditeur délégué à envoyer au nom d'une ressource appartenant au propriétaire de l'identité :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSESSendEmail",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": [
"ses:SendEmail",
"ses:SendRawEmail"
],
"Resource": [
"arn:aws:ses:us-east-1:444455556666:identity/bob@example.com"
],
"Condition": {}
}
]
}
```
------
Pour la politique ci-dessus, la légende suivante explique les éléments clés et à qui ils appartiennent :
+ **Principal** : ce champ est renseigné avec l'ARN utilisateur IAM de l'expéditeur délégué.
+ **Action** : ce champ contient deux actions SES (`SendEmail` & `SendRawEmail`) que le propriétaire de l'identité autorise l'expéditeur délégué à effectuer à partir de la ressource du propriétaire de l'identité.
+ **Ressource** : ce champ contient la ressource vérifiée du propriétaire de l'identité à partir de laquelle il autorise l'expéditeur délégué à envoyer.
# Création d'une stratégie pour l'autorisation d'envoi Amazon SES
Comme pour la création de toute politique d'autorisation dans Amazon SES, comme expliqué dans [Création d'une stratégie d'autorisation d'identité](identity-authorization-policies-creating.md), pour autoriser un expéditeur délégué à envoyer des e-mails en utilisant une adresse e-mail ou un domaine (une *identité*) que vous possédez, vous créez la stratégie en spécifiant les actions de l'API d'envoi SES, puis vous attachez cette stratégie à l'identité.
Pour obtenir une liste des actions API qui peuvent être spécifiées dans une stratégie pour l'autorisation d'envoi, consultez la ligne *Action* du tableau [Déclarations propres à la stratégie](policy-anatomy.md#identity-authorization-policy-statements).
Vous pouvez créer une stratégie pour l'autorisation d'envoi en utilisant le générateur de stratégies ou en créant une stratégie personnalisée. Des procédures spécifiques à la création d'une stratégie pour l'autorisation d'envoi sont fournies pour l'une ou l'autre méthode.
**Note**
Les stratégies d'autorisation d'envoi que vous attachez à des identités d'adresse e-mail ont priorité sur les stratégies que vous attachez à leur identité de domaine correspondante. Par exemple, si vous créez une politique pour *example.com*, qui interdit un expéditeur délégué, et créez une politique pour *sender@example.com*, qui autorise l'expéditeur délégué, l'expéditeur délégué peut envoyer des e-mails à partir de *sender@example.com*, mais pas à partir d'une autre adresse du domaine *example.com*.
Si vous créez une stratégie pour *example.com* qui autorise un expéditeur délégué, et que vous créez une stratégie pour *sender@example.com* qui interdit l'expéditeur délégué, l'expéditeur délégué peut envoyer des e-mails à partir de n'importe quelle adresse du domaine *example.com* à l'exception de *sender@example.com*.
Si vous connaissez mal la structure des mécanismes d'autorisation de SES, consultez [Structure de la stratégie](policy-anatomy.md).
Si l'identité que vous autorisez est dupliquée dans une région secondaire dans le cadre de la fonctionnalité [Global endpoints](global-endpoints.md), vous devrez créer des politiques d'autorisation d'envoi relatives à l'identité dans les régions principale et secondaire afin que l'expéditeur délégué soit autorisé à utiliser cette identité pour envoyer dans les deux régions.
## Création d'une stratégie pour l'autorisation d'envoi à l'aide d'un générateur de stratégies.
Vous pouvez utiliser le générateur de stratégie pour créer une stratégie pour l'autorisation d'envoi en suivant la procédure ci-dessous.
**Pour créer une stratégie pour l'autorisation d'envoi en utilisant le générateur de stratégie**
1. Connectez-vous à la console Amazon SES AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Dans le volet de navigation, sous **Configuration**, choisissez **Identities**.
1. Dans le conteneur **Identities (Identités)** sur l'écran **Verified identities (Identités vérifiées)**, sélectionnez l'identité vérifiée pour laquelle vous souhaitez autoriser l'expéditeur délégué à envoyer en votre nom.
1. Choisissez l'onglet **Autorisation** de l'identité vérifiée.
1. Dans le panneau **Authorization policies** (Stratégies d'autorisation), choisissez **Create policy** (Créer une stratégie), puis sélectionnez **Use policy generator** (Utiliser le générateur de stratégie) depuis le menu déroulant.
1. Dans le panneau **Create statement (Créer une instruction)**, choisissez **Allow (Autoriser)** dans le champ **Effect (Effet)**. (Si vous souhaitez créer une politique visant à restreindre votre expéditeur délégué, choisissez **Deny (Refuser)** à la place.)
1. Dans le champ **Principals (Principal)**, entrez l'*ID Compte AWS * ou l'*ARN de l'utilisateur IAM* que votre expéditeur délégué a partagé avec vous pour l'autoriser à envoyer un e-mail au nom de votre compte pour cette identité, puis choisissez **Add (Ajouter)**. (Si vous souhaitez autoriser plusieurs expéditeurs délégués, répétez cette étape pour chacun d'eux.)
1. Dans le champ **Actions**, cochez la case correspondant à chaque type d'envoi que vous souhaitez autoriser pour votre expéditeur délégué.
1. (Facultatif) Développez **Specify conditions (Spécifiez les conditions)** si vous souhaitez ajouter une instruction qualificative à l'autorisation de l'expéditeur délégué.
1. Sélectionnez un opérateur dans la liste déroulante **Operator (Opérateur)**.
1. Sélectionnez un type dans la liste déroulante **Key (Clé)**.
1. En fonction du type de clé que vous avez sélectionné, saisissez sa valeur dans le champ **Value (Valeur)**. (Si vous souhaitez ajouter d'autres conditions, choisissez **Add new condition (Ajouter une nouvelle condition)** et répétez cette étape pour chaque condition supplémentaire.)
1. Choisissez **Save statement (Enregistrer l'instruction)**.
1. (Facultatif) Développez **Create another statement (Créer une autre instruction)** si vous souhaitez ajouter d'autres instructions à votre politique et répétez les étapes 6 à 10.
1. Choisissez **Next (Suivant)** et sur l'écran **Customize policy (Personnaliser la politique)**, le conteneur **Edit policy details (Modifier les détails de la politique)** contient des champs où vous pouvez modifier ou personnaliser le **Name (Nom)** de la politique et le **Policy document (Document de la politique)** proprement dit.
1. Choisissez **Next (Suivant)** et sur l'écran **Review and apply (Vérifier et appliquer)**, le conteneur **Overview (Présentation)** affiche l'identité vérifiée que vous autorisez pour votre expéditeur délégué ainsi que le nom de cette politique. Dans le panneau **Policy document (Document de politique)**, vous trouverez la politique que vous venez de rédiger ainsi que toutes les conditions que vous avez ajoutées ; vérifiez la politique et si elle semble correcte, choisissez **Apply policy (Appliquer la stratégie)**. (Si vous avez besoin de modifier ou corriger quelque chose, choisissez **Previous (Précédent)** et travaillez dans le conteneur **Edit policy details (Modification des détails de la politique)**.) La politique que vous venez de créer permettra à votre expéditeur délégué d'envoyer en votre nom.
1. (Facultatif) Si votre expéditeur délégué souhaite également utiliser une rubrique SNS dont il est propriétaire, pour recevoir des notifications de commentaires lorsqu'il reçoit des retours à l'expéditeur ou des réclamations, ou lorsque les e-mails sont délivrés, vous devrez configurer sa rubrique SNS dans cette identité vérifiée. (Votre expéditeur délégué devra partager avec vous son ARN de rubrique SNS.) Sélectionnez l'onglet **Notifications** et sélectionnez**Edit (Modifier)** dans le conteneur **Feedback notifications (Notifications de commentaire)** :
1. Dans le panneau **Configure SNS topics (Configuration des rubriques SNS(**, l'un des champs de retour, (retour à l'expéditeur, réclamation ou remise), sélectionnez **SNS topic you don't own (Sujet SNS que vous ne possédez pas)** et saisissez le **SNS topic ARN (ARN de rubrique SNS)** détenu et partagé avec vous par votre expéditeur délégué. (Seul l'expéditeur délégué recevra ces notifications, car il est propriétaire de la rubrique SNS ; vous, en tant que propriétaire de l'identité, ne les recevrez pas.)
1. (Facultatif) Si vous souhaitez que votre notification de rubrique inclue les en-têtes de l'e-mail d'origine, cochez la case **Include original email headers (Incluez les en-têtes d'e-mail d'origine)** située directement sous le nom de rubrique SNS de chaque type de commentaires. Cette option est disponible uniquement si vous avez affecté une rubrique Amazon SNS au type de notification associé. Pour en savoir plus sur le contenu des en-têtes de l'e-mail d'origine, consultez l'objet `mail` dans [Contenu des notifications ](notification-contents.md).
1. Sélectionnez **Enregistrer les modifications**. L'application des modifications que vous apportez à vos paramètres de notification peut prendre quelques minutes.
1. (Facultatif) Étant donné que votre expéditeur délégué recevra des notifications de rubriques Amazon SNS pour les retours à l'expéditeur et les réclamations, vous pouvez désactiver entièrement les notifications par e-mail si vous ne souhaitez pas recevoir de commentaires concernant les envois de cette identité. Pour désactiver les commentaires par e-mail pour les retours à l'expéditeur et les réclamations, sous l'onglet **Notifications**, dans le conteneur **Email Feedback Forwarding (Transfert de commentaires par e-mail)**, choisissez **Edit (Modifier)**, décochez la case **Enabled (Activé)**, et choisissez **Save changes (Enregistrer les modifications)**. Les notifications de statut de livraison seront désormais envoyées uniquement aux rubriques SNS appartenant à votre expéditeur délégué.
## Création d'une stratégie personnalisée pour l'autorisation d'envoi
Si vous voulez créer une stratégie pour l'autorisation d'envoi personnalisée et l'attacher à une identité, vous disposez des options suivantes :
+ **Utilisation de l'API Amazon SES** – Créez une stratégie dans un éditeur de texte, puis attachez-la à l'identité à l'aide de l'API `PutIdentityPolicy` décrite dans le document [Référence d'API Amazon Simple Email Service](https://docs.aws.amazon.com/ses/latest/APIReference/).
+ **Utilisation de la console Amazon SES** – Créez une stratégie dans un éditeur de texte et attachez-la à une identité en la collant dans l'éditeur de stratégie personnalisée de la console Amazon SES. La procédure suivante décrit cette méthode.
**Pour créer une stratégie pour l'autorisation d'envoi personnalisée en utilisant l'éditeur de stratégie personnalisé.**
1. Connectez-vous à la console Amazon SES AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Dans le volet de navigation, sous **Configuration**, choisissez **Identities**.
1. Dans le conteneur **Identities (Identités)** sur l'écran **Verified identities (Identités vérifiées)**, sélectionnez l'identité vérifiée pour laquelle vous souhaitez autoriser l'expéditeur délégué à envoyer en votre nom.
1. Dans l'écran des détails de l'identité vérifiée que vous avez sélectionnée à l'étape précédente, choisissez l'onglet **Authorization (Autorisation)**.
1. Dans le panneau **Authorization policies** (Stratégies d'autorisation), choisissez **Create policy** (Créer une stratégie), puis sélectionnez **Create custom policy** (Créer une stratégie personnalisée) depuis le menu déroulant.
1. Dans le volet **Policy document** (Document de la stratégie), saisissez ou collez le texte de votre stratégie au format JSON. Vous pouvez également utiliser le générateur de stratégies pour créer rapidement la structure de base d'une stratégie, puis la personnaliser ici.
1. Choisissez **Apply Policy (Appliquer la stratégie)**. (Si vous avez besoin de modifier votre politique personnalisée, il suffit de cocher sa case à cocher sous l'onglet **Authorization (Autorisation)**, choisir **Edit (Modifier)**, et effectuer vos modifications dans le panneau **Document de politique** pour finir par **Save changes (Enregistrer les modifications)**).
1. (Facultatif) Si votre expéditeur délégué souhaite également utiliser une rubrique SNS dont il est propriétaire, pour recevoir des notifications de commentaires lorsqu'il reçoit des retours à l'expéditeur ou des réclamations, ou lorsque les e-mails sont délivrés, vous devrez configurer sa rubrique SNS dans cette identité vérifiée. (Votre expéditeur délégué devra partager avec vous son ARN de rubrique SNS.) Sélectionnez l'onglet **Notifications** et sélectionnez**Edit (Modifier)** dans le conteneur **Feedback notifications (Notifications de commentaire)** :
1. Dans le panneau **Configure SNS topics (Configuration des rubriques SNS(**, l'un des champs de retour, (retour à l'expéditeur, réclamation ou remise), sélectionnez **SNS topic you don't own (Sujet SNS que vous ne possédez pas)** et saisissez le **SNS topic ARN (ARN de rubrique SNS)** détenu et partagé avec vous par votre expéditeur délégué. (Seul l'expéditeur délégué recevra ces notifications, car il est propriétaire de la rubrique SNS ; vous, en tant que propriétaire de l'identité, ne les recevrez pas.)
1. (Facultatif) Si vous souhaitez que votre notification de rubrique inclue les en-têtes de l'e-mail d'origine, cochez la case **Include original email headers (Incluez les en-têtes d'e-mail d'origine)** située directement sous le nom de rubrique SNS de chaque type de commentaires. Cette option est disponible uniquement si vous avez affecté une rubrique Amazon SNS au type de notification associé. Pour en savoir plus sur le contenu des en-têtes de l'e-mail d'origine, consultez l'objet `mail` dans [Contenu des notifications ](notification-contents.md).
1. Sélectionnez **Enregistrer les modifications**. L'application des modifications que vous apportez à vos paramètres de notification peut prendre quelques minutes.
1. (Facultatif) Étant donné que votre expéditeur délégué recevra des notifications de rubriques Amazon SNS pour les retours à l'expéditeur et les réclamations, vous pouvez désactiver entièrement les notifications par e-mail si vous ne souhaitez pas recevoir de commentaires concernant les envois de cette identité. Pour désactiver les commentaires par e-mail pour les retours à l'expéditeur et les réclamations, sous l'onglet **Notifications**, dans le conteneur **Email Feedback Forwarding (Transfert de commentaires par e-mail)**, choisissez **Edit (Modifier)**, décochez la case **Enabled (Activé)**, et choisissez **Save changes (Enregistrer les modifications)**. Les notifications de statut de livraison seront désormais envoyées uniquement aux rubriques SNS appartenant à votre expéditeur délégué.
# Exemples de stratégies d'envoi
Une autorisation d'envoi vous permet de spécifier les conditions précises selon lesquelles vous autorisez des expéditeurs délégués à effectuer un envoi en votre nom.
**Topics**
+ [Conditions spécifiques à l'envoi de l'autorisation](#sending-authorization-policy-conditions)
+ [Spécification de l'expéditeur délégué](#sending-authorization-policy-example-sender)
+ [Restriction de l'adresse d'expédition](#sending-authorization-policy-example-from)
+ [Restriction de l'heure à laquelle le délégué peut envoyer un e-mail](#sending-authorization-policy-example-time)
+ [Limitation de l'action d'envoi d'e-mails](#sending-authorization-policy-example-action)
+ [Restriction du nom d'affichage de l'expéditeur de l'e-mail](#sending-authorization-policy-example-display-name)
+ [Utilisation de plusieurs instructions](#sending-authorization-policy-example-multiple-statements)
## Conditions spécifiques à l'envoi de l'autorisation
Une *condition* est une restriction qui s'applique à l'autorisation contenue dans l'instruction. La partie de l'instruction qui spécifie les conditions peut être la plus détaillée. Une *clé* est une caractéristique spécifique qui constitue la base pour une restriction d'accès (par exemple, la date et l'heure de la demande).
Vous utilisez à la fois les conditions et les clés afin d'exprimer la restriction. Par exemple, si vous voulez empêcher l'expéditeur délégué d'effectuer des demandes à Amazon SES en votre nom après le 30 juillet 2019, vous devez utiliser la condition appelée `DateLessThan`. Vous utilisez la clé appelée `aws:CurrentTime` et la définissez sur la valeur `2019-07-30T00:00:00Z`.
Vous pouvez utiliser n'importe laquelle des touches AWS-wide répertoriées dans la [section Clés disponibles](https://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_ElementDescriptions.html#AvailableKeys) dans le *guide de l'utilisateur IAM*, ou vous pouvez utiliser l'une des clés suivantes spécifiques à SES qui sont utiles pour envoyer des politiques d'autorisation :
****
| Clé de condition | Description |
| --- | --- |
| `ses:Recipients` | Restreint les adresses des destinataires, qui incluent les adresses « To: », « CC » et « BCC ». |
| `ses:FromAddress` | Limite l'adresse d'expédition. |
| `ses:FromDisplayName` | Limite le contenu de la chaîne utilisée comme nom d'affichage de l'expéditeur (parfois appelé « nom d'expéditeur convivial »). Par exemple, le nom d'affichage « John Doe » est John Doe. |
| `ses:FeedbackAddress` | Limite l'adresse de retour, qui est l'adresse à laquelle les retours à l'expéditeur et les réclamations peuvent vous être envoyés via le transfert de commentaires par e-mail. Pour en savoir plus sur le transfert de commentaires par e-mail, consultez [Réception des notifications Amazon SES par e-mail](monitor-sending-activity-using-notifications-email.md). |
Vous pouvez utiliser les conditions `StringEquals` et `StringLike` avec des clés Amazon SES. Ces conditions sont destinées à la recherche de chaîne sensible à la casse. Pour `StringLike`, les valeurs peuvent inclure un caractère générique (\$1) correspondant à plusieurs caractères ou un caractère générique (?) correspondant à un seul caractère n'importe où dans la chaîne. Par exemple, la condition suivante indique que l'expéditeur délégué peut uniquement effectuer des envois à partir d'une adresse d'expédition qui commence par *invoicing* et se termine par *example.com* :
```
1. "Condition": {
2. "StringLike": {
3. "ses:FromAddress": "invoicing*@example.com"
4. }
5. }
```
Vous pouvez également utiliser la condition `StringNotLike` pour empêcher les expéditeurs délégués d'envoyer des e-mails à partir de certaines adresses e-mail. Par exemple, vous pouvez interdire l'envoi depuis *admin@example.com*, ainsi que des adresses similaires telles que *« admin »@example.com*, *admin\$11@example.com* ou *sender@admin.example.com*, en incluant la condition suivante dans votre déclaration de stratégie :
```
1. "Condition": {
2. "StringNotLike": {
3. "ses:FromAddress": "*admin*example.com"
4. }
5. }
```
Pour de plus amples informations sur la spécification de conditions dans une stratégie, consultez [Éléments de stratégie JSON IAM : Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l'utilisateur IAM*.
## Spécification de l'expéditeur délégué
Le *principal*, qui est l'entité à laquelle vous accordez l'autorisation, peut être un Compte AWS utilisateur Gestion des identités et des accès AWS (IAM) ou un AWS service.
*L'exemple suivant montre une politique simple qui permet à l' AWS ID *123456789012* d'envoyer un e-mail depuis l'identité vérifiée *exemple.com* (qui appartient à 888888888888). Compte AWS * *La `Condition` déclaration contenue dans cette politique autorise uniquement le délégué (c'est-à-dire l' AWS ID *123456789012*) à envoyer un e-mail à partir de l'adresse marketing\$1. \$1 @example .com*, où *\$1* est une chaîne que l'expéditeur souhaite ajouter après *marketing\$1*. .
------
#### [ JSON ]
****
```
{
"Id":"SampleAuthorizationPolicy",
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AuthorizeMarketer",
"Effect":"Allow",
"Resource":"arn:aws:ses:us-east-1:888888888888:identity/example.com",
"Principal":{
"AWS":[
"123456789012"
]
},
"Action":[
"ses:SendEmail",
"ses:SendRawEmail"
],
"Condition":{
"StringLike":{
"ses:FromAddress":"marketing+.*@example.com"
}
}
}
]
}
```
------
L'exemple de stratégie suivant accorde à deux utilisateurs IAM une autorisation d'envoi à partir de l'identité *example.com*. Les utilisateurs IAM sont spécifiés par leur Amazon Resource Name (ARN).
------
#### [ JSON ]
****
```
{
"Id":"ExampleAuthorizationPolicy",
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AuthorizeIAMUser",
"Effect":"Allow",
"Resource":"arn:aws:ses:us-east-1:888888888888:identity/example.com",
"Principal":{
"AWS":[
"arn:aws:iam::111122223333:user/John",
"arn:aws:iam::444455556666:user/Jane"
]
},
"Action":[
"ses:SendEmail",
"ses:SendRawEmail"
]
}
]
}
```
------
L'exemple de stratégie suivant accorde à Amazon Cognito l'autorisation d'envoi à partir de l'identité *example.com*.
------
#### [ JSON ]
****
```
{
"Id":"ExampleAuthorizationPolicy",
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AuthorizeService",
"Effect":"Allow",
"Resource":"arn:aws:ses:us-east-1:888888888888:identity/example.com",
"Principal":{
"Service":[
"cognito-idp.amazonaws.com"
]
},
"Action":[
"ses:SendEmail",
"ses:SendRawEmail"
],
"Condition": {
"StringEquals": {
"aws:SourceAccount": "888888888888",
"aws:SourceArn": "arn:aws:cognito-idp:us-east-1:888888888888:userpool/your-user-pool-id-goes-here"
}
}
}
]
}
```
------
L'exemple de stratégie suivant accorde l'autorisation à tous les comptes au sein d'une Organization AWS d'envoyer à partir de l'identité example.com. L' AWS organisation est spécifiée à l'aide de la clé de condition globale [PrincipalOrgID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid).
------
#### [ JSON ]
****
```
{
"Id":"ExampleAuthorizationPolicy",
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AuthorizeOrg",
"Effect":"Allow",
"Resource":"arn:aws:ses:us-east-1:888888888888:identity/example.com",
"Principal":"*",
"Action":[
"ses:SendEmail",
"ses:SendRawEmail"
],
"Condition":{
"StringEquals":{
"aws:PrincipalOrgID":"o-xxxxxxxxxxx"
}
}
}
]
}
```
------
## Restriction de l'adresse d'expédition
Si vous utilisez un domaine vérifié, vous pouvez créer une stratégie permettant uniquement à l'expéditeur délégué d'envoyer à partir d'une adresse e-mail spécifiée. Pour restreindre l'adresse « De », vous définissez une condition sur la clé appelée *ses : FromAddress*. *La politique suivante permet d'envoyer l' Compte AWS ID *123456789012* à partir de l'*identitéexemple.com*, mais uniquement à partir de l'adresse e-mail sender@example.com.*
------
#### [ JSON ]
****
```
{
"Id":"ExamplePolicy",
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AuthorizeFromAddress",
"Effect":"Allow",
"Resource":"arn:aws:ses:us-east-1:888888888888:identity/example.com",
"Principal":{
"AWS":[
"123456789012"
]
},
"Action":[
"ses:SendEmail",
"ses:SendRawEmail"
],
"Condition":{
"StringEquals":{
"ses:FromAddress":"sender@example.com"
}
}
}
]
}
```
------
## Restriction de l'heure à laquelle le délégué peut envoyer un e-mail
Vous pouvez également configurer votre stratégie d'autorisation de manière à ce qu'un expéditeur délégué ne puisse envoyer des e-mails qu'à une certaine heure du jour ou qu'au sein d'une certaine période. Par exemple, si vous prévoyez d'envoyer votre campagne par e-mail pendant le mois de septembre 2021, vous pouvez utiliser la stratégie suivante pour restreindre la capacité du délégué à n'envoyer les e-mails qu'au cours de ce seul mois.
------
#### [ JSON ]
****
```
{
"Id":"ExamplePolicy",
"Version":"2012-10-17",
"Statement":[
{
"Sid":"ControlTimePeriod",
"Effect":"Allow",
"Resource":"arn:aws:ses:us-east-1:888888888888:identity/example.com",
"Principal":{
"AWS":[
"123456789012"
]
},
"Action":[
"ses:SendEmail",
"ses:SendRawEmail"
],
"Condition":{
"DateGreaterThan":{
"aws:CurrentTime":"2021-08-31T12:00Z"
},
"DateLessThan":{
"aws:CurrentTime":"2021-10-01T12:00Z"
}
}
}
]
}
```
------
## Limitation de l'action d'envoi d'e-mails
Avec Amazon SES, les expéditeurs peuvent envoyer un e-mail au moyen de deux actions : `SendEmail` et `SendRawEmail`. Tout dépend du degré de contrôle que l'expéditeur souhaite avoir sur le format de l'e-mail. Les stratégies d'autorisation d'envoi vous permettent de limiter l'expéditeur délégué à l'une de ces deux actions. Toutefois, de nombreux propriétaires d'identité laissent à l'expéditeur délégué la possibilité de définir les détails des appels d'envoi d'e-mail en autorisant les deux actions dans leurs stratégies.
**Note**
Si vous souhaitez autoriser l'expéditeur délégué à accéder à Amazon SES via l'interface SMTP, vous devez choisir `SendRawEmail` au minimum.
Si votre cas d'utilisation vous impose de limiter l'action, incluez uniquement l'une des actions dans votre stratégie d'autorisation d'envoi. L'exemple suivant montre comment limiter l'action à `SendRawEmail`.
------
#### [ JSON ]
****
```
{
"Id":"ExamplePolicy",
"Version":"2012-10-17",
"Statement":[
{
"Sid":"ControlAction",
"Effect":"Allow",
"Resource":"arn:aws:ses:us-east-1:888888888888:identity/example.com",
"Principal":{
"AWS":[
"123456789012"
]
},
"Action":[
"ses:SendRawEmail"
]
}
]
}
```
------
## Restriction du nom d'affichage de l'expéditeur de l'e-mail
Certains clients de messagerie affichent le nom « convivial » de l'expéditeur de l'e-mail (si l'en-tête de l'e-mail l'indique) à la place de l'adresse d'expédition effective. Par exemple, le nom d'affichage « John Doe » est John Doe. Vous pouvez par exemple envoyer des e-mails à partir de *user@example.com*, mais préférer que les destinataires voient que l'e-mail provient de *Marketing* et non de *user@example.com*. *La politique suivante permet d'envoyer l' Compte AWS ID 123456789012 depuis identity *example.com*, mais uniquement si le nom d'affichage de l'adresse « De » inclut le marketing.*
------
#### [ JSON ]
****
```
{
"Id":"ExamplePolicy",
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AuthorizeFromAddress",
"Effect":"Allow",
"Resource":"arn:aws:ses:us-east-1:888888888888:identity/example.com",
"Principal":{
"AWS":[
"123456789012"
]
},
"Action":[
"ses:SendEmail",
"ses:SendRawEmail"
],
"Condition":{
"StringLike":{
"ses:FromDisplayName":"Marketing"
}
}
}
]
}
```
------
## Utilisation de plusieurs instructions
Votre stratégie d'autorisation d'envoi peut inclure plusieurs instructions. L'exemple de stratégie suivant comporte deux instructions. La première déclaration autorise deux personnes Comptes AWS à envoyer depuis *sender@example.com* à condition que l'adresse « From » et l'adresse de feedback utilisent toutes deux le domaine *example.com*. La deuxième instruction autorise un utilisateur IAM à envoyer des e-mails à partir de *sender@example.com*, à condition que l'adresse e-mail du destinataire appartienne au domaine *example.com*.
# Communication des informations d'identité à l'expéditeur délégué pour l'autorisation d'envoi Amazon SES
Une fois que vous avez créé votre stratégie d'autorisation d'envoi et que vous l'avez attachée à votre identité, vous pouvez fournir l'ARN (Amazon Resource Name) de l'identité à l'expéditeur délégué. L'expéditeur délégué transmet cet ARN à Amazon SES dans l'opération d'envoi d'e-mail ou dans l'en-tête de l'e-mail. Pour trouver l'ARN de votre identité, procédez comme suit.
**Pour trouver l'ARN d'une identité**
1. Connectez-vous à la console Amazon SES AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Dans le panneau de navigation, sous **Configuration**, choisissez **Verified identities (Identités vérifiées)**.
1. Dans la liste des identités, choisissez l'identité à laquelle vous avez attaché la stratégie d'autorisation d'envoi.
1. Dans le panneau **Summary (Récapitulatif)**, la deuxième colonne, **Amazon Resource Name (ARN)**, contiendra l'ARN de l'identité. Il se présente comme suit : *arn:aws:ses:us-east-1:123456789012:identity/user@example.com*. Copiez l'ARN dans son intégralité et communiquez-le à votre expéditeur délégué.
**Important**
Si l'identité que vous autorisez est dupliquée dans une région secondaire dans le cadre de la fonctionnalité [Global endpoints](global-endpoints.md), remplacez le paramètre de région, tel que, par un astérisque`us-east-1`, `*` comme dans l'exemple suivant,. `arn:aws:ses:*:123456789012:identity/user@example.com`
# Tâches d'expéditeur délégué pour l'autorisation d'envoi Amazon SES
En tant qu'expéditeur délégué, vous envoyez des e-mails au nom d'une identité dont vous n'êtes pas propriétaire, mais que vous êtes autorisé à utiliser. Même si vous envoyez au nom du propriétaire de l'identité, les rebonds et les plaintes sont pris en compte dans les statistiques de rebond et de plainte de votre AWS compte, et le nombre de messages que vous envoyez est pris en compte dans votre quota d'envoi. Il vous incombe également de demander l'augmentation du quota d'envoi dont vous pourriez avoir besoin pour envoyer les e-mails du propriétaire de l'identité.
En tant qu'expéditeur délégué, vous devez exécuter les opérations suivantes :
+ [Communication d'informations au propriétaire d'identité](sending-authorization-delegate-sender-tasks-information.md)
+ [Utilisation de notifications d'expéditeur délégué](sending-authorization-delegate-sender-tasks-notifications.md)
+ [Envoi d'e-mails au nom du propriétaire d'identité](sending-authorization-delegate-sender-tasks-email.md)
# Communication d'informations au propriétaire d'identité pour l'autorisation d'envoi Amazon SES
En tant qu'expéditeur délégué, vous devez fournir au propriétaire de l'identité votre identifiant de AWS compte ou le nom de ressource Amazon (ARN) de votre utilisateur IAM, car vous allez envoyer un e-mail au nom du propriétaire de l'identité. Le propriétaire de l'identité a besoin des informations de votre compte afin de créer une politique vous autorisant à envoyer depuis l'une de ses identités vérifiées.
Si vous souhaitez utiliser vos propres rubriques SNS, vous pouvez demander à votre propriétaire d'identité de configurer les notifications de commentaires pour les retours à l'expéditeur, les réclamations ou les remises à envoyer à une ou plusieurs de vos rubriques SNS. Pour ce faire, vous devez partager l'ARN de votre rubrique SNS avec le propriétaire de votre identité afin qu'il puisse configurer votre rubrique SNS avec l'identité vérifiée à partir de laquelle il vous autorise à envoyer des messages.
Les procédures suivantes expliquent comment trouver les informations de votre compte et la rubrique SNS ARNs à partager avec le propriétaire de votre identité.
**Pour trouver l'identifiant de votre AWS compte**
1. Connectez-vous à l' AWS Management Console adresse [https://console.aws.amazon.com](https://console.aws.amazon.com/).
1. Dans le coin supérieur droit de la console, augmentez votre name/account numéro et choisissez **Mon compte** dans le menu déroulant.
1. La page des paramètres du compte s'ouvre et affiche toutes les informations de votre compte, y compris votre identifiant de AWS compte.
**Pour trouver l'ARN de votre utilisateur IAM**
1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
1. Dans le panneau de navigation, sélectionnez **Users**.
1. Dans la liste des utilisateurs, choisissez le nom d'utilisateur. La section **Summary (Récapitulatif)** affiche l'ARN de l'utilisateur IAM. L'ARN ressemble à l'exemple suivant : *arn:aws:iam::123456789012:user/John*.
**Pour trouver l'ARN de votre rubrique SNS**
1. [Ouvrez la console Amazon SNS à l'adresse v3/home. https://console.aws.amazon.com/sns/](https://console.aws.amazon.com/sns/v3/home)
1. Dans le volet de navigation, choisissez **Rubriques**.
1. Dans la liste des rubriques, les rubriques SNS ARNs sont affichées dans la colonne **ARN**. L'ARN ressemble à l'exemple suivant : *arn:aws:sns:us-east* - 1:444455556666 :. my-sns-topic
# Utilisation de notifications d'expéditeur délégué pour l'autorisation d'envoi Amazon SES
En tant qu'expéditeur délégué des e-mails entre comptes, vous envoyez des e-mails au nom d'une identité dont vous n'êtes pas propriétaire, mais que vous êtes autorisé à utiliser. Toutefois, les retours à l'expéditeur et les réclamations sont toujours pris en compte dans *vos* métriques de retour à l'expéditeur et de réclamation, et non celles du propriétaire de l'identité.
Si le taux de retours à l'expéditeur ou de réclamations pour votre compte devient trop élevé, votre compte risque d'être placé sous contrôle ou de ne plus pouvoir envoyer d'e-mails. Pour cette raison, il est important que vous configuriez les notifications et mettiez en place un processus pour les surveiller. Vous devez également mettre en place un processus pour supprimer de vos listes de diffusion les adresses qui ont fait l'objet de retours à l'expéditeur ou de réclamations.
Par conséquent, en tant qu'expéditeur délégué, vous pouvez configurer Amazon SES pour qu'il envoie des notifications lorsque des événements de retour à l'expéditeur et de réclamation se produisent pour les e-mails que vous envoyez au nom des identités que vous ne possédez pas, mais que vous avez été autorisé à utiliser par le propriétaire. Vous pouvez également configurer la [publication d'événements](monitor-using-event-publishing.md) pour publier des notifications de rebond et de plainte sur Amazon SNS ou Firehose.
**Note**
Si vous configurez Amazon SES de façon à envoyer des notifications à l'aide d'Amazon SNS, vous êtes facturé selon les tarifs Amazon SNS standard pour les notifications que vous recevez. Pour en savoir plus, consultez la page [Tarification d'Amazon SNS](https://aws.amazon.com/sns/pricing).
## Créer une nouvelle notification d'expéditeur délégué
Vous pouvez mettre en place des notifications d'envoi de délégués soit avec des ensembles de configuration utilisant la [publication d'événements](event-destinations-manage.md), soit avec des identités vérifiées [configurées avec vos propres rubriques SNS](sending-authorization-identity-owner-tasks-policy.md#configure-sns-topic-you-dont-own).
Les procédures sont données ci-dessous pour configurer un nouvel envoi délégué de notifications en utilisant l'une ou l'autre méthode :
+ Publication d'événements au moyen d'un jeu de configurations
+ Notifications de commentaires sur les rubriques SNS que vous possédez
**Pour configurer la publication d'événements via un jeu de configurations pour l'envoi délégué**
1. Connectez-vous à la console Amazon SES AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/).
1. Suivez la procédure fournie dans [Créer des destination d'évenement](event-destinations-manage.md).
1. Une fois que vous avez configuré la publication d'événements dans votre jeu de configurations, spécifiez le nom du jeu de configurations lorsque vous envoyez un e-mail en tant qu'expéditeur délégué à l'aide de l'identité vérifiée à partir de laquelle le propriétaire de l'identité vous a autorisé à envoyer. Consultez [Envoi d'e-mails au nom du propriétaire d'identité](sending-authorization-delegate-sender-tasks-email.md).
**Pour configurer des notifications de commentaires sur les rubriques SNS que vous possédez pour l'envoi délégué**
1. Une fois que vous avez décidé quelles rubriques SNS vous souhaitez utiliser pour les notifications de commentaires, suivez les procédures [pour trouver l'ARN de votre rubrique SNS](sending-authorization-delegate-sender-tasks-information.md#find-sns-topic-arn), copiez l'ARN complet et partagez-le avec le propriétaire de votre identité.
1. Demandez à votre propriétaire d'identité de configurer vos rubriques SNS pour les notifications de commentaires sur l'identité partagée à partir de laquelle il vous a autorisé à envoyer. (Le propriétaire de votre identité devra suivre les procédures données pour [la configuration des rubriques SNS](sending-authorization-identity-owner-tasks-policy.md#configure-sns-topic-you-dont-own) dans les procédures de politique d'autorisation.)
# Envoi d'e-mails au nom du propriétaire d'identité pour l'autorisation d'envoi Amazon SES
En tant qu'expéditeur délégué, vous envoyez les e-mails de la même façon que les autres expéditeurs Amazon SES, sauf que vous fournissez l'Amazon Resource Name (ARN) de l'identité que son propriétaire vous a autorisé à utiliser. Lorsque vous appelez Amazon SES pour envoyer l'e-mail, Amazon SES vérifie si l'identité que vous avez spécifiée est associée à une stratégie qui vous autorise à effectuer un envoi pour ladite identité.
Il existe différentes façon de spécifier l'ARN de l'identité au moment d'envoyer un e-mail. La méthode que vous utilisez varie selon que vous envoyez l'e-mail à l'aide des opérations de l'API Amazon SES ou de l'interface SMTP Amazon SES.
**Important**
Pour envoyer un e-mail avec succès, vous devez vous connecter au point de terminaison Amazon SES dans la AWS région dans laquelle le propriétaire de l'identité a vérifié l'identité.
**En outre, les AWS comptes du propriétaire de l'identité et de l'expéditeur délégué doivent être supprimés du sandbox avant que l'un ou l'autre des comptes puisse envoyer des e-mails à des adresses non vérifiées.** Pour de plus amples informations, veuillez consulter [Demande d'accès à la production (sortie du sandbox d'Amazon SES)](request-production-access.md).
Si l'identité que vous avez été autorisé à utiliser est dupliquée dans une région secondaire dans le cadre de la fonctionnalité [Global Endpoints](global-endpoints.md) :
Le propriétaire de l'identité doit vous avoir fourni un ARN d'identité dont le paramètre de région, tel que,`us-east-1`, a été remplacé par un astérisque, `*` comme dans l'exemple suivant,`arn:aws:ses:*:123456789012:identity/user@example.com`.
Le propriétaire de l'identité doit avoir créé des politiques d'autorisation d'envoi pour vous dans les régions principale et secondaire.
## Utilisation de l'API Amazon SES
Comme pour tout expéditeur d'e-mail Amazon SES, si vous accédez à Amazon SES via l'API Amazon SES (soit directement via HTTPS, soit indirectement via un AWS SDK), vous pouvez choisir entre l'une des trois actions d'envoi d'e-mails suivantes :`SendEmail`,, `SendTemplatedEmail` et. `SendRawEmail` Le [manuel Amazon Simple Email Service API Reference](https://docs.aws.amazon.com/ses/latest/APIReference/) en décrit les détails APIs, mais nous donnons un aperçu des paramètres d'autorisation d'envoi ici.
### SendRawEmail
Si vous souhaitez utiliser `SendRawEmail` afin de contrôler le format de vos e-mails, vous pouvez spécifier l'identité entre comptes de deux manières différentes :
+ **Transmettez les paramètres facultatifs à l'`SendRawEmail`API**. Les paramètres requis sont décrits dans le tableau suivant :
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/ses/latest/dg/sending-authorization-delegate-sender-tasks-email.html)
+ **Incluez les en-têtes X-header dans l'e-mail**. Les en-têtes X-header sont des en-têtes personnalisés que vous pouvez utiliser en plus des en-têtes d'e-mail standard (tels que les en-têtes From, Reply-To ou Subject). Amazon SES reconnaît trois en-têtes X-header que vous pouvez utiliser pour spécifier les paramètres d'autorisation d'envoi :
**Important**
N'incluez pas ces en-têtes X dans la signature DKIM, car Amazon SES les supprime avant l'envoi de l'e-mail.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/ses/latest/dg/sending-authorization-delegate-sender-tasks-email.html)
Amazon SES supprime tous les en-têtes X-header de l'e-mail avant de l'envoyer. Si vous incluez plusieurs instances d'un en-tête X-header, Amazon SES utilise uniquement la première instance.
L'exemple suivant présente un e-mail qui comprend des en-têtes X d'autorisation d'envoi :
```
1. X-SES-SOURCE-ARN: arn:aws:ses:us-east-1:123456789012:identity/example.com
2. X-SES-FROM-ARN: arn:aws:ses:us-east-1:123456789012:identity/example.com
3. X-SES-RETURN-PATH-ARN: arn:aws:ses:us-east-1:123456789012:identity/example.com
4.
5. From: sender@example.com
6. To: recipient@example.com
7. Return-Path: feedback@example.com
8. Subject: subject
9. Content-Type: multipart/alternative;
10. boundary="----=_boundary"
11.
12. ------=_boundary
13. Content-Type: text/plain; charset=UTF-8
14. Content-Transfer-Encoding: 7bit
15.
16. body
17. ------=_boundary
18. Content-Type: text/html; charset=UTF-8
19. Content-Transfer-Encoding: 7bit
20.
21. body
22. ------=_boundary--
```
### SendEmail et SendTemplatedEmail
Si vous utilisez l'opération `SendEmail` ou `SendTemplatedEmail`, vous pouvez spécifier l'identité entre comptes en transmettant les paramètres facultatifs ci-dessous. Vous ne pouvez pas utiliser la méthode d'en-tête X-header si vous utilisez l'opération `SendEmail` ou `SendTemplatedEmail`.
****
| Paramètre | Description |
| --- | --- |
| `SourceArn` | ARN de l'identité associée à la stratégie d'autorisation d'envoi qui vous permet d'effectuer un envoi pour l'adresse e-mail spécifiée dans le paramètre `Source` de `SendEmail` ou `SendTemplatedEmail`. |
| `ReturnPathArn` | ARN de l'identité associée à la stratégie d'autorisation d'envoi qui vous permet d'utiliser l'adresse e-mail spécifiée dans le paramètre `ReturnPath` de `SendEmail` ou `SendTemplatedEmail`. |
L'exemple suivant montre comment envoyer un e-mail qui inclut les attributs `SourceArn` et `ReturnPathArn` à l'aide de l'opération `SendEmail` ou `SendTemplatedEmail` et du [kit SDK pour Python](https://aws.amazon.com/sdk-for-python).
```
import boto3
from botocore.exceptions import ClientError
# Create a new SES resource and specify a region.
client = boto3.client('ses',region_name="us-east-1")
# Try to send the email.
try:
#Provide the contents of the email.
response = client.send_email(
Destination={
'ToAddresses': [
'recipient@example.com',
],
},
Message={
'Body': {
'Html': {
'Charset': 'UTF-8',
'Data': 'This email was sent with Amazon SES.',
},
},
'Subject': {
'Charset': 'UTF-8',
'Data': 'Amazon SES Test',
},
},
SourceArn='arn:aws:ses:us-east-1:123456789012:identity/example.com',
ReturnPathArn='arn:aws:ses:us-east-1:123456789012:identity/example.com',
Source='sender@example.com',
ReturnPath='feedback@example.com'
)
# Display an error if something goes wrong.
except ClientError as e:
print(e.response['Error']['Message'])
else:
print("Email sent! Message ID:"),
print(response['ResponseMetadata']['RequestId'])
```
## Utilisation de l'interface SMTP Amazon SES
Lorsque vous utilisez l'interface SMTP Amazon SES pour l'envoi entre comptes, vous devez inclure les en-têtes `X-SES-SOURCE-ARN`, `X-SES-FROM-ARN` et `X-SES-RETURN-PATH-ARN` dans votre message. Transmettez ces en-têtes une fois que vous avez émis la commande `DATA` dans la conversation SMTP.