翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon SES での ID の設定 Amazon Simple Email Service (Amazon SES) は、Simple Mail Transfer Protocol (SMTP) を使用してEメールを送信します。SMTP 自体は認証を提供しません。実際の送信元を隠蔽したスパムの発信者から、他人を装って E メールメッセージが送信される可能性があります。スパムの発信者は、Eメールヘッダーを改ざんし、送信元 IP アドレスを偽装することにより、そのメールメッセージが本物であると受取人に思い込ませることができます。 メールトラフィックを転送するほとんどのISP は、E メールの正当性を評価するための対策を講じています。E メールが*認証*されているかどうかの確認は、ISP が講じているそうした対策の 1 つです。認証において送信者は、自分がその送信元アカウントの所有者であることを証明する必要があります。場合によっては、ISP は認証されない E メールの送信を拒否します。配信性能を最大限確保するために、E メールを認証することをお勧めします。 以降のセクションでは、ISP で使用される 2 つの認証メカニズム、Sender Policy Framework (SPF) とドメインキーアイデンティファイドメール (DKIM)、について説明するとともに、Amazon SES でそれらの標準を使用する方法について説明します。 + Eメールメッセージをその送信元のシステムにまでさかのぼって追跡するSPF については、「[Amazon SES における SPF を使った E メールの認証](send-email-authentication-spf.md)」を参照してください。 + メールメッセージに署名し、自分のメッセージが本物であることと送信中に改ざんされていないことを ISP に証明するための標準規格であるDKIM は、「[Amazon SES における DKIM を使った E メールの認証](send-email-authentication-dkim.md)」を参照してください。 + SPF および DKIM に基づく DMARC (Domain-based Message Authentication, Reporting and Conformance) に準拠する方法については、「[Amazon SES の DMARC 認証プロトコルへの準拠](send-email-authentication-dmarc.md)」を参照してください。 # E メールの認証方法 Amazon Simple Email Service (Amazon SES) は、Simple Mail Transfer Protocol (SMTP) を使用して E メールを送信します。SMTP 自体は認証を提供しません。実際の送信元を隠蔽したスパムの発信者から、他人を装って E メールメッセージが送信される可能性があります。スパムの発信者は、E メールヘッダーを改ざんし、送信元 IP アドレスを偽装することにより、そのメールメッセージが本物であると受取人に思い込ませることができます。 メールトラフィックを転送するほとんどのISP は、E メールの正当性を評価するための対策を講じています。E メールが認証されているかどうかの確認は、ISP が講じているそうした対策の 1 つです。認証において送信者は、自分がその送信元アカウントの所有者であることを証明する必要があります。場合によっては、ISP は認証されない E メールの送信を拒否します。配信性能を最大限確保するために、E メールを認証することをお勧めします。 **Topics** + [Amazon SES における DKIM を使った E メールの認証](send-email-authentication-dkim.md) + [Amazon SES における SPF を使った E メールの認証](send-email-authentication-spf.md) + [カスタムの MAIL FROM ドメインを使用する](mail-from.md) + [Amazon SES の DMARC 認証プロトコルへの準拠](send-email-authentication-dmarc.md) + [Amazon SES での BIMI の使用](send-email-authentication-bimi.md) # Amazon SES における DKIM を使った E メールの認証 *DomainKeys アイデンティファイドメール*(*DKIM*) は、特定のドメインから来たと主張するEメールが、そのドメインの所有者によって実際に許可されていることを確認するために設計されたEメールセキュリティ標準です。パブリックキー暗号を使用して、プライベートキーで Eメールに署名します。受信者サーバーは、ドメインの DNS に発行されたパブリックキーを使用して、送信中にEメールの一部が変更されていないことを確認できます。 DKIM 署名はオプションです。DKIM署名を使ってEメールに署名することで、DKIMに対応する E メールプロバイダーによる配信性能を強化することができます。Amazon SES には、DKIM 署名を使用してメッセージに署名するための 3 つのオプションがあります。 + **Easy DKIM**: SES によってパブリックキーとプライベートキーのペアが生成され、その ID から送信するすべてのメッセージに DKIM 署名が自動的に追加されます。「[Amazon SES のEasy DKIM](send-email-authentication-dkim-easy.md)」を参照してください。 + **Deterministic Easy DKIM (DEED)**: Easy DKIM を使用している親 ID として DKIM 署名属性を自動的に継承するレプリカ ID を作成 AWS リージョン することで、複数の にわたって一貫した DKIM 署名を維持できます。「」を参照してください[Amazon SES で Deterministic Easy DKIM (DEED) を使用する](send-email-authentication-dkim-deed.md)。 + **BYODKIM (Bring Your Own DKIM)**: 独自のパブリックキーとプライベートキーのペアを提供すると、SES によって、その ID から送信するすべてのメッセージに DKIM 署名が追加されます。「[Amazon SES で独自の DKIM 認証トークン (BYODKIM) を提供する](send-email-authentication-dkim-bring-your-own.md)」を参照してください。 + **手動で DKIM 署名を追加する**: `SendRawEmail` API を使用して送信する E メールに独自の DKIM 署名を追加します。「[Amazon SES 内で手動での DKIM 署名](send-email-authentication-dkim-manual.md)」を参照してください。 ## DKIM 署名キーの長さ 現在、多くの DNS プロバイダーは DKIM 2048 ビット RSA 暗号化を完全にサポートしているため、Amazon SES は DKIM 2048 をサポートして E メールのより安全な認証を可能にし、API またはコンソールから Easy DKIM を設定するときにデフォルトのキー長として使用します。2048ビットキーは、Bring Your Own DKIM（BYODKIM）でもセットアップして使用できます。この場合、署名キーの長さは1024ビット以上2048ビット以下である必要があります。 Easy DKIMで構成されている場合、セキュリティと電子メールの配信可能性のために、まだ2048をサポートしていないDNSプロバイダーによって問題が発生した場合に備えて、1024ビットと2048ビットのいずれかのキー長と1024に戻す柔軟性を使用することを選択できます。*新しい ID を作成すると、1024 を指定しない限り、デフォルトで DKIM 2048 で作成されます。* 転送中のEメールの配信性能を維持するために、DKIM キーの長さを変更できる頻度には制限があります。制限事項は次のとおりです。 + 既に設定されているキーの長さと同じ長さに切り替えることはできません。 + 24時間の間に複数回異なるキーの長さに切り替えることはできません（その期間で1024への最初のダウングレードでない限り）。 Eメールが送信されると、DNS はパブリックキーを使用してメールを認証します。したがって、キーを迅速または頻繁に変更すると、以前のキーがすでに無効になっている可能性があるため、DNS はメールを DKIM で認証できない可能性があります。したがって、これらの制限は保護されます。 ## DKIM に関する考慮事項 E メールの認証に DKIM を使用する場合、次のルールが適用されます。 + 「送信元」アドレスで使用するドメインでのみ DKIM を設定する必要があります。「Return-Path」あるいは「Reply-to」アドレスで使用するドメインに DKIM をセットアップする必要はありません。 + Amazon SES は複数の AWS リージョンで利用できます。複数の AWS リージョンを使用して E メールを送信する場合、リージョンごとに DKIM のセットアップを完了して、すべての E メールに DKIM 署名があることを確認する必要があります。 + DKIM プロパティは親ドメインから継承されるため、DKIM 認証を使用してドメインを検証する場合は次のようになります。 + DKIM 認証は、そのドメインのすべてのサブドメインにも適用されます。 + サブドメインの DKIM 設定は、サブドメインで DKIM 認証を使用しない場合は継承を無効にし、後で再度有効にすることで、親ドメインの設定を上書きできます。 + DKIM 認証は、そのアドレスで DKIM 検証済みドメインを参照する E メール ID から送信されるすべての E メールにも適用されます。 + E メールアドレスの DKIM 設定を、サブドメインの設定 (適用される場合) と親ドメインの設定に上書きできます。DKIM 認証なしでメールを送信する場合は、継承を無効にし、後で再度有効にすることもできます。 ## 継承された DKIM 署名プロパティについて理解する まず、Easy DKIM または BYODKIM が使用されているかどうかにかかわらず、そのドメインが DKIM で設定されている場合、E メールアドレス ID が親ドメインから DKIM 署名プロパティを継承することを理解することが重要です。したがって、E メールアドレス ID で DKIM 署名を無効または有効にすると、次の重要な点に基づいてドメインの DKIM 署名プロパティが上書きされます。 + E メールアドレスが属するドメインで既に DKIM をセットアップしている場合には、E メールアドレス ID にも同じく DKIM 署名を有効にする必要はありません。 + ドメインで DKIM をセットアップする場合、Amazon SES が親ドメインから継承された DKIM プロパティを介して、このドメインのすべてのアドレスからのすべての E メールを自動的に認証します。 + 特定の E メールアドレス ID の DKIM 設定により、そのアドレスが属する*親ドメインまたはサブドメイン (該当する場合) の設定が自動的に上書きされます*。 E メールアドレス ID の DKIM 署名プロパティが親ドメインから継承されるため、これらのプロパティを上書きする場合は、次の表で説明された上書きの階層ルールに注意する必要があります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ses/latest/dg/send-email-authentication-dkim.html) 通常、DKIM 署名の無効化はお勧めしません。送信者の評価を損うリスクがあるだけでなく、送信したメールが迷惑メールやスパムフォルダに移動されたり、ドメインが偽装されたりするリスクが高まるためです。 ただし、特定のユースケースや、DKIM 署名を永続的または一時的に無効にしたり、後で再有効化したりする必要があるような通常とは異なるビジネス上の意思決定がなされた場合に備えて、ドメインから継承された DKIM 署名プロパティを E メールアドレス ID に上書きするための機能があります。「[E メールアドレス ID に継承された DKIM 署名を上書きする](send-email-authentication-dkim-easy-managing.md#send-email-authentication-dkim-easy-setup-email)」を参照してください。 # Amazon SES のEasy DKIM ドメイン ID で Easy DKIM をセットアップすると、Amazon SES はその ID から送信するすべての E メールに 2048 ビットの DKIM キーを自動的に追加します。Easy DKIM を設定するには、Amazon SES コンソールあるいは API を使用できます。 **注記** Easy DKIM をセットアップするには、ドメインの DNS 設定を変更する必要があります。Route 53 を DNS プロバイダーとして使用している場合、Amazon SES は適切なレコードを自動的に作成します。別の DNS プロバイダーを使用する場合は、使用するプロバイダーのドキュメントを参照して、ドメインの DNS 設定を変更する詳細を確認します。 **警告** 現在 BYODKIM が有効になっていて、Easy DKIM に移行している場合、Easy DKIM のセットアップ中で、DKIM ステータスが保留中になっている間、Amazon SES は BYODKIM を使用してメールに署名しないことに注意してください。Easy DKIM を有効にする電話を (API またはコンソールを介して) かけたときと SES が DNS 設定を確認できるときまでの間に、SES によって DKIM 署名なしで E メールが送信されることがあります。したがって、中間ステップを使用して、一方の DKIM 署名方法からもう一方の DKIM 署名方法に移行する (例えば、BYODKIM を有効にしてドメインのサブドメインを使用し、Easy DKIM 検証に合格したら削除する) か、アプリケーションのダウンタイム中にこのアクティビティを実行することをお勧めします (存在する場合)。 ## 検証済みドメイン ID に対する Easy DKIM のセットアップ このセクションの手順は、すでに作成したドメイン ID に Easy DKIM を設定するために必要なステップだけに簡素化されています。ドメイン ID を作成していない場合や、デフォルトの設定セット、カスタムの MAIL FROM ドメイン、タグの使用など、ドメイン ID をカスタマイズするための利用可能なすべてのオプションを表示する場合は、「[ドメイン ID の作成](creating-identities.md#verify-domain-procedure)」を参照してください。 Easy DKIM ドメイン ID の作成には、DKIM ベースの検証の設定があります。この検証では、Amazon SES のデフォルトである 2048 ビットを受け入れるか、1024 ビットを選択してデフォルトを上書きするかを選択できます。「[DKIM 署名キーの長さ](send-email-authentication-dkim.md#send-email-authentication-dkim-1024-2048)」を参照して、DKIM 署名キーの長さとその変更方法のご参照ください。 **ドメインに Easy DKIM をセットアップするには** 1. AWS マネジメントコンソール にサインインし、Amazon SES コンソール ([https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)) を開きます。 1. ナビゲーションペインの **[設定]** で、**[ID]** を選択します。 1. ID のリストで、**ID のタイプ**が*ドメイン*であるIDを選択します。 **注記** ドメインを作成または検証する必要がある場合は、「[ドメイン ID の作成](creating-identities.md#verify-domain-procedure)」を参照してください。 1. **認証**タブの**DomainKeys アイデンティファイドメール (DKIM)**コンテナで、**編集**を選択します。 1. **DKIM の詳細設定**コンテナで、**ID のタイプ**フィールドの**Easy DKIM**ボタンを選択します。 1. **DKIM 署名キーの長さ**フィールドで、[**RSA\$12048\$1BIT**または**RSA\$11024\$1BIT**](send-email-authentication-dkim.md#send-email-authentication-dkim-1024-2048)を選択します。 1. **DKIM 署名**フィールドで、[**Enabled**]ボックスをチェックします。 1. [**Save changes**] をクリックします。 1. Easy DKIM でドメイン ID を設定したので、DNS プロバイダーで検証プロセスを完了する必要があります。「[DNS プロバイダーでの DKIM ドメイン ID の検証](creating-identities.md#just-verify-domain-proc)」に進み、Easy DKIM の DNS 認証手順に従います。 ## ID の Easy DKIM 署名キーの長さを変更する このセクションの手順では、署名アルゴリズムに必要な Easy DKIM ビットを簡単に変更する方法について説明します。セキュリティを強化するには、常に 2048 ビットの署名長が優先されますが、DKIM 1024 のみをサポートする DNS プロバイダーを使用する必要があるなど、1024 ビットの長さを使用する必要がある場合があります。 転送中のEメールの配信性能を維持するために、DKIM キーの長さを変更または反転できる頻度には制限があります。 メールが送信されると、DNS はパブリックキーを使用してメールを認証します。したがって、キーを迅速または頻繁に変更すると、以前のキーがすでに無効になっている可能性があるため、DNS はメールをDKIMで認証できない可能性があります。したがって、次の制限によって保護されます。 + 既に設定されているキーの長さと同じキーの長さに切り替えることはできません。 + 24 時間の間に複数回異なるキーの長さに切り替えることはできません（ただし、その間の1024への最初のダウングレードでない限り）。 次の手順を使用してキーの長さを変更する際、これらの制限のいずれかを無視すると、コンソールでは、無効だった理由とともに「*the input you provided is invalid (指定した入力は無効です)*」と示すエラーバナーが返されます。 **DKIM 署名キーの長さビットを変更するには** 1. AWS マネジメントコンソール にサインインし、Amazon SES コンソール ([https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)) を開きます。 1. ナビゲーションペインの**設定** で、**ID の検証**を選択します。 1. ID のリストで、DKIM署名キーを変更したいID を選択します。 1. **認証**タブの**DomainKeys アイデンティファイドメール (DKIM)**コンテナで、**編集**を選択します。 1. **[DKIM の詳細設定]** コンテナで、**[DKIM 署名キーの長さ]** フィールドの [**[RSA\$12048\$1BIT]** または **[RSA\$11024\$1BIT]**](send-email-authentication-dkim.md#send-email-authentication-dkim-1024-2048) を選択します。 1. [**Save changes(変更を保存)**] をクリックします。 # Amazon SES で Deterministic Easy DKIM (DEED) を使用する Deterministic Easy DKIM (DEED) は、複数の DKIM 設定を管理するためのソリューションを提供します AWS リージョン。DNS 管理を簡素化し、一貫した DKIM 署名を維持することで、DEED は堅牢な E メール認証手法を維持しながら、マルチリージョンの E メール送信オペレーションを効率化するために役立ちます。 ## Deterministic Easy DKIM (DEED) とは Deterministic Easy DKIM (DEED) は、Easy DKIM で設定された親ドメイン AWS リージョン に基づいて、すべての で一貫した DKIM トークンを生成する機能です。 [Amazon SES のEasy DKIM](send-email-authentication-dkim-easy.md)これにより、Easy DKIM で現在設定 AWS リージョン されている親 ID と同じ DKIM 署名設定を自動的に継承および維持する異なる に ID をレプリケートできます。DEED では、親 ID に対して DNS レコードを 1 回発行するだけで、レプリカ ID は同じ DNS レコードを使用してドメインの所有権を検証し、DKIM 署名を管理します。 DNS 管理を簡素化し、一貫した DKIM 署名を維持することで、DEED は、E メール認証のベストプラクティスを維持しながら、マルチリージョンの E メール送信オペレーションを効率化するために役立ちます。 DEED に関して使用される用語: + **親 ID** – レプリカ ID の DKIM 設定のソースとして機能する、Easy DKIM で設定された検証済み ID。 + **レプリカ ID** – 同じ DNS 設定と DKIM 署名設定を共有する親 ID のコピー。 + **親リージョン** – 親 ID が設定されている AWS リージョン 。 + **レプリカリージョン** – レプリカ ID が設定されている AWS リージョン 。 + **DEED ID** – 親 ID またはレプリカ ID として使用されるあらゆる ID (新しい ID が作成されると、最初は通常の (非 DEED) ID として扱われます。ただし、レプリカが作成されると、その ID は DEED ID と見なされます)。 DEED を使用する主な利点は次のとおりです。 + **DNS 管理の簡素化** – 親 ID に対して DNS レコードを 1 回だけ発行します。 + **より簡単なマルチリージョンオペレーション** – E メール送信オペレーションを新しいリージョンに拡張するプロセスを簡素化します。 + **管理オーバーヘッドの削減** – DKIM 設定を親 ID から一元管理します。 ## Deterministic Easy DKIM (DEED) の仕組み レプリカ ID を作成すると、Amazon SES は親 ID からレプリカ ID に DKIM 署名キーを自動的にレプリケートします。親 ID に加えられた、それ以降の DKIM キーローテーションまたはキーの長さの変更は、すべてのレプリカ ID に自動的に伝播されます。 このプロセスには、以下のワークフローが含まれます。 1. Easy DKIM AWS リージョン を使用して に親 ID を作成します。 1. 親 ID に必要な DNS レコードを設定します。 1. 他の にレプリカ ID を作成し AWS リージョン、親 ID のドメイン名と DKIM 署名リージョンを指定します。 1. Amazon SES は、親の DKIM 設定をレプリカ ID に自動的にレプリケートします。 重要な考慮事項: + 既にレプリカである ID のレプリカを作成することはできません。 + 親 ID では [Easy DKIM](send-email-authentication-dkim-easy.md) が有効になっている必要があります。BYODKIM のレプリカまたは手動で署名された ID のレプリカを作成することはできません。 + 親 ID は、すべてのレプリカ ID が削除されるまで削除できません。 ## DEED を使用したレプリカ ID の設定 このセクションでは、DEED を使用してレプリカ ID を作成および検証する方法と、必要なアクセス許可の例を示します。 **Topics** + [レプリカ ID の作成](#creating-replica-identity) + [レプリカ ID 設定の検証](#verifying-replica-identity) + [DEED を使用するために必要なアクセス許可](#required-permissions) ### レプリカ ID の作成 レプリカ ID を作成するには: 1. レプリカアイデンティティを作成する AWS リージョン で、[https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/) で SES コンソールを開きます。 (SES コンソールでは、レプリカ ID は*グローバル ID *と呼ばれます)。 1. ナビゲーションペインで、**[ID]** を選択します。 1. [**ID の作成**] を選択します。 1. **[ID タイプ]** で **[ドメイン]** を選択し、Easy DKIM で設定された、レプリケートして親として機能する既存の ID のドメイン名を入力します。 1. **[DKIM の詳細設定]** を展開し、**[Deterministic Easy DKIM]** を選択します。 1. **[親リージョン]** ドロップダウンメニューから、グローバル (レプリカ) ID に入力したのと同じ名前の Easy DKIM で署名された ID が存在する親リージョンを選択します (デフォルトでは、レプリカリージョンは SES コンソールにサインインしたリージョンになります)。 1. **DKIM 署名**が有効になっていることを確認します。 1. (オプション) ドメイン ID に 1 つ以上の**タグ**を追加します。 1. 設定を確認して、**[ID の作成]** を選択します。 の使用 AWS CLI: Easy DKIM で設定された親 ID に基づいてレプリカ ID を作成するには、次の例に示すように、親のドメイン名、レプリカ ID を作成するリージョン、および親の DKIM 署名リージョンを指定する必要があります。 ``` aws sesv2 create-email-identity --email-identity example.com --region us-west-2 --dkim-signing-attributes '{"DomainSigningAttributesOrigin": "AWS_SES_US_EAST_1"}' ``` 前の例では、以下のようになっています。 1. *example.com* を、レプリケートされる親ドメイン ID に置き換えます。 1. *us-west-2* を、レプリカドメイン ID が作成されるリージョンに置き換えます。 1. *AWS\$1SES\$1US\$1EAST\$11* を、レプリカ ID にレプリケートされる Easy DKIM 署名設定を表す親の DKIM 署名リージョンに置き換えます。 **注記** `AWS_SES_` プレフィックスは、DKIM が Easy DKIM を使用して親 ID 用に設定されたことを示し、 `US_EAST_1`は作成された AWS リージョン です。 ### レプリカ ID 設定の検証 レプリカ ID を作成したら、親 ID の DKIM 署名設定で正しく設定されていることを検証できます。 **レプリカ ID を検証するには:** 1. レプリカアイデンティティを AWS リージョン 作成した で、[https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/) で SES コンソールを開きます。 1. ナビゲーションペインで **[ID]** を選択し、**[ID]** 表から、検証する ID を選択します。 1. **[認証]** タブで、**[DKIM の設定]** フィールドにはステータスが表示され、**[親リージョン]** フィールドには DEED を利用した ID の DKIM 署名設定に使用されているリージョンが表示されます。 の使用 AWS CLI: `get-email-identity` コマンドを使用して、レプリカのドメイン名とリージョンを指定します。 ``` aws sesv2 get-email-identity --email-identity example.com --region us-west-2 ``` レスポンスには、親 ID の DKIM 署名設定でレプリカ ID が正常に設定されたことを示す `SigningAttributesOrigin` パラメータの親リージョンの値が含まれます。 ``` { "DkimAttributes": { "SigningAttributesOrigin": "AWS_SES_US_EAST_1" } } ``` ### DEED を使用するために必要なアクセス許可 DEED を使用するには、以下が必要です。 1. レプリカリージョンで E メール ID を作成するための標準アクセス許可。 1. 親リージョンから DKIM 署名キーをレプリケートするアクセス許可。 #### DKIM レプリケーションの IAM ポリシーの例 次のポリシーでは、親 ID から指定されたレプリカリージョンへの DKIM 署名キーのレプリケーションを許可します。 ------ #### [ 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"] } } } ] } ``` ------ ## ベストプラクティス 次のベストプラクティスが推奨されます。 + **親リージョンとレプリカリージョンを計画する** – 選択する親リージョンはレプリカリージョンで使用される DKIM 設定の信頼できるソースとなるため、検討が必要です。 + **一貫した IAM ポリシーを使用する** – IAM ポリシーで、意図したすべてのリージョンで DKIM レプリケーションが許可されていることを確認します。 + **親 ID をアクティブにしておく** – レプリカ ID は親 ID の DKIM 署名設定を継承することに注意してください。この依存関係により、すべてのレプリカ ID が削除されるまで親 ID を削除することはできません。 ## トラブルシューティング DEED で問題が発生した場合は、次の点を考慮してください。 + **検証エラー** – DKIM レプリケーションに必要なアクセス許可があることを確認します。 + **レプリケーションの遅延** – レプリケーションが完了するまでにしばらく時間がかかります (特に新しいレプリカ ID を作成する場合)。 + **DNS の問題** – 親 ID の DNS レコードが正しく設定され、伝播されていることを確認します。 # Amazon SES で独自の DKIM 認証トークン (BYODKIM) を提供する [Easy DKIM](send-email-authentication-dkim-easy.md) を使用する代わりに、独自のパブリックキーとプライベートキーのペアを使用して DKIM 認証を設定することもできます。このプロセスは、「*Bring Your Own DKIM*(*BYODKIM*)」として知られています。 BYODKIM では、単一の DNS レコードを使用してドメインの DKIM 認証を設定できます。一方 Easy DKIM では、3 つの個別の DNS レコードを発行する必要があります。さらに、BYODKIM を使用すると、ドメインの DKIM キーを必要な回数だけローテーションできます。 **Topics** + [ステップ 1: キーペアを作成する](#send-email-authentication-dkim-bring-your-own-create-key-pair) + [ステップ 2: DNS プロバイダーのドメイン設定にセレクタおよびパブリックキーを追加する](#send-email-authentication-dkim-bring-your-own-update-dns) + [ステップ 3: BYODKIM を使用するようにドメインを設定し、検証する](#send-email-authentication-dkim-bring-your-own-configure-identity) **警告** 現在 Easy DKIM が有効になっていて、BYODKIM に移行している場合、BYODKIM のセットアップ中で、DKIM ステータスが保留中になっている間、Amazon SES は Easy DKIM を使用してメールに署名しないことに注意してください。BYODKIM を有効にする電話を (API またはコンソールを介して) かけたときと SES が DNS 設定を確認できるときまでの間に、SES によって DKIM 署名なしで E メールが送信されることがあります。したがって、中間ステップを使用して、一方の DKIM 署名方法からもう一方の DKIM 署名方法に移行する (例えば、Easy DKIM を有効にしてドメインのサブドメインを使用し、BYODKIM 検証に合格したら削除する) か、アプリケーションのダウンタイム中にこのアクティビティを実行することをお勧めします (存在する場合)。 ## ステップ 1: キーペアを作成する 独自の DKIM 機能を使用するには、まず RSA キーペアを作成する必要があります。 生成するプライベートキーは、PKCS \$11 または PKCS \$18 形式で、少なくとも 1024 ビットの RSA 暗号化と最大 2048 ビットを使用し、base64 [(PEM)](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) エンコードを使用してエンコードする必要があります。DKIM 署名キーの長さとその変更方法の詳細は、[DKIM 署名キーの長さ](send-email-authentication-dkim.md#send-email-authentication-dkim-1024-2048)を参照してください。 **注記** プライベートキーが最低 1024 ビットの RSA 暗号化、最大 2048 ビットで、base64 [(PEM)](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) エンコーディングを使用して生成されている限り、サードパーティーのアプリケーションおよびツールを使用して RSA キーペアを生成できます。 次の手順では、ほとんどの Linux、macOS、または Unix オペレーティングシステムに組み込まれている `openssl genrsa` コマンドを使用してキーペアを作成するコード例では、自動的に base64 [(PEM)](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail) エンコードが使用されます。 **Linux、macOS、またはUnix コマンドラインからキーペアを作成するには** 1. コマンドラインで、以下のコマンドを入力して、*nnnn*を少なくとも1024のビット長で、2048までのビット長のプライベートキーに置き換えます。 ``` openssl genrsa -f4 -out private.key nnnn ``` 1. コマンドラインで、以下のコマンドを入力してパブリックキーを生成します。 ``` openssl rsa -in private.key -outform PEM -pubout -out public.key ``` ## ステップ 2: DNS プロバイダーのドメイン設定にセレクタおよびパブリックキーを追加する キーペアを作成したので、パブリックキーを TXT レコードとしてドメインの DNS 設定に追加する必要があります。 **ドメインの DNS 設定にパブリックキーを追加するには** 1. DNS またはホスティングプロバイダーの管理コンソールにサインインします。 1. ドメインの DNS 設定に新しいテキストレコードを追加します。レコードは、次の形式を使用する必要があります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ses/latest/dg/send-email-authentication-dkim-bring-your-own.html) 上の例に、以下の変更を加えます。 + *selector*は、キーを識別する一意の名前に置き換えます。 **注記** いくつかの DNS プロバイダーでは、レコード名に下線 (\$1) を含めることが許可されていません。ただし、DKIM レコード名には下線が必要となります。DNS プロバイダーがレコード名に下線を含めることを許可しない場合、プロバイダーのカスタマーサポートにお問い合わせください。 + *example.com*をドメインに置き換えます。 + 上記の [*Value*] (値) 列に示すように、*yourPublicKey* を、以前に作成したパブリックキーに置き換え、プレフィックス `p=` を含めます。 **注記** パブリックキーを DNS プロバイダーに公開 (追加) するときは、次のようにフォーマットする必要があります。 生成されたパブリックキーの最初と最後の行 (それぞれ `-----BEGIN PUBLIC KEY-----` と `-----END PUBLIC KEY-----`) を削除する必要があります。さらに、生成されたパブリックキーの改行を削除する必要があります。結果の値は、スペースや改行を含まない文字列になります。 上記の表の [*Value*] (値) 列に示すように、プレフィックス `p=` を含める必要があります。 プロバイダーによって、DNS レコードを更新する手順は異なります。次の表には、いくつかの広く使用されている DNS プロバイダーに関するドキュメントへのリンクが含まれています。このリストは網羅的なものではなく、推奨を意味するものでもありません。同様に、DNS プロバイダーがリストされていない場合、Amazon SES でドメインを使用できないことを意味するものでもありません。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ses/latest/dg/send-email-authentication-dkim-bring-your-own.html) ## ステップ 3: BYODKIM を使用するようにドメインを設定し、検証する BYODKIM は、新しいドメイン (現在 Amazon SES を経由した E メールの送信に使用していないドメイン) と既存のドメイン (コンソールまたは AWS CLIを使って、Amazon SES を介して設定済みのドメイン) の両方に対して設定できます。このセクション AWS CLI の手順を使用する前に、まず をインストールして設定する必要があります AWS CLI。詳細については、[AWS Command Line Interface 「 ユーザーガイド](https://docs.aws.amazon.com/cli/latest/userguide/)」を参照してください。 ### オプション 1: BYODKIM を使用する新しいドメイン ID を作成する このセクションでは、BYODKIM を使用する新しいドメイン ID を作成する手順について説明します。新しいドメイン ID とは、Amazon SES を使用して E メールを送信するように設定していないドメインです。 BYODKIM を使用するように既存のドメインを設定する場合は、代わりに「[オプション 2: 既存のドメイン ID を設定する](#send-email-authentication-dkim-bring-your-own-configure-identity-existing-domain)」の手順を実行します。 **コンソールから BYODKIM を使用して ID を作成するには** + 「[ドメイン ID の作成](creating-identities.md#verify-domain-procedure)」の手順に従い、ステップ 8 に到達したら、BYODKIM 固有の指示に従います。 **から BYODKIM を使用して ID を作成するには AWS CLI** 新しいドメインを設定するには、Amazon SES API で`CreateEmailIdentity` オペレーションを実行します。 1. テキストエディタで、次のコードを貼り付けます。 ``` { "EmailIdentity":"example.com", "DkimSigningAttributes":{ "DomainSigningPrivateKey":"privateKey", "DomainSigningSelector":"selector" } } ``` 上の例に、以下の変更を加えます。 + *example.com*を、作成するドメインに置き換えます。 + *privateKey*をプライベートキーに置き換えます。 **注記** 生成されたプライベートキーの最初と最後の行 (それぞれ `-----BEGIN PRIVATE KEY-----` と `-----END PRIVATE KEY-----`) を削除する必要があります。さらに、生成されたプライベートキーの改行を削除する必要があります。結果の値は、スペースや改行を含まない文字列になります。 + *selector*は、ドメインの DNS 設定で TXT レコードを作成したときに指定した一意のセレクタに置き換えます。 終了したら、`create-identity.json`としてファイルを保存します。 1. コマンドラインで以下のコマンドを入力します。 ``` aws sesv2 create-email-identity --cli-input-json file://path/to/create-identity.json ``` 上記のコマンドで、*path/to/create-identity.json*を、前のステップで作成したファイルの完全なパスに置き換えます。 ### オプション 2: 既存のドメイン ID を設定する このセクションでは、BYODKIM を使用するために既存のドメイン ID を更新する手順について説明します。既存のドメイン ID は、Amazon SES を使用して E メールを送信するようにすでに設定されているドメインです。 **コンソールから BYODKIM を使用してドメイン ID を更新するには** 1. AWS マネジメントコンソール にサインインし、Amazon SES コンソール ([https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)) を開きます。 1. ナビゲーションペインの**設定**で、**ID の検証**を選択します。 1. ID のリストで、**ID のタイプ**が*ドメイン*であるIDを選択します。 **注記** ドメインを作成または検証する必要がある場合は、「[ドメイン ID の作成](creating-identities.md#verify-domain-procedure)」を参照してください。 1. [**認証**] タブの [**DomainKeys Identified Mail (DKIM)**] ペインで、[**編集**] を選択します。 1. [**DKIM の詳細設定**] ペインで、[**ID のタイプ**] フィールドの [**DKIM 認証トークン (BYODKIM) の提供**] ボタンを選択します。 1. [**プライベートキー**] に、以前に生成したプライベートキーを貼り付けます。 **注記** 生成されたプライベートキーの最初と最後の行 (それぞれ `-----BEGIN PRIVATE KEY-----` と `-----END PRIVATE KEY-----`) を削除する必要があります。さらに、生成されたプライベートキーの改行を削除する必要があります。結果の値は、スペースや改行を含まない文字列になります。 1. **セレクタ名**については、ドメインの DNS 設定で指定したセレクタの名前を入力します。 1. **DKIM 署名**フィールドで、**[Enabled]**ボックスにチェックを入れます。 1. [**Save changes**] をクリックします。 **から BYODKIM を使用してドメイン ID を更新するには AWS CLI** 既存のドメインを設定するには、Amazon SES API での`PutEmailIdentityDkimSigningAttributes`オペレーションを使用します。 1. テキストエディタで、次のコードを貼り付けます。 ``` { "SigningAttributes":{ "DomainSigningPrivateKey":"privateKey", "DomainSigningSelector":"selector" }, "SigningAttributesOrigin":"EXTERNAL" } ``` 上の例に、以下の変更を加えます。 + *privateKey*をプライベートキーに置き換えます。 **注記** 生成されたプライベートキーの最初と最後の行 (それぞれ `-----BEGIN PRIVATE KEY-----` と `-----END PRIVATE KEY-----`) を削除する必要があります。さらに、生成されたプライベートキーの改行を削除する必要があります。結果の値は、スペースや改行を含まない文字列になります。 + *selector*は、ドメインの DNS 設定で TXT レコードを作成したときに指定した一意のセレクタに置き換えます。 終了したら、`update-identity.json`としてファイルを保存します。 1. コマンドラインで以下のコマンドを入力します。 ``` aws sesv2 put-email-identity-dkim-signing-attributes --email-identity example.com --cli-input-json file://path/to/update-identity.json ``` 上のコマンドに、以下の変更を加えます。 + *path/to/update-identity.json*を、前のステップで作成したファイルへの完全なパスに置き換えます。 + *example.com*を、更新するドメインに置き換えます。 ### BYODKIM を使用するドメインの DKIM ステータスを検証する **コンソールからドメインの DKIM ステータスを検証するには** BYODKIM を使用するようにドメインを設定したら、SES コンソールを使用して、DKIM が正しく設定されていることを検証できます。 1. AWS マネジメントコンソール にサインインし、Amazon SES コンソール ([https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)) を開きます。 1. ナビゲーションペインの**設定**で、**検証済み ID** を選択します。 1. ID のリストで、検証する DKIM ステータスの ID を選択します。 1. DNS 設定への変更が反映されるまでに最大 72 時間かかる場合があります。Amazon SES がドメインの DNS 設定の中から必要な DKIM レコードをすべて検出するとすぐに、検証プロセスは完了します。すべてが正しく設定されていれば、**[DomainKeys Identified Mail (DKIM)]** ペインで、ドメインの **[DKIM の設定]** フィールドには **[成功]** と表示され、**[概要]** ペインで、**[ID ステータス]** フィールドには **[検証済み]** と表示されます。 **を使用してドメインの DKIM ステータスを確認するには AWS CLI** BYODKIM を使用するようにドメインを設定したら、GetEmailIdentity オペレーションを実行して、DKIM が正しく設定されていることを検証できます。 + コマンドラインで以下のコマンドを入力します。 ``` aws sesv2 get-email-identity --email-identity example.com ``` 上記のコマンドで、*example.com*をドメインに置き換えます。 このコマンドは、次の例のようなセクションを含む JSON オブジェクトを返します。 ``` { ... "DkimAttributes": { "SigningAttributesOrigin": "EXTERNAL", "SigningEnabled": true, "Status": "SUCCESS", "Tokens": [ ] }, ... } ``` BYODKIMは、以下のすべてに該当する場合、ドメインに対して適切に設定されています。 + `SigningAttributesOrigin`プロパティの値は`EXTERNAL`です。 + `SigningEnabled`の値は`true`です。 + `Status`の値は`SUCCESS`です。 # Easy DKIM と BYODKIM の管理 Easy DKIM または BYODKIM で認証された ID の DKIM 設定は、ウェブベースの Amazon SES コンソールを使用するか、Amazon SES API を使用して管理できます。これらのいずれかの方法を使用して ID の DKIM レコードを取得するか、または、ID に対して DKIM 署名を有効または無効にすることができます。 ## ID の DKIM レコードを取得する Amazon SES コンソールを使用して、ドメインあるいは E メールアドレスの DKIM レコードをいつでも取得できます。 **コンソールを使用して、ID の DKIM レコードを取得するには** 1. AWS マネジメントコンソール にサインインし、Amazon SES コンソール ([https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)) を開きます。 1. ナビゲーションペインの**設定**で、**検証済み ID** を選択します。 1. ID のリストで、DKIM レコードを取得する ID を選択します。 1. ID詳細ページの**認証**タブで、**DNS レコードを表示する**を拡大します。 1. Easy DKIM を使用した場合は 3 つの CNAME レコードをコピーし、このセクションに表示されている BYODKIM を使用した場合は TXT レコードをコピーします。または、[**レコードセットを CSV としてダウンロード**] を選択してコンピューターにこのレコードのコピーを保存することもできます。 次の図で、**[View DNS records]** (DNS レコードの表示) セクションを拡大して、Easy DKIM に関連付けられた CNAME レコードの例を示します。 ![\[\]](http://docs.aws.amazon.com/ja_jp/ses/latest/dg/images/dkim_existing_dns.png) Amazon SES API を使用して、ID の DKIM レコードを取得することもできます。API とやり取りする一般的な方法は、 AWS CLIを使用することです。 **を使用して ID の DKIM レコードを取得するには AWS CLI** 1. コマンドラインから、以下のコマンドを入力します。 ``` aws ses get-identity-dkim-attributes --identities "example.com" ``` 前述の例で、*example.com* を DKIM レコードを取得する ID で置き換えます。E メールアドレスまたはドメインを指定できます。 1. このコマンドの出力には、次の例に示すように、`DkimTokens`セクションが含まれています。 ``` { "DkimAttributes": { "example.com": { "DkimEnabled": true, "DkimVerificationStatus": "Success", "DkimTokens": [ "hirjd4exampled5477y22yd23ettobi", "v3rnz522czcl46quexamplek3efo5o6x", "y4examplexbhyhnsjcmtvzotfvqjmdqoj" ] } } } ``` トークンを使用してドメインの DNS 設定に追加する CNAME レコードを作成します。CNAME レコードを作成するには、次のテンプレートを使用します。 ``` 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 ``` *token1* の各インスタンスを、`get-identity-dkim-attributes` コマンドを実行したときに受け取ったリストの最初のトークンに置き換え、*token2* のインスタンスすべてを、リストの 2 番目のトークンに置き換え、*token3* のインスタンスすべてを、リストの 3 番目のトークンに置き換えます。 例えば、前述の例に示されるトークンにこのテンプレートを適用すると、次のレコードが生成されます。 ``` 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 ``` **注記** すべての がデフォルトの SES DKIM ドメイン AWS リージョン を使用するわけではありません`dkim.amazonses.com`。リージョンがリージョン固有の DKIM ドメインを使用しているかどうかを確認するには、 の [DKIM ドメインテーブル](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_dkim_domains)を確認してください*AWS 全般のリファレンス*。 ## ID の Easy DKIM を無効にする Amazon SES コンソールを使用して、ID の DKIM 認証を素早く無効にできます。 **ID で DKIM を無効にするには** 1. AWS マネジメントコンソール にサインインし、Amazon SES コンソール ([https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)) を開きます。 1. ナビゲーションペインの**設定**で、**検証済み ID** を選択します。 1. ID のリストで、DKIM を無効にする ID を選択します。 1. **DomainKeys アイデンティファイドメール (DKIM)**コンテナの[**認証**]タブで、**編集**を選択します。 1. **[Advanced DKIM settings]** (DKIM の詳細設定) で、**DKIM 署名**フィールドの **[Enabled]** (有効) ボックスをオフにします。 また、Amazon SES API を使用して、ID の DKIM を無効にすることもできます。API とやり取りする一般的な方法は、 AWS CLIを使用することです。 **を使用して ID の DKIM を無効にするには AWS CLI** + コマンドラインから、以下のコマンドを入力します。 ``` aws ses set-identity-dkim-enabled --identity example.com --no-dkim-enabled ``` 前述の例で、*example.com* を DKIM を無効にする ID で置き換えます。E メールアドレスまたはドメインを指定できます。 ## ID の Easy DKIM を有効にする 前に ID で DKIM を無効化した場合、Amazon SES コンソールを使用して再度有効化できます。 **ID で DKIM を有効にするには** 1. AWS マネジメントコンソール にサインインし、Amazon SES コンソール ([https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)) を開きます。 1. ナビゲーションペインの**設定**で、**検証済み ID** を選択します。 1. ID のリストで、DKIM を有効にする ID を選択します。 1. **認証**タブの**DomainKeys アイデンティファイドメール (DKIM)**コンテナで、**編集**を選択します。 1. **DKIM の詳細設定**で、**DKIM 署名**フィールドの[**Enabled**]ボックスにチェックを入れます。 また、Amazon SES API を使用して、ID の DKIM を有効にすることもできます。API とやり取りする一般的な方法は、 AWS CLIを使用することです。 **を使用して ID の DKIM を有効にするには AWS CLI** + コマンドラインから、以下のコマンドを入力します。 ``` aws ses set-identity-dkim-enabled --identity example.com --dkim-enabled ``` 前述の例で、*example.com* を DKIM を有効にする ID で置き換えます。E メールアドレスまたはドメインを指定できます。 ## E メールアドレス ID に継承された DKIM 署名を上書きする このセクションでは、Amazon SES で検証済みの特定の E メールアドレス ID に、親ドメインから継承された DKIM 署名プロパティを上書き (無効化または有効化) する方法を説明します。DNS 設定はドメインレベルで構成されているため、既に所有するドメインに属する E メールアドレス ID に対してのみこれを行うことができます。 **重要** E メールアドレス ID の DKIM 署名を無効化/有効化することはできません。 所有していないドメインの場合。例えば、*gmail.com* や *hotmail.com* アドレスの DKIM 署名を切り替えることはできません。 所有するドメインだが、Amazon SES でまだ検証されていない場合。 所有するドメインだが、そのドメインで DKIM 署名が有効になっていない場合。 このセクションは、以下のトピックで構成されます。 + [継承された DKIM 署名プロパティについて理解する](#dkim-easy-setup-email-key-points-mng) + [E メールアドレス ID に DKIM 署名を上書きする (コンソール)](#override-dkim-email-console-mng) + [E メールアドレス ID に DKIM 署名を上書きする (AWS CLI)](#override-dkim-email-cli-mng) ### 継承された DKIM 署名プロパティについて理解する まず、Easy DKIM または BYODKIM が使用されているかどうかにかかわらず、そのドメインが DKIM で設定されている場合、E メールアドレス ID が親ドメインから DKIM 署名プロパティを継承することを理解することが重要です。したがって、E メールアドレス ID で DKIM 署名を無効または有効にすると、次の重要な点に基づいてドメインの DKIM 署名プロパティが上書きされます。 + E メールアドレスが属するドメインで既に DKIM をセットアップしている場合には、E メールアドレス ID にも同じく DKIM 署名を有効にする必要はありません。 + ドメインで DKIM をセットアップする場合、Amazon SES が親ドメインから継承された DKIM プロパティを介して、このドメインのすべてのアドレスからのすべての E メールを自動的に認証します。 + 特定の E メールアドレス ID の DKIM 設定により、そのアドレスが属する*親ドメインまたはサブドメイン (該当する場合) の設定が自動的に上書きされます*。 E メールアドレス ID の DKIM 署名プロパティが親ドメインから継承されるため、これらのプロパティを上書きする場合は、次の表で説明された上書きの階層ルールに注意する必要があります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ses/latest/dg/send-email-authentication-dkim-easy-managing.html) 通常、DKIM 署名の無効化はお勧めしません。送信者の評価を損うリスクがあるだけでなく、送信したメールが迷惑メールやスパムフォルダに移動されたり、ドメインが偽装されたりするリスクが高まるためです。 ただし、特定のユースケースや、DKIM 署名を永続的または一時的に無効にしたり、後で再有効化したりする必要があるような通常とは異なるビジネス上の意思決定がなされた場合に備えて、ドメインから継承された DKIM 署名プロパティを E メールアドレス ID に上書きするための機能があります。 ### E メールアドレス ID に DKIM 署名を上書きする (コンソール) 以下の SES コンソールの手順では、Amazon SES で既に検証済みの特定の E メールアドレス ID に、親ドメインから継承された DKIM 署名プロパティを上書き (無効化または有効化) する方法を説明しています。 **コンソールを使用して E メールアドレス ID の DKIM 署名を無効/有効にするには** 1. AWS マネジメントコンソール にサインインし、Amazon SES コンソール ([https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)) を開きます。 1. ナビゲーションペインの**設定**で、**検証済み ID** を選択します。 1. ID のリストで、**[Identity type]** (ID のタイプ) が *[Email address]* (E メールアドレス) であり、認証済みドメインのいずれかに属する ID を選択します。 1. **DomainKeys アイデンティファイドメール (DKIM)**コンテナの[**認証**]タブで、**編集**を選択します。 **注記** **[Authentication]** (認証) タブは、選択した電子メールアドレス ID が SES によって既に検証済みのドメインに属している場合にのみ表示されます。ドメインをまだ検証していない場合は、「[ドメイン ID の作成](creating-identities.md#verify-domain-procedure)」を参照してください。 1. **[Advanced DKIM settings]** (DKIM の詳細設定) の **[DKIM signatures]** (DKIM 署名) フィールドで、**[Enabled]** (有効) チェックボックスをオフにして DKIM 署名を無効にします。DKIM 署名を再度有効にするにはオンにします (以前に上書きされていた場合)。 1. **[Save changes]** (変更の保存) をクリックします。 ### E メールアドレス ID に DKIM 署名を上書きする (AWS CLI) 次の例では、SES AWS CLI で検証済みの特定の E メールアドレス ID の親ドメインから継承された DKIM 署名プロパティを上書き (無効化または有効化) する SES API コマンドとパラメータで を使用します。 **を使用して E メールアドレス ID の DKIM 署名を無効化/有効化するには AWS CLI** + 例えば、*example.com* ドメインを所有していて、そのドメインの E メールアドレスのいずれかに対して DKIM 署名を無効にする場合は、コマンドラインで次のコマンドを入力します。 ``` aws sesv2 put-email-identity-dkim-attributes --email-identity marketing@example.com --no-signing-enabled ``` 1. *marketing@example.com* を DKIM 署名を無効にする E メールアドレス ID に置き換えます。 1. `--no-signing-enabled` を使用すると、DKIM 署名が無効化されます。DKIM 署名を再度有効にするには、`--signing-enabled` を使用します。 # Amazon SES 内で手動での DKIM 署名 Easy DKIM を使用する代わりに、手動で DKIM 署名をメッセージに追加し、Amazon SES を使用してこのメッセージを送信することもできます。手動でメッセージを署名することを選択する場合、まず DKIM 署名を作成する必要があります。メッセージと DKIM 署名を作成したら、[SendRawEmail](https://docs.aws.amazon.com/ses/latest/APIReference/API_SendRawEmail.html) API を使用してメッセージを送信できます。 E メールを手動で署名する場合、次の要素を考慮してください。 + Amazon SES を使用して送信するすべてのメッセージには、*amazonses.com*のドメインの署名を参照する DKIM ヘッダーが含まれています(つまり、`d=amazonses.com`という文字列が含まれています)。そのため、メッセージを手動で署名する場合、そのメッセージには、ドメインのヘッダーと *amazonses.com*のためにAmazon SESが自動で作成するヘッダーという、*2つ*のDKIM ヘッダーが含まれます。 + Amazon SES は、メッセージに手動で追加した DKIM 署名を検証しません。メッセージの DKIM 署名にエラーがある場合、このメッセージはEメールプロバイダーによって拒否される可能性があります。 + メッセージに署名する場合は、少なくとも 1024 ビットのビット長を使用する必要があります。 + 次のフィールドには署名しないでください。メッセージ ID、日付、Return-Path、Bounces-To。 **注記** Amazon SES SMTP インタフェースでの E メールの送信に E メールクライアントを使用する場合、クライアントはメッセージで自動的に DKIM 署名を実行することがあります。一部のクライアントは上述のフィールドのいずれかに署名することがあります。デフォルトで署名されたフィールドについての情報は、Eメールのクライアントのドキュメンテーションを参照してください。 # Amazon SES における SPF を使った E メールの認証 *Sender Policy Framework*(SPF) は、E メールのなりすましを防ぐために設計された E メールの検証標準です。ドメイン所有者は SPF を使用して、自分のドメインからメールを送信できるサーバーをメールプロバイダーに通知します。SPF は[RFC 7208](https://tools.ietf.org/html/rfc7208)で定義されています。 Amazon SES から送信するメッセージには、MAIL FROM ドメインとして `amazonses.com` のサブドメインが自動的に使用されます。デフォルトの MAIL FROM ドメインがメールを送信するアプリケーション (この場合 Amazon SES) と一致するため、これらのメッセージは SPF (Sender Policy Framework) 認証に合格します。したがって、SES では、SPF は暗黙的に自動設定されます。 SES のデフォルトの MAIL FROM ドメインを使用せず、所有しているドメインのサブドメインを使用する場合、SES では*カスタム* MAIL FROM ドメインを使用すると認識されます。そのためには、カスタム MAIL FROM ドメインに独自の SPF レコードを公開する必要があります。また、SES ではカスタム MAIL FROM ドメインがメールプロバイダーから送信されたバウンスと苦情の通知を受信できるように、MX レコードを設定する必要があります。 **SPF 認証をセットアップする方法の説明** SPF を使用してドメインを設定する手順と、MX レコードと SPF (タイプ TXT) レコードを発行する方法は、「[カスタムの MAIL FROM ドメインを使用する](mail-from.md)」で説明されています。 # カスタムの MAIL FROM ドメインを使用する E メールを送信する際、送信元を示す 2 つのアドレスを使用します。メッセージの受取人に表示される差出人アドレスと、メッセージの発信元を示す MAIL FROM アドレスです。MAIL FROM アドレスは、*envelope sender*、*envelope from*、*bounce address*、または *Return Path* アドレスと呼ばれることもあります。メールサーバーは MAIL FROM アドレスを使用して、バウンスメッセージやその他のエラー通知を返します。MAIL FROM アドレスは通常、受取人がメッセージのソースコードを表示する場合にのみ表示できます。 Amazon SES では、独自の (カスタム) ドメインを指定する場合を除き、送信するメッセージの MAIL FROM ドメインがデフォルト値に設定されます。このセクションでは、カスタム MAIL FROM ドメインを設定する利点について説明し、設定手順を示します。 ## カスタムの MAIL FROM ドメインを使用する理由 Amazon SES から送信するメッセージには、MAIL FROM ドメインとして `amazonses.com` のサブドメインが自動的に使用されます。デフォルトの MAIL FROM ドメインが E メールを送信するアプリケーション (この場合 SES )と一致するため、これらのメッセージは SPF (Sender Policy Framework) 認証に合格します。 SES のデフォルトの MAIL FROM ドメインを使用せず、所有しているドメインのサブドメインを使用したい場合、SES では*カスタム* MAIL FROM ドメインを使用と呼んでいます。そのためには、カスタム MAIL FROM ドメインに独自の SPF レコードを公開する必要があります。また、SES ではカスタム MAIL FROM ドメインが E メールプロバイダーから送信されたバウンスと苦情の通知を受信できるように、MX レコードを設定する必要があります。 カスタム MAIL FROM ドメインを使用すると、SPF または DKIM、あるいはその両方を使用して、[ドメインベースのメッセージ、レポート、および適合性 (DMARC)](send-email-authentication-dmarc.md) に合格することができます。DMARC により、送信者のドメインは、ドメインから送信された E メールが 1 つ以上の認証システムによって保護されていることを示すことができます。DMARC 認証に合格するには、[SPF による DMARC への準拠](send-email-authentication-dmarc.md#send-email-authentication-dmarc-spf) および [DKIM を介した DMARC への準拠](send-email-authentication-dmarc.md#send-email-authentication-dmarc-dkim) の 2 つの方法があります。 ## カスタム MAIL FROM ドメインの選択 以下、*MAIL FROM ドメイン*という用語は常に、ユーザーが所有しているドメインのサブドメインを指します。カスタム MAIL FROM ドメインに使用するこのサブドメインは、その他の目的では使用してはならず、以下の要件を満たしている必要があります。 + MAIL FROM ドメインは、E メールの送信元とする検証済み ID (E メールアドレスまたはドメイン) の親ドメインのサブドメインである必要があります。 + MAIL FROM ドメインには、E メールの送信に使用するサブドメインを設定することはできません。 + MAIL FROM ドメインには、E メールの受信に使用するサブドメインを指定することはできません。 ## カスタム MAIL FROM ドメインで SPF を使用する *Sender Policy Framework*(SPF) は、E メールのなりすましを防ぐために設計された E メールの検証標準です。カスタム MAIL FROM ドメインに SPF を設定することにより、カスタム MAIL FROM ドメインから E メールを送信できるサーバーを E メールプロバイダーに通知できます。SPF は [RFC 7208](https://tools.ietf.org/html/rfc7208) で定義されています。 SPF を設定するには、TXT レコードをカスタム MAIL FROM ドメインの DNS 設定に公開します。このレコードには、カスタム MAIL FROM ドメインを使用して E メールを送信することを許可するサーバーの一覧が含まれます。E メールプロバイダーは、カスタム MAIL FROM ドメインからメッセージを受信すると、ドメインの DNS レコードをチェックして、承認されたサーバーから E メールが送信されたことを確認します。 DMARC に準拠する方法としてこの SPF レコードを使用する場合、差出人アドレスのドメインが MAIL FROM ドメインと一致する必要があります。「[SPF による DMARC への準拠](send-email-authentication-dmarc.md#send-email-authentication-dmarc-spf)」を参照してください。 次のセクション [カスタムの MAIL FROM ドメインの設定](#mail-from-set) では、カスタム MAIL FROM ドメインに SPF を設定する方法について説明します。 ## カスタムの MAIL FROM ドメインの設定 カスタム MAIL FROM ドメインを設定するプロセスでは、ドメインの DNS 設定にレコードを追加する必要があります。SES では、ドメインがメールプロバイダーから送信されるバウンス通知と苦情通知を受信できるようにするには、MX レコードを公開する必要があります。また、ドメインから E メールを送信する許可が Amazon SES にあることを証明するためにも、SPF (TXT 型) レコードを発行する必要があります。 ドメイン全体または個別のメールアドレスに対して、カスタム MAIL FROM ドメインを設定できます。次の手順は、Amazon SES コンソールを使用してカスタム MAIL FROM ドメインを設定する方法を示しています。[SetIdentityMailFromDomain](https://docs.aws.amazon.com/ses/latest/APIReference/API_SetIdentityMailFromDomain.html)API オペレーションを使用して、カスタム MAIL FROM ドメインを設定することもできます。 ### 検証済みドメインのカスタム MAIL FROM ドメインを設定する これらの手順では、ドメイン全体またはサブドメインに対してカスタム MAIL FROM ドメインを設定し、このドメイン上のアドレスから送信されるメッセージすべてがこのカスタム MAIL FROM ドメインを使用するように設定する方法を説明します。 **検証済みドメインが指定したカスタム MAIL FROM ドメインを使用するように設定するには** 1. Amazon SES コンソール ([https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)) を開きます。 1. 左側のナビゲーションペインの **[設定]** の下にある **[ID]** を選択します。 1. ID のリストで、設定する ID を選択します。その際、**ID のタイプ**を **[Domain]** (ドメイン)、**ステータス**を*[Verified]* (検証済み) にします。 1. **ステータス**が *[Unverified]* (未検証) の場合、[DNS プロバイダーでの DKIM ドメイン ID の検証](creating-identities.md#just-verify-domain-proc) の手順を完了させてから E メールアドレスのドメインを検証します。 1. **[カスタム MAIL FROM ドメイン]** ペインの画面下部で、**[編集]** を選択します。 1. **[General details]** (一般的な詳細) ペインで、次の操作を行います。 1. **[Use a custom MAIL FROM domain]** (カスタムの MAIL FROM ドメインを使用) チェックボックスをオンにします。 1. [**MAIL FROM ドメイン**] に、MAIL FROMドメインとして使用するサブドメインを入力します。 1. **[Behavior on MX failure]** (MX 障害時の動作) で、次のオプションのいずれかを選択します。 + **[Use default MAIL FROM domain]** (デフォルトの MAIL FROM ドメインを使用) – カスタムの MAIL FROM ドメインの MX レコードが正しくセットアップされていない場合、Amazon SES は `amazonses.com` のサブドメインを使用します。サブドメインは、Amazon SES AWS リージョン を使用する によって異なります。 + **メッセージ拒否** – カスタム MAIL FROM ドメインの MX レコードが正しくセットアップされていない場合、Amazon SES はエラー `MailFromDomainNotVerified` を返します。このドメインから送信しようとした E メールは自動的に拒否されます。 1. [**変更を保存する**] を選択すると、前の画面に戻ります。 1. カスタム MAIL FROM ドメインの DNS サーバーに MX および SPF (TXT 型) レコードを発行します。 [**Custom MAIL FROM domain**] (カスタムの MAIL FROM ドメイン) ペインで、[**Publish DNS records**] (DNS レコードの発行) テーブルに、ドメインの DNS 設定に発行 (追加) する必要がある MX および SPF (TXT 型) レコードが表示されます。これらのレコードでは、次の表に示す形式を使用します。 **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ses/latest/dg/mail-from.html) 上記のレコードでは、以下のようになります。 + *subdomain*.*domain*.*com* には、MAIL FROM サブドメインが入力されます + *リージョン*には、MAIL FROM ドメインを検証する AWS リージョン の名前 (`us-west-2`、`us-east-1`、 `eu-west-1`など) が入力されます。 + MX 値と共に表示されている数値 *10* は、メールサーバーの優先順位であり、DNS プロバイダーの GUI で指定された別の値フィールドに入力する必要があります。 + SPF の TXT レコード値には通常引用符を含める必要がありますが、一部の DNS プロバイダーでは不要です。 [**Publish DNS records**] (DNS レコードの発行) テーブルで、各値の横にあるコピーアイコンを選択して MX レコードと SPF レコード (TXT 型) をコピーし、DNS プロバイダーの GUI の対応するフィールドに貼り付けます。または、[**レコードセットを CSV としてダウンロード**] を選択してコンピューターにこのレコードのコピーを保存することもできます。 **重要** MX および SPF (TXT タイプ) レコードを発行する具体的な手順は、DNS またはホスティングプロバイダーによって異なります。お客様のドメインの DNS 設定へのこれらのレコードの追加の詳細については、ご利用のプロバイダーのドキュメントを参照するか、ご利用のプロバイダーにお問い合わせください。 Amazon SES でカスタムの MAIL FROM ドメインを正しくセットアップするには、MAIL FROM ドメインの DNS サーバーに、MX レコードを 1 件のみ発行する必要があります。MAIL FROM ドメインに複数の MX レコードがあると、Amazon SES でのカスタム MAIL FROM のセットアップは失敗します。 Route 53 が MAIL FROM ドメインの DNS サービスを提供し、Route 53 に使用するのと同じアカウント AWS マネジメントコンソール で にサインインしている場合は、**Route 53 を使用してレコードを発行**を選択します。DNS レコードは、ドメインの DNS 設定に自動的に適用されます。 別の DNS プロバイダーを使用する場合は、DNS レコードを MAIL FROM ドメインの DNS サーバーに手動で公開する必要があります。DNS レコードをドメインの DNS サーバーに追加する手順は、ウェブホスティングサービスまたは DNS プロバイダーによって異なります。 ドメインの DNS レコードを公開する手順は、使用している DNS プロバイダーによって異なります。次の表には、いくつかの広く使用されている DNS プロバイダーに関するドキュメントへのリンクが含まれています。このリストは網羅的なものではなく、推奨を意味するものでもありません。同様に、DNS プロバイダーがリストされていない場合、MAIL FROM ドメイン設定をサポートしないことを意味するものでもありません。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ses/latest/dg/mail-from.html) レコードが適切に配置されていることを Amazon SES が検出すると、カスタム MAIL FROM ドメインが正常に設定されたことを通知するメールが送信されます。DNS プロバイダーによっては、Amazon SES が MX レコードを検出するまでに最大 72 時間の遅延が発生する場合があります。 ### 検証済みの E メールアドレスのカスタム MAIL FROM ドメインを設定する また、特定のメールアドレスにカスタム MAIL FROM ドメインを設定することもできます。E メールアドレスにカスタム MAIL FROM ドメインを設定するには、E メールアドレスが関連付けられているドメインの DNS レコードを変更する必要があります。 **注記** 自分が所有していないドメインのアドレスにカスタム MAIL FROM ドメインを設定することはできません (たとえば、`gmail.com`ドメインのアドレスにカスタム MAIL FROM ドメインを作成することはできません。 必要な DNS レコードをドメインに追加できないためです)。 **指定された MAIL FROM ドメインが確認済み E メールアドレスで使用されるように設定するには** 1. Amazon SES コンソール ([https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)) を開きます。 1. 左側のナビゲーションペインの **[設定]** の下にある **[ID]** を選択します。 1. ID のリストで、設定する ID を選択します。その際、**ID のタイプ**を **[Email address]** (E メールアドレス)、**ステータス**を*[Verified]* (検証済み) にします。 1. **ステータス**が *[Unverified]* (未検証) の場合、[E メールアドレス ID の検証](creating-identities.md#just-verify-email-proc) の手順を完了させてから E メールアドレスのドメインを検証します。 1. **[MAIL FROM Domain]** (MAIL FROM ドメイン) タブの、**[Custom MAIL FROM domain]** (カスタムの MAIL FROM ドメイン) ペインで **[Edit]** (編集) を選択します。 1. **[General details]** (一般的な詳細) ペインで、次の操作を行います。 1. **[Use a custom MAIL FROM domain]** (カスタムの MAIL FROM ドメインを使用) チェックボックスをオンにします。 1. [**MAIL FROM ドメイン**] に、MAIL FROMドメインとして使用するサブドメインを入力します。 1. **[Behavior on MX failure]** (MX 障害時の動作) で、次のオプションのいずれかを選択します。 + **[Use default MAIL FROM domain]** (デフォルトの MAIL FROM ドメインを使用) – カスタムの MAIL FROM ドメインの MX レコードが正しくセットアップされていない場合、Amazon SES は `amazonses.com` のサブドメインを使用します。サブドメインは、Amazon SES AWS リージョン を使用する によって異なります。 + **メッセージ拒否** – カスタム MAIL FROM ドメインの MX レコードが正しくセットアップされていない場合、Amazon SES は`MailFromDomainNotVerified`エラーを返します。この E メールアドレスから送信しようとした E メールは自動的に拒否されます。 1. [**変更を保存する**] を選択すると、前の画面に戻ります。 1. カスタム MAIL FROM ドメインの DNS サーバーに MX および SPF (TXT 型) レコードを発行します。 [**Custom MAIL FROM domain**] (カスタムの MAIL FROM ドメイン) ペインで、[**Publish DNS records**] (DNS レコードの発行) テーブルに、ドメインの DNS 設定に発行 (追加) する必要がある MX および SPF (TXT 型) レコードが表示されます。これらのレコードでは、次の表に示す形式を使用します。 **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ses/latest/dg/mail-from.html) 上記のレコードでは、以下のようになります。 + *subdomain*.*domain*.*com* には、MAIL FROM サブドメインが入力されます + *リージョン*には、MAIL FROM ドメインを検証する AWS リージョン の名前 (`us-west-2`、`us-east-1`、 `eu-west-1`など) が入力されます。 + MX 値と共に表示されている数値 *10* は、メールサーバーの優先順位であり、DNS プロバイダーの GUI で指定された別の値フィールドに入力する必要があります。 + SPF の TXT レコードの値には引用符を含める必要があります。 [**Publish DNS records**] (DNS レコードの発行) テーブルで、各値の横にあるコピーアイコンを選択して MX レコードと SPF レコード (TXT 型) をコピーし、DNS プロバイダーの GUI の対応するフィールドに貼り付けます。または、[**レコードセットを CSV としてダウンロード**] を選択してコンピューターにこのレコードのコピーを保存することもできます。 **重要** Amazon SES でカスタムの MAIL FROM ドメインを正しくセットアップするには、MAIL FROM ドメインの DNS サーバーに、MX レコードを 1 件のみ発行する必要があります。MAIL FROM ドメインに複数の MX レコードがあると、Amazon SES でのカスタム MAIL FROM のセットアップは失敗します。 Route 53 が MAIL FROM ドメインの DNS サービスを提供し、Route 53 に使用するのと同じアカウント AWS マネジメントコンソール で にサインインしている場合は、**Route 53 を使用してレコードを発行**を選択します。DNS レコードは、ドメインの DNS 設定に自動的に適用されます。 別の DNS プロバイダーを使用する場合は、DNS レコードを MAIL FROM ドメインの DNS サーバーに手動で公開する必要があります。DNS レコードをドメインの DNS サーバーに追加する手順は、ウェブホスティングサービスまたは DNS プロバイダーによって異なります。 ドメインの DNS レコードを公開する手順は、使用している DNS プロバイダーによって異なります。次の表には、いくつかの広く使用されている DNS プロバイダーに関するドキュメントへのリンクが含まれています。このリストは網羅的なものではなく、推奨を意味するものでもありません。同様に、DNS プロバイダーがリストされていない場合、MAIL FROM ドメイン設定をサポートしないことを意味するものでもありません。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ses/latest/dg/mail-from.html) レコードが適切に配置されていることを Amazon SES が検出すると、カスタム MAIL FROM ドメインが正常に設定されたことを通知するメールが送信されます。DNS プロバイダーによっては、Amazon SES が MX レコードを検出するまでに最大 72 時間の遅延が発生する場合があります。 ## Amazon SES でのカスタム MAIL FROM ドメインのセットアップ状態 カスタムの MAIL FROM ドメインを使用するようにアイデンティティを設定すると、DNS 設定内の必要な MX レコードを Amazon SES で検出するまでは、セットアップの状態が [pending] になります。Amazon SES で MX レコードを検出したかどうかで状態は変わります。次の表は、各状態に対応する E メール送信動作と Amazon SES のアクションの一覧です。状態が変化するたびに、Amazon SES は に関連付けられた E メールアドレスに通知を送信します AWS アカウント。 **** | State | E メール送信動作 | Amazon SES のアクション | | --- | --- | --- | | Pending | カスタムの MAIL FROM フォールバック設定を使用 | Amazon SES は、必要な MX レコードの検出を 72 時間試行します。検出できない場合、状態は "Failed" に変化します。 | | 成功 | カスタムの MAIL FROM ドメインを使用 | Amazon SES では、必要な MX レコードがあることを継続的に確認します。 | | TemporaryFailure | カスタムの MAIL FROM フォールバック設定を使用 | Amazon SES は、必要な MX レコードの検出を 72 時間試行します。検出できない場合、状態は "Failed" に変化します。検出できた場合、状態は "Success" に変化します。 | | 失敗 | カスタムの MAIL FROM フォールバック設定を使用 | Amazon SES は、必要な MX レコードを検出するための試行を停止しました。カスタムの MAIL FROM ドメインを使用するには、[カスタムの MAIL FROM ドメインの設定](#mail-from-set)のセットアッププロセスをやり直す必要があります。 | # Amazon SES の DMARC 認証プロトコルへの準拠 DMARC (Domain-based Message Authentication, Reporting and Conformance) は、SPF (Sender Policy Framework) および DKIM (DomainKeys Identified Mail) を使用して、E メールのなりすましやフィッシングを検出する、E メール認証プロトコルです。DMARC に準拠するには、メッセージを SPF または DKIM で認証する必要があります。理想的には、両方を DMARC で使用すると、E メール送信に関して可能な限り高いレベルの保護を確保できます。 SPF と DKIM の機能と、DMARC がこの 2 つを連携する方法を簡単に説明します。 + **SPF** – DNS が使用する DNS TXT レコードを介して、カスタム MAIL FROM ドメインに代わってメールを送信できるメールサーバーを特定します。受信者のメールシステムは、SPF TXT レコードを参照して、カスタムドメインからのメッセージが承認済みのメッセージングサーバーから送信されたかを判断します。基本的に、SPF はなりすまし防止目的で設計されているとはいえ、実際には SPF が影響を受けやすいなりすまし手法もあるため、DMARC とともに DKIM も使用する必要があります。 + **DKIM** – E メールヘッダーのアウトバウンドメッセージにデジタル署名を追加します。受信 E メールシステムは、このデジタル署名を使用して、受信する E メールがドメインが所有するキーによって署名されているかの検証に役立てます。ただし、受信 E メールシステムがメッセージを転送した場合、メッセージのエンベロープは SPF 認証を無効にするような方法で変更されます。デジタル署名は E メールヘッダーの一部であるため、E メールメッセージに保持されます。このため、メッセージがメールサーバー間で転送された場合でも、(メッセージコンテンツが変更されない限り) DKIM は機能します。 + **DMARC** – SPF と DKIM の少なくともいずれかでドメインのアライメントがとれていることを確認します。SPF と DKIM を単独で使用しても、送信元アドレスが認証されるかは保証されません (これは受信者が E メールクライアントで目にするメールアドレスです)。SPF は、MAIL FROM アドレスで指定されたドメインのみをチェックします (受信者には表示されません)。DKIM は、DKIM 署名で指定されたドメインのみをチェックします (これも受信者には表示されません)。DMARC は、SPF または DKIM のいずれかでドメインのアライメントが適切であることを求めることで、このような 2 つの問題に対処します。 + SPF が DMARC アライメントで適格になるには、送信元アドレスのドメインが MAIL FROM アドレス (Return-Path やエンベロープ送信元アドレスとも呼ばれます) のドメインと一致する必要があります。Return-Path (MAIL FROM) は、プロバイダー (SES) が所有するアドレスを使用して追跡するバウンスや苦情に使用されます。このため、転送されたメールの場合には削除され、ほぼ不可能です。またはサードパーティーの一括 E メールプロバイダー経由でメールを送信する場合にもほとんど不可能です。 + DKIM が DMARC アライメントに適格になるには、DKIM 署名で指定されたドメインが、送信元アドレスのドメインと一致する必要があります。お客様の代理でメールを送信するサードパーティーの送信者やサービスを使用する場合、サードパーティーの送信者が DKIM 署名向けに適切に設定され、お客様のドメイン内に適切な DNS レコードが追加されていることを確認することで、これを実現できます。その後、受信側メールサーバーは、サードパーティーから送信されたメールをドメイン内でアドレスを使用する権限が付与されたユーザーから送信されたメールであるかのように検証を行うことができます。 **DMARC を使用した仕組みの構築** 上記の DMARC アライメントチェックは、SPF、DKIM、DMARC すべてが連携し、ドメインの信頼性と受信トレイへの E メールの配信を向上させる方法です。DMARC は、受信者に表示される送信元アドレスが SPF または DKIM のいずれかによって認証されることを必須とすることでこれを実現します。 + 説明したとおり SPF または DKIM チェックのいずれかまたは両方で適格性が認められた場合、メッセージは DMARC で適格性が認められます。 + 説明したとおり SPF または DKIM チェックの両方で適格性が認められないと、メッセージは DMARC で不適格と見なされます。 したがって、DMARC が送信メールを認証する可能性を最大限に向上するには、SPF と DKIM の両方が必要であり、これら 3 つをすべて活用することで、送信ドメインが完全に保護されることが保証されます。 DMARC を使用する場合、ユーザー設定のポリシーを使用して、DMARC 認証に失敗した E メールの処理方法を E メールサーバーに指示することもできます。これについては、次のセクション「[ドメインの DMARC ポリシーのセットアップ](#send-email-authentication-dmarc-dns)」で説明します。このセクションには、送信する E メールが SPF と DKIM の両方を介して DMARC 認証プロトコルに準拠するように SES ドメインを設定する方法に関する情報が提供されています。 ## ドメインの DMARC ポリシーのセットアップ DMARC をセットアップするには、ドメインの DNS 設定を変更する必要があります。ドメインの DNS 設定に、ドメインの DMARC 設定を指定する TXT レコードが含まれている必要があります。DNS 設定に TXT レコードを追加する手順は、DNS またはホスティングプロバイダーによって異なります。Route 53 を使用する場合、[Amazon Route 53 デベロッパーガイド](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)の「*レコードで作業*」を参照してください。別のプロバイダーを使用する場合、DNS 設定についてはプロバイダーのドキュメントを参照してください。 作成する TXT レコードの名前は、`_dmarc.example.com`の必要があります。ここで、`example.com`はお客様のドメインです。TXT レコードの値には、ドメインに適用される DMARC ポリシーが含まれています。以下に、DMARC ポリシーを含む TXT レコードの例を示します。 | 名前 | タイプ | 値 | | --- | --- | --- | | \$1dmarc.example.com | TXT | "v=DMARC1;p=quarantine;rua=mailto:my\$1dmarc\$1report@example.com" | 上記の DMARC ポリシー例では、このポリシーは E メールプロバイダーに以下を実行するように指示します。 + 認証に失敗したメッセージについてはすべて、ポリシーパラメータ `p=quarantine` で指定されているとおり、スパムフォルダに送信します。その他のオプションには、`p=none` を使用して何もしない、または `p=reject` を使用してメッセージを完全に拒否する、などがあります。 + 次のセクションでは、これら 3 つのポリシー設定の使用方法と、使用すべきケースについて説明します。*適切でない設定を適切でないタイミングで使用すると、E メールが配信されなくなる可能性があります*。「[DMARC の実装のベストプラクティス](#send-email-authentication-dmarc-implement)」を参照してください。 + レポートパラメータ `rua=mailto:my_dmarc_report@example.com` (*rua* は集約レポートのレポート URI の略) で指定されるとおり、認証に失敗したすべての E メールに関するレポートをダイジェスト (つまり、イベントごとに個別のレポートを送信するのではなく、特定の期間のデータを集約したレポート) で送信します。ポリシーはプロバイダーごとに異なりますが、通常、E メールプロバイダーは 1 日 1 回レポートを送信します。 ドメインの DMARC 設定の詳細については、DMARC ウェブサイトの「[概要](https://dmarc.org/overview/)」を参照してください。 DMARC システムの完全な仕様については、「[Internet Engineering Task Force (IETF) DMARC Draft](https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/)」を参照してください。 ## DMARC の実装のベストプラクティス メールフローのその他の部分が中断しないように、DMARC ポリシーの実施は段階的なアプローチで実装することをお勧めします。以下のステップに沿ったロールアウトプランを作成して実装します。まず各サブドメインでこれらの手順を実行し、最後に組織内のトップレベルのドメインで実行してから、次の手順に進みます。 1. DMARC (p=none) の実装の影響をモニタリングします。 + まず、メール受信組織に、そのドメインを使用して受信したメッセージに関する統計を送信するように要求するサブドメインまたはドメインのシンプルなモニタリングモードレコードから始めます。モニタリングモードレコードとは、ポリシーがなし `p=none` に設定されている DMARC TXT レコードです。 + DMARC を介して生成されたレポートには、これらのチェックに合格したメッセージ数とメッセージの送信元が記載されます。正当なトラフィックがどの程度カバーされているか、またはカバーされていないかを簡単に確認できます。コンテンツが変更されると、転送されたメッセージは SPF と DKIM に失敗するため、転送のマークが表示されます。送信された不正なメッセージの数と送信元も表示されます。 + このステップの目的は、次の 2 つのステップのいずれかを実装するとどのような E メールが影響を受けるかを把握し、サードパーティーまたは承認済みの送信者の SPF ポリシーまたは DKIM ポリシーへのアライメントを確保することにあります。 + 既存のドメインに最適です。 1. 外部メールシステムに、DMARC (p=quarantine) に失敗したメールを隔離するようリクエストします。 + 正当なトラフィックのすべてまたはほとんどが SPF または DKIM のいずれかでドメインアライメントが確認されて送信されていることが確実であり、DMARC を実装することの影響を把握している場合に、隔離ポリシーを実装できます。隔離ポリシーとは、ポリシーが隔離 `p=quarantine` に設定されている DMARC TXT レコードです。これを実施することで、DMARC 受信者に、DMARC に失敗したドメインからのメッセージを、顧客の受信トレイではなく、スパムフォルダと同等のローカルの場所に配置するように要求することになります。 + ステップ 1 で DMARC レポートを分析したドメインの移行に最適です。 1. 外部メールシステムに、DMARC (p=reject) に失敗したメールを受け取らないようリクエストします。 + 通常、拒否ポリシーの実装が最後のステップとなります。拒否ポリシーとは、ポリシーが拒否 `p=reject` に設定されている DMARC TXT レコードです。これを実施すると、DMARC 受信者に DMARC チェックに失敗したメッセージを受け入れないように依頼することになります。つまり、これらのメッセージは、スパムフォルダや迷惑メールフォルダに隔離されることもなく、完全に拒否されます。 + 拒否ポリシーを使用すると、拒否によって SMTP バウンスが発生するため、DMARC ポリシーに失敗したメッセージを正確に把握できます。隔離の場合、集約データは、SPF チェック、DKIM チェック、DMARC チェックで適格または不適格となった E メールの割合に関する情報を提供します。 + 以前の 2 つのステップを実施した後の新しいドメインまたは既存のドメインに最適です。 ## SPF による DMARC への準拠 E メールが SPF に基づいて DMARC に準拠するためには、次の両方の条件を満たすことが求められています。 + メッセージは、カスタム MAIL FROM ドメインの DNS 設定に発行した有効な SPF (タイプは TXT) レコードに基づいて SPF チェックで適格性が認められる必要があります。 + E メールヘッダーの送信元アドレスのドメインは、MAIL FROM アドレスで指定されているドメイン、またはサブドメインとのアライメントが認められる (一致する) 必要があります。SES との SPF アラインメントを確保するために、ドメインの DMARC ポリシーで strict の SPF ポリシー (aspf=s) を指定することは避けます。 これらの要件に準拠するためには、次のステップを実行します。 + [カスタムの MAIL FROM ドメインを使用する](mail-from.md)の手順を実行して、カスタム MAIL FROM ドメインを設定します。 + 送信元ドメインが SPF に relaxed ポリシーを使用していることを確認します。ドメインのポリシーアラインメントを変更していない場合は、デフォルトで SES と同様に relaxed のポリシーが使用されます。 **注記** コマンドラインで以下のコマンドを入力して、`example.com`をドメインで置き換えることで、SPF での DMARC アラインメントを選択できます。 ``` dig TXT _dmarc.example.com ``` このコマンドの出力の [**Non-authoritative answer**] から、`v=DMARC1`で始まるレコードを探します。このレコードに文字列`aspf=r`が含まれるか、または`aspf`文字列がまったく存在しない場合、ドメインは SPF に relaxed アラインメントを使用します。レコードに文字列`aspf=s`が含まれる場合、ドメインは SPF に strict アラインメントを使用します。システム管理者は、ドメインの DNS 設定の DMARC TXT レコードからこのタグを削除する必要があります。 別の方法として、dmarcian ウェブサイトの [DMARC Inspector](https://dmarcian.com/dmarc-inspector/) や MxToolBox ウェブサイトの [DMARC Check ツール](https://mxtoolbox.com/dmarc.aspx)などのウェブベースの DMARC ルックアップツールを使用して、ドメインのポリシーの SPF へのアライメントを判断することもできます。 ## DKIM を介した DMARC への準拠 E メールが DKIM に基づいて DMARC に準拠するためには、次の両方の条件を満たすことが求められています。 + メッセージには有効な DKIM 署名が必要であり、DKIM チェックで適格性が認められる必要があります。 + DKIM 署名で指定されたドメインが、送信元アドレスのドメインと一致する必要があります。ドメインの DMARC ポリシーで DKIM に strict アラインメントが指定されている場合は、これらのドメインは完全に一致する必要があります (SES はデフォルトで strict の DKIM ポリシーを使用します)。 これらの要件に準拠するためには、次のステップを実行します。 + [Amazon SES のEasy DKIM](send-email-authentication-dkim-easy.md)の手順を実行して Easy DKIM を設定します。Easy DKIM を使用すると、Amazon SES は自動的に E メールに署名します。 **注記** Easy DKIM を使用せずに、[メッセージに手動で署名](send-email-authentication-dkim-manual.md)することもできます。ただし、Amazon SES は構築した DKIM 署名を検証しないため、この選択は慎重に行ってください。そのため、Easy DKIM を使用することを強くお勧めします。 + DKIM 署名で指定されたドメインが、送信元アドレスのドメインと一致していることを確認してください。または、送信元アドレスのドメインのサブドメインから送信する場合は、DMARC ポリシーが relaxed アライメントに設定されていることを確認します。 **注記** コマンドラインで以下のコマンドを入力して、`example.com`をドメインで置き換えることで、DKIM での DMARC アラインメントを選択できます。 ``` dig TXT _dmarc.example.com ``` このコマンドの出力の [**Non-authoritative answer**] から、`v=DMARC1`で始まるレコードを探します。このレコードに文字列`adkim=r`が含まれるか、または`adkim`文字列がまったく存在しない場合、ドメインは DKIM に relaxed アラインメントを使用します。レコードに文字列`adkim=s`が含まれる場合、ドメインは DKIM に strict アラインメントを使用します。システム管理者は、ドメインの DNS 設定の DMARC TXT レコードからこのタグを削除する必要があります。 別の方法として、dmarcian ウェブサイトの [DMARC Inspector](https://dmarcian.com/dmarc-inspector/) や MxToolBox ウェブサイトの [DMARC Check ツール](https://mxtoolbox.com/dmarc.aspx)などのウェブベースの DMARC ルックアップツールを使用して、ドメインのポリシーの DKIM へのアライメントを判断することもできます。 # Amazon SES での BIMI の使用 Brand Indicators for Message Identification (BIMI) は、対応しているメールクライアントの E メールの受信トレイにおいて、ブランドの認証済み E メールメッセージの横にブランドのロゴを表示できるようにするメール仕様です。 BIMI は認証に直接関係するメール仕様ですが、すべての E メールに対して [DMARC](send-email-authentication-dmarc.md) 認証への準拠を要求するため、スタンドアロンの E メール認証プロトコルではありません。 BIMI には DMARC が必要であり、DMARC にはドメインの SPF レコードまたは DKIM レコードのアラインメントが必要ですが、SPF レコードと DKIM レコードの両方を含めるのが最善です。セキュリティの強化になるとともに、E メールサービスプロバイダー (ESP) によっては BIMI を使用する際に両方を要求する場合があるためです。次のセクションでは、Amazon SES に BIMI を実装する手順を示します。 ## SES での BIMI の設定 所有するメールドメイン (SES では*カスタム* MAIL FROM ドメインと呼ばれます) に BIMI を設定できます。設定すると、[BIMI をサポートする E メールクライアント](https://bimigroup.org/bimi-infographic/)において、そのドメインから送信されたすべてのメッセージに BIMI ロゴが表示されます。 E メールに BIMI ロゴを表示するには、SES 内でいくつかの前提条件を満たす必要があります。次の手順では、これらの前提条件を一般化するとともに、これらのトピックを詳細に説明する専用のセクションを参照として示します。ここでは、BIMI に固有の手順と、SES で BIMI を設定するために必要な事項について詳しく説明します。 **カスタム MAIL FROM ドメインに BIMI を設定するには** 1. SES でカスタム MAIL FROM ドメインを設定し、このドメインに SPF (タイプ TXT) レコードと MX レコードの両方を発行する必要があります。カスタム MAIL FROM ドメインを持っていないか、これを BIMI ロゴ用に新しく作成する場合は、「[カスタムの MAIL FROM ドメインを使用する](mail-from.md)」を参照してください。 1. Easy DKIM を使用してドメインを設定します。「[Amazon SES のEasy DKIM](send-email-authentication-dkim-easy.md)」を参照してください。 1. 以下の 2 つの例のいずれかと同様に、BIMI に必要な以下の強制ポリシーの詳細を含む TXT レコードを DNS プロバイダーに発行して、ドメインに DMARC を設定します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ses/latest/dg/send-email-authentication-bimi.html) 上の BIMI に必要な DMARC ポリシーの例では、以下のとおりとします。 + `example.com` は、ドメイン名またはサブドメイン名に置き換える必要があります。 + `p=` の値は以下のいずれかです。 + 表示されているとおりに *pct* 値を *100* に設定した *quarantine* + 表示されているとおりに *reject*。 + サブドメインから送信する場合、BIMI は親ドメインにもこの強制ポリシーを持つことを要求します。サブドメインは親ドメインのポリシーに従います。ただし、親ドメインに発行した内容に加えてサブドメインにも DMARC レコードを追加する場合、BIMI の対象となるには、サブドメインにも同じ強制ポリシーが必要です。 + ドメインに DMARC ポリシーを設定したことがない場合は、「[Amazon SES の DMARC 認証プロトコルへの準拠](send-email-authentication-dmarc.md)」を参照し、表示されているとおりに BIMI 固有の DMARC ポリシー値のみを使用してください。 1. BIMI ロゴをスケーラブルベクターグラフィックス (SVG) `.svg` ファイルとして作成します。BIMI に必要な特定の SVG プロファイルは、SVG Portable/Secure (SVG P/S) として定義します。ロゴを E メールクライアントに表示するには、これらの仕様に正確に準拠する必要があります。[BIMI Group](https://bimigroup.org/) の [SVG ロゴファイルの作成](https://bimigroup.org/creating-bimi-svg-logo-files/)に関するガイダンスと、推奨される [SVG 変換ツール](https://bimigroup.org/svg-conversion-tools-released/)を参照してください。 1. (オプション) Verified Mark Certificate (VMC) を取得します。Gmail や Apple などの一部の ESP では、BIMI ロゴの商標とコンテンツを所有していることの証拠として VMC を要求します。これはドメインに BIMI を実装するための要件ではありませんが、メール送信先の ESP が VMC 準拠を強制している場合、BIMI ロゴは E メールクライアントに表示されません。ロゴの VMC を取得するには、BIMI Group の[加盟認証機関](https://bimigroup.org/verified-mark-certificates-vmc-and-bimi/)に関するリファレンスを参照してください。 1. BIMI ロゴの SVG ファイルを、ユーザーがアクセスできるサーバーでホストし、HTTPS 経由で一般に公開します。例えば、[Amazon S3 バケット](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-buckets-s3.html)にファイルをアップロードできます。 1. ロゴの URL を含む BIMI DNS レコードを作成して発行します。[BIMI をサポートする ESP](https://bimigroup.org/bimi-infographic/) は、DMARC レコードをチェックするときに、ロゴの `.svg` ファイルの URL が含まれている BIMI レコードと、VMC の `.pem` ファイルの URL (設定されている場合) も検索します。レコードが一致すると、BIMI ロゴが表示されます。 ドメインに BIMI を設定します。そのために、以下に示す値を使用して DNS プロバイダーに TXT レコードを発行します。最初の例はドメインからの送信、2番目の例はサブドメインからの送信を示しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ses/latest/dg/send-email-authentication-bimi.html) 上の BIMI レコードの例では、以下のとおりとします。 + 名前の値は、`default._bimi.` を `example.com` または `marketing.example.com` のサブドメインとして文字どおり指定する必要があり、自分のドメイン名またはサブドメイン名に置き換えます。 + `v=` 値は BIMI レコードの*バージョン*です。 + `l=` 値は、ロゴの URL であり、画像の `.svg` ファイルを指します。 + `a=` 値は、機関の URL であり、証明書の `.pem` ファイルを指します。 BIMI Group の [BIMI Inspector](https://bimigroup.org/bimi-generator/) などのツールを使用して BIMI レコードを検証できます。 このプロセスの最後のステップとして、BIMI ロゴの掲載をサポートする ESP への定期的な送信パターンを設定します。ドメインは、定期的な配信頻度を持ち、送信先の ESP から高い評価を得ている必要があります。評価や配信頻度の実績がない場合、BIMI ロゴが ESP に掲載されるまでに時間がかかることがあります。 BIMI に関する詳細情報やリソースについては、[BIMI Group](https://bimigroup.org/) 組織で参照できます。 # Amazon SES のイベント通知の設定 Amazon SES を使用して電子メールを送信するには、バウンスと苦情を管理するためのシステムが必要です。Amazon SES は、通知メールを送信する、Amazon SNS トピックを通知する、送信イベントを公開する、の 3 つのいずれかの方法でバウンスや苦情イベントを通知します。このセクションでは、E メールまたは Amazon SNS トピックに通知することによって、特定の種類の通知を送信するように Amazon SES を設定する方法について説明します。送信イベントを公開する方法の詳細については、「[Amazon SES イベント発行を使用して E メール送信をモニタリングする](monitor-using-event-publishing.md)」を参照してください。 Amazon SES コンソールまたは Amazon SES API を使用して通知をセットアップできます。 **Topics** + [重要な考慮事項](#monitor-sending-activity-using-notifications-considerations) + [E メールを介したAmazon SES に関する通知の受信](monitor-sending-activity-using-notifications-email.md) + [Amazon SNSを使用したAmazon SES通知の受信](monitor-sending-activity-using-notifications-sns.md) ## 重要な考慮事項 通知を送信するように Amazon SES を設定する際に考慮すべきいくつかの重要な点があります。 + E メールと Amazon SNS 通知は、個々の ID (E メールの送信に使用する検証済みの電子メールアドレスまたはドメイン) に適用されます。ID の通知を有効にすると、Amazon SES はその ID から送信された E メールの通知のみを送信し、通知を設定した AWS リージョンでのみ通知を送信します。 + バウンスや苦情の通知を受け取る方法を有効にする必要があります。バウンスや苦情を生成したドメインや電子メールアドレス、または Amazon SNS トピックに通知を送信できます。[イベント発行](monitor-using-event-publishing.md)を使用すると、いくつかの異なるタイプのイベントに関する通知 (バウンス、苦情、配信) を Amazon SNS トピックまたは Firehose ストリームに送信することもできます。 バウンスや苦情の通知を受け取るこれらの方法の 1 つを設定しない場合は、E メールのフィードバック転送を無効にしていても、Amazon SES はバウンスや苦情のイベントの原因となった E メールの Return-Path アドレス (または Return-Path アドレスを指定しなかった場合はソースアドレス) にバウンスや苦情の通知を自動的に転送します。 E メールのフィードバック転送を無効にし、イベント発行を有効にする場合は、送信するすべての E メールにイベント発行ルールを含む設定セットを適用する必要があります。この状況で、設定セットを使用しない場合は、Amazon SES はバウンスや苦情のイベントの原因となった E メールのリターンパス アドレスまたは出典アドレスにバウンスや苦情の通知を自動的に転送します。 + 1 つ以上の方法 (E メール通知を送信する、イベントの送信を使用するなど) を使用してバウンスや苦情を送信するように Amazon SES を設定する場合は、同じイベントに対して 1 つ以上の通知を受け取る場合があります。 # E メールを介したAmazon SES に関する通知の受信 Amazon SES は、ユーザーがバウンスや苦情を受信すると、*E メールのフィードバック転送*というプロセスを使用して、ユーザーに E メールを送信します。 Amazon SES を使用して E メールを送信するには、次のいずれかの方法を使用して、バウンスや苦情の通知を送信するように設定する必要があります。 + E メールのフィードバック転送を有効にする。このタイプの通知を設定する手順は、このセクションに含まれています。 + Amazon SNS トピックに通知を送信する。詳細については、「[Amazon SNSを使用したAmazon SES通知の受信](monitor-sending-activity-using-notifications-sns.md)」を参照してください。 + イベント通知を発行する。詳細については、「[Amazon SES イベント発行を使用して E メール送信をモニタリングする](monitor-using-event-publishing.md)」を参照してください。 **重要** 通知についてのいくつかの重要なポイントについては、「[Amazon SES のイベント通知の設定](monitor-sending-activity-using-notifications.md)」を参照してください。 **Topics** + [E メールのフィードバック転送を有効にする](#monitor-sending-activity-using-notifications-email-enabling) + [E メールのフィードバック転送を無効にする](#monitor-sending-activity-using-notifications-email-disabling) + [E メールのフィードバック転送先](#monitor-sending-activity-using-notifications-email-destination) ## E メールのフィードバック転送を有効にする E メールのフィードバック転送はデフォルトで有効です。以前に無効にしている場合、このセクションの以下の手順に従って有効にできます。 **Amazon SES コンソールを使用して E メールによるバウンスや苦情の転送を有効にする** 1. AWS マネジメントコンソール にサインインし、Amazon SES コンソール ([https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)) を開きます。 1. ナビゲーションペインの**設定**で、**検証済み ID** を選択します。 1. 確認済みの E メールアドレスまたはドメインで、バウンスと苦情の通知を設定する E メールアドレスまたはドメインを選択します。 1. 詳細ペインで、[**Notifications**] セクションを展開します。 1. [**Edit Configuration**] を選択します。 1. [**E メール Feedback Forwarding**] で、[**Enabled**] を選択します。 **注記** このページで行った変更は、反映されるまでに数分かかる場合があります。 また、[SetIdentityFeedbackForwardingEnabled](https://docs.aws.amazon.com/ses/latest/APIReference/API_SetIdentityFeedbackForwardingEnabled.html) API オペレーションを使用して、バウンスや苦情の通知を有効にできます。 ## E メールのフィードバック転送を無効にする バウンスや苦情の通知を提供する別の方法を設定する場合は、バウンスや苦情のイベントが発生したときに複数の通知を受け取らないように、E メールのフィードバック転送を無効にすることができます。 **Amazon SES コンソールを使用して E メールを介したバウンスや苦情の転送を無効にする** 1. AWS マネジメントコンソール にサインインし、Amazon SES コンソール ([https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)) を開きます。 1. ナビゲーションペインの**設定**で、**検証済み ID** を選択します。 1. 確認済みの E メールアドレスまたはドメインで、バウンスと苦情の通知を設定する E メールアドレスまたはドメインを選択します。 1. 詳細ペインで、[**Notifications**] セクションを展開します。 1. [**Edit Configuration**] を選択します。 1. [**E メール Feedback Forwarding**] で、[**Disabled**] を選択します。 **注記** Amazon SES を介して E メールを送信するには、バウンスや苦情の通知を受け取る 1 つの方法を設定する必要があります。E メールのフィードバック転送を無効にする場合は、Amazon SNS が送信する通知を有効にするか、[イベント発行](monitor-using-event-publishing.md)を使用して、バウンスイベントと苦情イベントを Amazon SNS トピックまたは Firehose ストリームに発行する必要があります。イベント発行を使用する場合は、送信する各 E メールにイベント発行ルールを含む設定セットも適用する必要があります。バウンスや苦情の通知を受け取る方法を設定しない場合は、Amazon SES はバウンスや苦情のイベントの原因となったメッセージのリターンパス フィールド (またはリターンパス アドレスを指定しなかった場合は出典フィールド) のアドレスに、E メールによるフィードバック通知を自動的に転送します。この場合、E メールのフィードバック通知を無効にしても、Amazon SES はバウンス通知や苦情の通知を転送します。 1. [**Save Config**] を選択して通知設定を保存します。 **注記** このページで行った変更は、反映されるまでに数分かかる場合があります。 また、[SetIdentityFeedbackForwardingEnabled](https://docs.aws.amazon.com/ses/latest/APIReference/API_SetIdentityFeedbackForwardingEnabled.html)API オペレーションを使用して、バウンスや苦情の通知を無効にできます。 ## E メールのフィードバック転送先 E メールで通知を受け取る場合、Amazon SES は`From`ヘッダーを書き換えて通知を送信します。Amazon SES が通知を転送するアドレスは、元のメッセージの送信方法によって異なります。 SMTP インターフェイスを使用してメッセージを送信すると、通知は以下の規則に従って配信されます。 + `SMTP DATA` セクションで `Return-Path` ヘッダーを指定すると、通知はそのアドレスに送信されます。 + その他の場合は、MAIL FROM コマンドを発行したときに指定したアドレスに通知が送信されます。 `SendEmail`API オペレーションを使用してメッセージを送信すると、通知は以下の規則に従って配信されます。 + `SendEmail`API を呼び出す際にオプションの`ReturnPath` パラメータを指定すると、通知はそのアドレスに送信されます。 + 指定しない場合、`Source`の必須`SendEmail`パラメータであるで指定されたアドレスに通知が送信されます。 `SendRawEmail`API オペレーションを使用してメッセージを送信すると、通知は以下の規則に従って配信されます。 + raw メッセージで `Return-Path` ヘッダーを指定すると、通知はそのアドレスに送信されます。 + その他の場合は、`SendRawEmail` API を呼び出す際に `Source` パラメータを指定すると、通知はそのアドレスに送信されます。 + その他の場合、raw メッセージの`From`ヘッダーにおいて指定されたアドレスに通知が送信されます。 **注記** E メールで`Return-Path`アドレスを指定すると、通知はそのアドレスに送信されます。ただし、受信者が受信するメッセージのバージョンには、 匿名化されたEメールアドレス (*a0b1c2d3e4f5a6b7-c8d9e0f1-a2b3-c4d5-e6f7-a8b9c0d1e2f3-000000@amazonses.com*) を含む`Return-Path`ヘッダー含まれています。この匿名化は、E メールの送信方法にかかわらず実行されます。 # Amazon SNSを使用したAmazon SES通知の受信 バウンスや苦情を受け取ったとき、または E メールが配信されたときに、Amazon SES トピックを通知するように Amazon SNS を設定できます。Amazon SNS 通知は [JavaScript Object Notation (JSON)](http://www.json.org)形式になっており、プログラムで処理できます。 Amazon SES を使用して E メールを送信するには、次のいずれかの方法を使用して、バウンスや苦情の通知を送信するように設定する必要があります。 + Amazon SNS トピックに通知を送信する。このタイプの通知を設定する手順は、このセクションに含まれています。 + E メールのフィードバック転送を有効にする。詳細については、「[E メールを介したAmazon SES に関する通知の受信](monitor-sending-activity-using-notifications-email.md)」を参照してください。 + イベント通知を発行する。詳細については、「[Amazon SES イベント発行を使用して E メール送信をモニタリングする](monitor-using-event-publishing.md)」を参照してください。 **重要** 通知に関する重要な情報については、「[Amazon SES のイベント通知の設定](monitor-sending-activity-using-notifications.md)」を参照してください。 **Topics** + [Amazon SES の Amazon SNS 通知の設定](configure-sns-notifications.md) + [Amazon SES の Amazon SNS 通知コンテンツ](notification-contents.md) + [Amazon SES の Amazon SNS 通知の例](notification-examples.md) # Amazon SES の Amazon SNS 通知の設定 [Amazon Simple Notification Service (Amazon SNS)](https://aws.amazon.com/sns)を通して、Amazon SES は、バウンス、苦情、配信を通知します。 通知は Amazon SES コンソールで設定するか、Amazon SES API を使用して設定できます。 **Topics** + [前提条件](#configure-feedback-notifications-prerequisites) + [Amazon SES コンソールを使用した通知の設定](#configure-feedback-notifications-console) + [Amazon SES API を使用した通知の設定](#configure-feedback-notifications-api) + [フィードバック通知のトラブルシューティング](#configure-feedback-notifications-troubleshooting) ## 前提条件 Amazon SES で Amazon SNS 通知を設定する前に、次のステップを完了します。 1. Amazon SNS トピックを作成します。詳細については、[Amazon Simple Notification Service デベロッパーガイド](https://docs.aws.amazon.com/sns/latest/dg/CreateTopic.html)の「*トピックの作成*」を参照してください。 **重要** Amazon SNS を使用してトピックを作成する場合、**タイプ**は**スタンダード**を選択します。（SES は FIFO タイプのトピックをサポートしていません。） 新しい SNS トピックを作成する場合も、既存のトピックを選択する場合も、トピックに通知を発行するために SES へのアクセスを許可する必要があります。 トピック に通知を発行するためのアクセス許可をAmazon SES に付与するには、SNS コンソールの [**トピ追加ックの編集**] 画面で [**アクセスポリシー**] を展開し、[**JSON エディタ**] に次の許可ポリシーをします。 ------ #### [ 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" } } } ] } ``` ------ 上のポリシー例に、以下の変更を加えます。 + *topic\$1region* を、SNS トピックを作成した AWS リージョンに置き換えます。 + *111122223333*を自分の AWS アカウント ID に置き換えます。 + *topic\$1name*は、SNS トピックの名前に置き換えます。 + *identity\$1name*は、SNS トピックにサブスクライブしている確認済みアイデンティティ (E メールアドレスまたはドメイン) に置き換えます。 1. 少なくとも 1 つのエンドポイントをトピックにサブスクライブします。たとえば、テキストメッセージで通知を受け取る場合は、トピックに SMS エンドポイント (携帯電話番号) をサブスクライブします。E メールで通知を受信するには、E メールエンドポイント (E メールアドレス) をトピックにサブスクライブします。 詳細については、[Amazon Simple Notification Service デベロッパーガイド](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html)の「*作業スタート*」を参照してください。 1. (オプション) Amazon SNS トピックがサーバー側の暗号化に AWS Key Management Service (AWS KMS) を使用する場合は、 AWS KMS キーポリシーにアクセス許可を追加する必要があります。アクセス許可を追加するには、次のポリシーを AWS KMS キーポリシーにアタッチします。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowSESToUseKMSKey", "Effect": "Allow", "Principal": { "Service": "ses.amazonaws.com" }, "Action": [ "kms:GenerateDataKey", "kms:Decrypt" ], "Resource": "*" } ] } ``` ------ ## Amazon SES コンソールを使用した通知の設定 **Amazon SES コンソールを使用して通知を設定するには** 1. Amazon SES コンソール ([https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)) を開きます。 1. ナビゲーションペインの **[設定]** で、**[ID]** を選択します。 1. **[Identities]** (ID) コンテナで、この ID の結果から送信されたメッセージがバウンス、苦情、または配信になったときのフィードバック通知を受信する検証済み ID を選択します。 **重要** 確認済みドメイン通知設定は、同様に確認済みの E メールアドレスを*除き*、そのドメインの E メールアドレスから送信されるすべてのメールに適用されます。 1. 選択した検証済み ID の詳細画面で、**[Notifications]** (通知) タブを選択し、**[Feedback notifications**] (フィードバック通知) コンテナの **[Edit]** (編集) を選択します。 1. 通知を受信する各フィードバックタイプの SNS トピックリストボックスを展開し、[SNS topic you own] (所有する SNS トピック)、**[No SNS topic]** (SNS トピックなし)、または **[SNS topic you don't own]** (所有していない SNS トピック) のいずれかを選択します。 1. **[SNS topic you don't own]** (所有していない SNS トピック) を選択した場合、**SNS トピックの ARN** フィールドが表示され、そこで代理送信者が共有する SNS トピックの ARN を入力する必要があります。(代理送信者が SNS トピックを所有するため、これらの通知は代理送信者だけが受け取ります。代理送信の詳細については、「[送信承認の概要](sending-authorization-overview.md)」を参照してください)。 **重要** バウンス、苦情、配信の通知に使用する Amazon SNS トピックは、Amazon SES を使用する AWS リージョン トピックと同じ にある必要があります。 さらに、通知を受け取るには、1 つ以上のエンドポイントをトピックにサブスクライブしている必要があります。たとえば、E メールアドレスに通知を送信する場合は、E メールエンドポイントをそのトピックにサブスクライブする必要があります。詳細については、『*Amazon Simple Notification Service デベロッパーガイド*』の「[作業スタート](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html)」を参照してください。 1. (オプション) 元の E メールのヘッダーをトピック通知に含める場合は、各フィードバックタイプの SNS トピック名のすぐ下にある **[Include original email headers]** (元の E メールヘッダーを含める) ボックスにチェックを入れます。このオプションは、その通知タイプに Amazon SNS トピックを割り当てている場合にのみ使用できます。元の E メールヘッダーの内容については、[通知の内容](notification-contents.md)の `mail` オブジェクトを参照してください。 1. **[Save changes]** (変更の保存) をクリックします。通知設定に対する変更は、反映されるまでに数分かかる場合があります。 1. (オプション) バウンスと苦情の両方で Amazon SNS トピック通知を選択した場合、すべての E メール通知を無効にして、E メール通知と SNS 通知を重複して受け取らないようにすることができます。バウンスや苦情に関する E メール通知を無効にするには、**[Email Feedback Forwarding]** (E メールのフィードバック転送) コンテナの検証済み ID の詳細画面にある **[Notifications]** (通知) タブで、**[Edit]** (編集) を選択し、**[Enabled]** (有効) ボックスのチェックを外して、**[Save changes]** (変更を保存) を選択します。 設定の完了後は、返送、苦情、配信の通知が Amazon SNS トピックに送られるようになります。これらの通知は JavaScript Object Notation (JSON) 形式になっており、「[通知の内容](notification-contents.md)」で説明されている構造に従っています。 バウンス、苦情、配信の通知には、Amazon SNS のスタンダードレートが課金されます。詳細については、「[Amazon SNS 料金ページ](https://aws.amazon.com/sns/pricing)」を参照してください。 **注記** トピックが削除されたか、 に発行するアクセス許可 AWS アカウント がなくなったために Amazon SNS トピックへの発行が失敗した場合、バウンスや苦情 (配信ではなく - 配信通知の場合、SES は SNS トピック設定を削除しません) 用に設定されている場合、Amazon SES はそのトピックの設定を削除します。さらに、Amazon SES が ID のバウンスと苦情の E メール通知を再度有効にし、ユーザーは変更の通知を E メールで受け取ります。トピックを使用するように複数の ID が設定されている場合、各 ID でトピックへの発行に失敗すると、各 ID のトピック設定が変更されます。 ## Amazon SES API を使用した通知の設定 バウンス、苦情、配信の通知は、Amazon SES API を使用して設定することもできます。次のオペレーションを使用して通知を設定します。 + [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) これらの API アクションを使用して、通知用にカスタマイズしたフロントエンドアプリケーションを作成することができます。通知に関連する API アクションの詳しい説明については、[Amazon Simple Email Service API リファレンス](https://docs.aws.amazon.com/ses/latest/APIReference/)を参照してください。 ## フィードバック通知のトラブルシューティング **通知が送られてこない** 通知を受け取っていない場合は、通知が送信されるトピックにエンドポイントをサブスクライブしていることを確認します。E メールエンドポイントをトピックにサブスクライブすると、サブスクリプションの確認を求める E メールが届きます。E メール通知の受信を開始するには、サブスクリプションを確認する必要があります。詳細については、『*Amazon Simple Notification Service デベロッパーガイド*』の「[作業スタート](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html)」を参照してください。 **`InvalidParameterValue` トピックを選択する際にエラーが発生する** `InvalidParameterValue` エラーが発生したことを示すエラーを受け取った場合は、Amazon SNS トピックが AWS KMSを使用して暗号化されているかどうかをチェックします。その場合は、 AWS KMS キーのポリシーを変更する必要があります。サンプルポリシーについては、「[前提条件](#configure-feedback-notifications-prerequisites)」を参照してください。 # Amazon SES の Amazon SNS 通知コンテンツ バウンス、苦情、および配信の通知は、JavaScript Object Notation (JSON) 形式で、[Amazon Simple Notification Service (Amazon SNS)](https://aws.amazon.com/sns) トピックに発行されます。トップレベル JSON オブジェクトには、`notificationType` 文字列と `mail` オブジェクトに加え、`bounce` オブジェクト、`complaint` オブジェクト、または `delivery` オブジェクトのいずれかが含まれます。 オブジェクトのタイプごとの詳細については以下のセクションを参照してください。 + [トップレベル JSON オブジェクト](#top-level-json-object) + [`mail` オブジェクト](#mail-object) + [`bounce` オブジェクト](#bounce-object) + [`complaint` オブジェクト](#complaint-object) + [`delivery` オブジェクト](#delivery-object) 以下は、Amazon SES の Amazon SNS 通知の内容に関する重要な注意事項です。 + 該当する通知タイプにより、複数の受信者に対応する 1 つの Amazon SNS 通知を受け取ることもあれば、各受信者に 1 つの Amazon SNS 通知を受け取ることもあります。コードでは Amazon SNS 通知を解析して、どちらの場合にも対応できる必要があります。Amazon SNS を使用して送信された通知に関しては、SES では順序付けや一括処理が保証されません。ただし、タイプの異なる Amazon SNS 通知 (バウンスと苦情など) が 1 つの通知にまとめられることはありません。 + 1 人の受信者に対して複数のタイプの Amazon SNS 通知を受け取ることがあります。たとえば、受信メールサーバーは、E メールを受理した場合でも (配信の通知をトリガーします)、そのメールの処理後に、そのメールは実際にはバウンスであると判定する場合があります (バウンスの通知をトリガーします)。ただし、通知のタイプが異なるため、これらは常に個別に通知されます。 + SES には、通知にその他のフィールドを追加する権限があります。そのため、これらの通知を解析するアプリケーションには、不明なフィールドを処理できるだけの十分な柔軟性が必要です。 + SES は、E メールの送信時にメッセージのヘッダーを上書きします。`mail` オブジェクトの `headers` および `commonHeaders` フィールドから元のメッセージのヘッダーを取得できます。 ## トップレベル JSON オブジェクト SES 通知のトップレベル JSON オブジェクトには、以下のフィールドが含まれています。 | フィールド名 | 説明 | | --- | --- | | notificationType | 通知のタイプを格納する文字列は、JSON オブジェクトによって表されます。想定される値は、`Bounce`、`Complaint`、および `Delivery` です。 [イベント発行をセットアップ](monitor-sending-using-event-publishing-setup.md)する場合、このフィールドの名前は `eventType` です。 | | mail | 通知に関連する元のメールについての情報を含む JSON オブジェクト。詳細については、「[Mail オブジェクト](#mail-object)」を参照してください。 | | bounce | このフィールドは `notificationType` が `Bounce` である場合のみ存在し、バウンスに関する情報を持つ JSON オブジェクトが含まれます。詳細については、「[Bounce オブジェクト](#bounce-object)」を参照してください。 | | complaint | このフィールドは `notificationType` が `Complaint` である場合のみ存在し、苦情に関する情報を持つ JSON オブジェクトが含まれます。詳細については、「[苦情のオブジェクト](#complaint-object)」を参照してください。 | | delivery | このフィールドは `notificationType` が `Delivery` である場合のみ存在し、配信に関する情報を持つ JSON オブジェクトが含まれます。詳細については、「[配信オブジェクト](#delivery-object)」を参照してください。 | ## Mail オブジェクト バウンス、苦情、または配信の通知にはそれぞれ、`mail` オブジェクト内の元の E メールについての情報が含まれます。`mail` オブジェクトについての情報を含む JSON オブジェクトには次のフィールドが含まれます。 | フィールド名 | 説明 | | --- | --- | | timestamp | 元のメッセージが送信された日時 (ISO 8601 形式)。 | | messageId | SES がメッセージに割り当てた一意の ID。ユーザーがメッセージを送信すると、SES はこの値を返します。 このメッセージ ID は SES によって割り当てられたものです。元の E メールのメッセージ ID は、`mail` オブジェクトの `headers` フィールドにあります。 | | source | 元のメッセージが送信された E メールアドレス (エンベロープ MAIL FROM アドレス)。 | | sourceArn | E メールの送信に使用された ID の Amazon リソースネーム (ARN)。送信承認の場合、`sourceArn` は、代理送信者が E メールの送信に使用することをアイデンティティ所有者により承認されたアイデンティティの ARN です。送信承認の詳細については、「[E メールの認証方法送信承認の使用](sending-authorization.md)」を参照してください。 | | sourceIp | SES に対して E メールの送信リクエストを実行したクライアントの送信側パブリック IP アドレス。 | | sendingAccountId | E メールの送信に使用されたアカウントの AWS アカウント ID。送信承認の場合、`sendingAccountId` は代理送信者のアカウント ID です。 | | callerIdentity | E メールを送信した SES ユーザーの IAM ID | | destination | 元のメールの受取人の E メールアドレスのリスト。 | | headersTruncated | 元の E メールからヘッダーを含めるように通知設定を構成した場合にのみ、このオブジェクトが表示されます。 ヘッダーが通知で切り詰められるかどうかを示します。SES では、元のメッセージのヘッダーのサイズが 10 KB 以上の場合、通知のヘッダーが切り詰められます。指定できる値は `true` および `false` です。 | | headers | 元の E メールからヘッダーを含めるように通知設定を構成した場合にのみ、このオブジェクトが表示されます。 E メールの元のヘッダーの一覧。リスト内の各ヘッダーには、`name` フィールドと `value` フィールドがあります。 `headers` オブジェクト内のメッセージ ID は、SES に渡した元のメッセージのものです。その後 SES がメッセージに割り当てるメッセージ ID は、`mail` オブジェクトの `messageId` フィールドのものです。 | | commonHeaders | 元の E メールからヘッダーを含めるように通知設定を構成した場合にのみ、このオブジェクトが表示されます。 元の E メールからの一般的な E メールヘッダーに関する情報 (送信元、宛先、件名フィールドなど) が含まれます。このオブジェクト内では、各ヘッダーはキーとなります。送信元フィールドと宛先フィールドは、複数の値を含むことができる配列で表されます。 イベントの場合、`commonHeaders` フィールド内のメッセージ ID は、Amazon SES が後でメールオブジェクトの `messageId` フィールドでメッセージに割り当てたメッセージ ID です。通知には、元の E メールのメッセージ ID が含まれます。 | 以下は、元の E メールヘッダーを含む `mail` オブジェクトの例です。この通知タイプが元の E メールヘッダーを含めるように設定されていない場合は、`mail` オブジェクトに `headersTruncated`、`headers` および `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" } } ``` ## Bounce オブジェクト バウンスに関する情報を含む JSON オブジェクトには以下のフィールドがあります。 | フィールド名 | 説明 | | --- | --- | | bounceType | バウンスのタイプ。SES によって決定されます。詳細については、「[バウンスのタイプ](#bounce-types)」を参照してください。 | | bounceSubType | バウンスのサブタイプ。SES によって決定されます。詳細については、「[バウンスのタイプ](#bounce-types)」を参照してください。 | | bouncedRecipients | バウンスとなった元のメールの受取人についての情報を含むリスト。詳細については、「[バウンスとなった受取人](#bounced-recipients)」を参照してください。 | | timestamp | バウンスが送信された日時 (ISO 8601 形式)。この時刻は、ISP によって通知が送信された時刻であり、SES が通知を受け取った時刻ではないことに注意してください。 | | feedbackId | バウンスの一意の ID。 | SES がリモートの Message Transfer Authority (MTA) に接続できた場合は、次のフィールドも表示されます。 | フィールド名 | 説明 | | --- | --- | | remoteMtaIp | SES で E メールの配信を試みた先の MTA の IP アドレス。 | 配信状態通知 (DSN) がバウンスに添付されている場合は、次のフィールドも表示されます。 | フィールド名 | 説明 | | --- | --- | | reportingMTA | DSN の `Reporting-MTA` フィールドの値。これは、DSN に記述された配信、リレー、またはゲートウェイのオペレーションを試みた MTA の値です。 | 以下は、`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" } ``` ### バウンスとなった受取人 バウンスの通知には、1 人の受信者に関するものと複数の受信者に関するものがあります。`bouncedRecipients` フィールドはオブジェクトのリスト (バウンスの通知が関係する受取人ごとに 1 つのオブジェクト) を保持し、常に次のフィールドが含まれます。 | フィールド名 | 説明 | | --- | --- | | emailAddress | 受取人の E メールアドレス。DSN が利用できる場合、これが DSN の `Final-Recipient` フィールドの値です。 | オプションで、DSN がバウンスに添付されている場合、以下のフィールドも表示される場合があります。 | フィールド名 | 説明 | | --- | --- | | action | DSN の `Action` フィールドの値。このフィールドには、Reporting-MTA により実行された、この受取人に対してメッセージを送信しようとした結果のアクションが示されます。 | | status | DSN の `Status` フィールドの値。これは、メッセージの配信状態を示す、受取人ごとに個別の、トランスポート独立型ステータスコードです。 | | diagnosticCode | ステータスコードは、Reporting-MTA により発行されます。これは、DSN の `Diagnostic-Code` フィールドの値です。このフィールドが DSN に存在しない場合もあります (その場合 JSON オブジェクトにも表示されません)。 | 以下は、`bouncedRecipients` のリストに示されるオブジェクトの例です。 ``` { "emailAddress": "recipient@example.com", "action": "failed", "status": "5.0.0", "diagnosticCode": "X-Postfix; unknown user" } ``` ### バウンスのタイプ バウンスオブジェクトには、バウンスタイプとして `Undetermined`、`Permanent` *(ハード)*、または `Transient` *(ソフト)* が含まれます。`Permanent` *(ハード)* および `Transient` *(ソフト)* バウンスタイプには、いくつかあるバウンスサブタイプの 1 つも含まれます。 バウンスタイプが `Transient` *(ソフト)* のバウンス通知を受信した場合は、メッセージのバウンスを起こした問題が解決されたときに、この受取人に対して将来 E メールを送信できる可能性があります。 バウンスタイプが `Permanent` *(ハード)* のバウンス通知を受信した場合、この受取人に将来 E メールを送信できる可能性はありません。このため、バウンスを生じたアドレスを持つ受取人はメーリングリストから即座に削除してください。 **注記** *ソフトバウンス* (受取人の受信トレイがいっぱいであるなどの一時的な問題に伴うバウンス) が発生すると、SES は一定期間にわたり、E メールの再配信を試行します。この期間の終了時に、まだ E メールを送信できない場合、SES は試行を停止します。 SES は、ハードバウンスの通知に加えて、配信の試行を停止したソフトバウンスの通知を提供します。ソフトバウンスが発生するたびに通知を受信する場合は、[イベントの公開を有効](monitor-sending-using-event-publishing-setup.md)にし、配信遅延イベントが発生したときに通知を送信するように設定します。 | bounceType | bounceSubType | 説明 | | --- | --- | --- | | Undetermined | Undetermined | 受取人の E メールプロバイダーはバウンスメッセージを送信しました。バウンスメッセージには、SES がバウンスの理由を判断できるだけの十分な情報が含まれていませんでした。バウンスを生じた E メールのリターンパスヘッダーのアドレスに送信されたバウンス E メールには、E メールのバウンスを起こした問題について追加情報が含まれている可能性があります。 | | Permanent | General | 受取人の E メールプロバイダーはハードバウンスメッセージを送信しました。 このタイプのバウンス通知を受信した場合は、受取人の E メールアドレスをメーリングリストから即座に削除してください。ハードバウンスを生じたアドレスにメッセージを送信すると、送信者としての評価に悪影響を及ぼす可能性があります。ハードバウンスを生じたアドレスに E メールを送信し続けると、追加の E メールの送信機能が一時停止される場合があります。「[Amazon SES アカウントレベルのサプレッションリストの使用](sending-email-suppression-list.md)」を参照してください。 | | Permanent | NoEmail | バウンスメッセージから受信者のメールアドレスを取得できませんでした。 | | Permanent | Suppressed | 受信者の E メールアドレスは、最近の履歴でハードバウンスを生じているため、SES サプレッションリストに追加されています。グローバルサプレッションリストを上書きするには、「[Amazon SES アカウントレベルのサプレッションリストの使用](sending-email-suppression-list.md)」を参照してください。 | | Permanent | OnAccountSuppressionList | SES は、アドレスが[アカウントレベルのサプレッションリスト](sending-email-suppression-list.md)に追加されているため、このアドレスへの送信を抑制しました。これは、バウンス率のメトリクスに対してはカウントされません。 | | Permanent | UnsubscribedRecipient | このバウンスタイプは、受信者の連絡先がトピックから登録を解除し、[リスト管理オプション](sending-email-list-management.md#configuring-list-management-list-contacts)を使用してメールが受信者に送信された場合に発生します。SES は問い合わせ設定を尊重し、配信を試みません。また、このバウンスは、配信が試行されなかったために送信者の評価に影響を与えたり、バウンスが原因で受信者の連絡先がサプレッションリストに追加されたりすることはありません。 UnsubscribedRecipient イベントをサブスクライブして、登録されていない受信者に引き続き送信されないようにすることをお勧めします。「[リスト管理の使用](sending-email-list-management.md)」を検討してください。リスト管理は、サブスクライバーリストの信頼できるソースである必要があります。SES の強制適用の観点から、抑制された受信者または登録されていない受信者に送信を続けた場合、E メール送信のベストプラクティスに従っていないという評価を受けます。 | | Transient | General | 受取人の E メールプロバイダーは一般的なバウンスメッセージを送信しました。メッセージのバウンスを生じた問題が解決された場合、将来、同じ受取人にメッセージを送信できる可能性があります。 アクティブな自動応答ルール (不在メッセージなど) が設定されている受取人に E メールを送信すると、このタイプの通知を受け取る場合があります。レスポンスの通知タイプが `Bounce` であっても、SES は自動応答をカウントすることなくアカウントのバウンス率を計算します。 | | Transient | MailboxFull | 受取人の E メールプロバイダーは、受取人の受信トレイが満杯であるために、バウンスメッセージを送信しました。メールボックスが満杯でなくなった場合、将来、同じ受取人に送信できる可能性があります。 | | Transient | MessageTooLarge | 受取人の E メールプロバイダーは、受信したメッセージが大きすぎるために、バウンスメッセージを送信しました。メッセージのサイズを小さくすることで、同じ受取人にメッセージを送信できる可能性があります。 | | Transient | ContentRejected | 受取人の E メールプロバイダーは、受信したメッセージにプロバイダーが許可しないコンテンツが含まれていたために、バウンスメッセージを送信しました。メッセージのコンテンツを変更することで、同じ受取人にメッセージを送信できる可能性があります。 | | Transient | AttachmentRejected | 受取人の E メールプロバイダーは、メッセージ内に許容されないコンテンツが含まれていたために、バウンスメッセージを送信しました。たとえば、一部の E メールプロバイダーは特定のファイルタイプのファイルが添付されたメッセージや、非常に大きなファイルが添付されたメッセージを拒否する場合があります。添付ファイルのコンテンツを削除または変更することで、同じ受取人にメッセージを送信できる可能性があります。 | ## 苦情のオブジェクト 苦情に関する情報を含む JSON オブジェクトには以下のフィールドが含まれます。 | フィールド名 | 説明 | | --- | --- | | complainedRecipients | 苦情の原因である可能性がある受取人についての情報を含むリスト。詳細については、「[苦情を申告した受取人](#complained-recipients)」を参照してください。 | | timestamp | ISP が苦情通知を ISO 8601 形式で送信した日時。このフィールドの日時は、SES が通知を受信した日時とは同じでない可能性があります。 | | feedbackId | 苦情に関連付けられた一意の ID。 | | complaintSubType | `complaintSubType` フィールドの値は、null または `OnAccountSuppressionList` のいずれかになります。値が `OnAccountSuppressionList` の場合、SES はメッセージを受け入れますが、[アカウントレベルのサプレッションリスト](sending-email-suppression-list.md)に含まれているため、送信を試みません。 | また、フィードバックレポートが苦情に添付されている場合、以下のフィールドが示される場合があります。 | フィールド名 | 説明 | | --- | --- | | userAgent | フィードバックレポートの `User-Agent` フィールドの値。これは、レポートを生成したシステムの名前とバージョンを示します。 | | complaintFeedbackType | ISP から受け取ったフィードバックレポートの `Feedback-Type` フィールドの値。これには、フィードバックのタイプが含まれます。 | | arrivalDate | ISO 8601 形式のフィードバックレポートの `Arrival-Date` フィールドまたは `Received-Date` フィールドの値。このフィールドがレポートにない場合もあります (その場合、JSON オブジェクトにも表示されません)。 | 以下は、`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" } ``` ### 苦情を申告した受取人 `complainedRecipients` フィールドには、苦情の送信元と思われる受信者のリストが含まれます。この情報を使用して、苦情の送信元の受取人を特定し、この受取人をメーリングリストから即座に削除する必要があります。 **重要** ほとんどの ISP は、苦情の送信元である受取人の E メールアドレスを苦情通知から削除します。このため、このリストに含まれている苦情の送信元と思われる受信者に関する情報は、元のメッセージの受信者と、苦情の送信元の ISP に基づくものです。SES は、この受信者のリストを確認するために元のメッセージを参照します。 このリストの JSON オブジェクトには以下のフィールドが含まれます。 | フィールド名 | 説明 | | --- | --- | | emailAddress | 受取人の E メールアドレス。 | 以下は、苦情を申告した受取人のオブジェクトの例です。 ``` { "emailAddress": "recipient1@example.com" } ``` **注記** 受信者 1 人につき 1 つのメッセージが送信されるように制限している (BCC 行に 30 個の異なる E メールアドレスを指定して送信しない) 場合は、この動作を利用して、メッセージに関する苦情を伝えている E メールアドレスをより確実に特定することできます。 #### 苦情のタイプ `complaintFeedbackType` フィールドには以下の苦情のタイプが示されます ([Internet Assigned Numbers Authority ウェブサイト](http://www.iana.org/assignments/marf-parameters/marf-parameters.xml#marf-parameters-2) に基づいて、報告する ISP により割り当てられます)。 + `abuse` — 未承諾またはその他種類の不正使用メールを示します。 + `auth-failure` — E メールの認証の障害を示します。 + `fraud` — なんらかの詐欺またはフィッシング行為を示します。 + `not-spam` — レポートの提供者がこのメッセージをスパムではないと見なしていることを示します。このタイプは、誤ってスパムとしてタグ付けまたは分類されたメッセージを修正するために使用される場合があります。 + `other` — その他の登録されたタイプに該当しないフィードバックを示します。 + `virus` — 元のメッセージでウイルスが見つかったことを示します。 ## 配信オブジェクト 配信に関する情報を含む JSON オブジェクトには常に以下のフィールドがあります。 | フィールド名 | 説明 | | --- | --- | | timestamp | SES が E メールを受信者のメールサーバーに配信した時間 (ISO8601 形式)。 | | processingTimeMillis | SES が送信者からのリクエストを承諾したときから、受信者のメールサーバーにそのメッセージを渡したときまでの時間 (ミリ秒単位)。 | | recipients | 配信通知を適用する E メールの対象となる受信者のリスト。 | | smtpResponse | SES から E メールを受け取ったリモート ISP の SMTP 応答メッセージ。このメッセージは、E メール、受信メールサーバー、および受信 ISP ごとに異なります。 | | reportingMTA | メールを送信した SES メールサーバーのホスト名。 | | remoteMtaIp | SES が E メールを配信した先の MTA の IP アドレス。 | 以下は、`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" } ``` # Amazon SES の Amazon SNS 通知の例 以下のセクションでは、3 種類の通知の例を紹介します。 + バウンス通知の例については、「[Amazon SNS バウンス通知の例](#notification-examples-bounce)」を参照してください。 + 苦情通知の例については、「[Amazon SNS苦情通知の例](#notification-examples-complaint)」を参照してください。 + 配信通知の例については、「[Amazon SNS 配信通知の例](#notification-examples-delivery)」を参照してください。 ## Amazon SNS バウンス通知の例 このセクションには、フィードバックを送信した E メール受取人によって提供される配信ステータス通知 (DSN) を含むバウンス通知と含まないバウンス通知の例が記載されています。 ### DSNを含むバウンス通知 以下は、DSN および元の E メールヘッダーを含むバウンス通知の例です。バウンス通知が元の E メールヘッダーを含めるように設定されていない場合は、通知内の `mail` オブジェクトに `headersTruncated`、`headers` および `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" } } } ``` ### DSNを含まないバウンス通知 以下は、元の E メールヘッダーを含むが DSN を含まないバウンス通知の例です。バウンス通知が元の E メールヘッダーを含めるように設定されていない場合は、通知内の `mail` オブジェクトに `headersTruncated`、`headers` および `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" } } } ``` ## Amazon SNS苦情通知の例 このセクションには、フィードバックを送信した E メール受取人によって提供されるフィードバックレポートを含む苦情通知と含まない苦情通知の例が記載されています。 ### フィードバックレポートを含む苦情通知 以下は、フィードバックレポートおよび元の E メールヘッダーを含む苦情通知の例です。苦情通知が元の E メールヘッダーを含めるように設定されていない場合は、通知内の `mail` オブジェクトに `headersTruncated`、`headers` および `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" } } } ``` ### フィードバックレポートを含まない苦情通知 以下は、元の E メールヘッダーを含むがフィードバックレポートを含まない苦情通知の例です。苦情通知が元の E メールヘッダーを含めるように設定されていない場合は、通知内の `mail` オブジェクトに `headersTruncated`、`headers` および `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" } } } ``` ## Amazon SNS 配信通知の例 以下は、元の E メールヘッダーを含む配信通知の例です。配信通知が元の E メールヘッダーを含めるように設定されていない場合は、通知内の `mail` オブジェクトに `headersTruncated`、`headers` および `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" } } ``` # Amazon SES での ID 承認の使用 ID 承認ポリシーでは、その ID に対して許可または拒否される SES API アクションと条件を指定することで、個々の検証済み ID が Amazon SES をどのように使用できるかを定義します。 これらの承認ポリシーを使用することにより、いつでもアクセス許可を変更または取り消して、ID に対する制御を維持できます。他のユーザーが、そのユーザーの SES アカウントで、自分が所有する (ドメインまたはメールアドレス) ID を使用することを承認することもできます。 **Topics** + [Amazon SES ポリシーの構造分析](policy-anatomy.md) + [Amazon SES の ID 承認ポリシーの作成](identity-authorization-policies-creating.md) + [Amazon SES の ID ポリシーの例](identity-authorization-policy-examples.md) + [Amazon SES の ID 承認ポリシーの管理](managing-policies.md) # Amazon SES ポリシーの構造分析 ポリシーは特定の構造に準拠し、要素を含み、特定の要件を満たす必要があります。 ## ポリシーの構造 各承認ポリシーは、ID にアタッチされる JSON ドキュメントです。各ポリシーには以下のセクションがあります。 + ポリシー全体に関する情報 (ドキュメントの最上部)。 + 1 つ以上の個別のステートメント (それぞれが 1 セットのアクセス許可を説明)。 次のポリシー例では、検証済みドメイン *example.com* の*アクション*セクションで指定された AWS アカウント ID *123456789012* のアクセス許可を付与します。 ------ #### [ 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" ] } ] } ``` ------ 他の承認ポリシーの例については、「[ID ポリシーの例](identity-authorization-policy-examples.md)」を参照してください。 ## ポリシーの要素 このセクションでは、ID 承認ポリシーに含まれる要素について説明します。まず、ポリシー全体の要素について説明した後、その要素が含まれるステートメントにのみ適用される要素について説明します。その後、ステートメントに条件を追加する方法について説明します。 エレメントの構文の詳細については、[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies-grammar.html)の「*IAM ポリシー言語の文法*」を参照してください。 ### ポリシー全体に関する情報 ポリシー全体の要素として、`Id` と `Version` の 2 つがあります。次の表に、これらの要素についての情報を示します。 **** | 名前 | 説明 | 必須 | 有効な値 | | --- | --- | --- | --- | | `Id` | ポリシーを一意に識別します。 | いいえ | 任意の文字列 | | `Version` | ポリシーアクセス言語のバージョンを指定します。 | いいえ | 任意の文字列。ベストプラクティスとして、このフィールドに値 "2012-10-17" を含めることをお勧めします。 | ### 個別のポリシーに関するステートメント ID 承認ポリシーには、少なくとも 1 つのステートメントが必要です。各ステートメントには、次の表に示す要素を含めることができます。 **** | 名前 | 説明 | 必須 | 有効な値 | | --- | --- | --- | --- | | `Sid` | ステートメントを一意に識別します。 | いいえ | 任意の文字列。 | | `Effect` | 評価時にポリシーのステートメントによって返される結果を指定します。 | はい | "Allow" または "Deny"。 | | `Resource` | ポリシーが適用されるアイデンティティを指定します。 ([送信承認](sending-authorization-identity-owner-tasks-policy.md)の場合、これは ID 所有者が代理送信者に使用を承認するメールアドレスまたはドメインです)。 | はい | ID の Amazon リソースネーム (ARN)。 | | `Principal` | ステートメントで アクセス許可を受け取る AWS アカウント、ユーザー、または AWS サービスを指定します。 | はい | 有効な AWS アカウント ID、ユーザー ARN、または AWS service. AWS アカウント IDsとユーザー ARNsは を使用して指定します `"AWS"` (例: `"AWS": ["123456789012"]`または `"AWS": ["arn:aws:iam::123456789012:root"]`)。 AWS サービス名は を使用して指定します `"Service"` (例: `"Service": ["cognito-idp.amazonaws.com"]`)。 ユーザー ARN の形式の例については、「[AWS 全般のリファレンス](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-iam.html)」を参照してください。 | | `Action` | ステートメントが適用されるアクションを指定します。 | はい | "ses:BatchGetMetricData"、"ses:CancelExportJob"、"ses:CreateDeliverabilityTestReport"、"ses:CreateEmailIdentityPolicy"、"ses:CreateExportJob"、"ses:DeleteEmailIdentity"、"ses:DeleteEmailIdentityPolicy"、"ses:GetDomainStatisticsReport"、"ses:GetEmailIdentity"、"ses:GetEmailIdentityPolicies"、"ses:GetExportJob"、"ses:ListExportJobs"、"ses:ListRecommendations"、"ses:PutEmailIdentityConfigurationSetAttributes"、"ses:PutEmailIdentityDkimAttributes"、"ses:PutEmailIdentityDkimSigningAttributes"、"ses:PutEmailIdentityFeedbackAttributes"、"ses:PutEmailIdentityMailFromAttributes"、"ses:TagResource"、"ses:UntagResource"、"ses:UpdateEmailIdentityPolicy" ([送信承認](sending-authorization-identity-owner-tasks-policy.md)アクション: "ses:SendEmail"、"ses:SendRawEmail"、"ses:SendTemplatedEmail"、"ses:SendBulkTemplatedEmail") これらのオペレーションは 1 つ以上指定できます。 | | `Condition` | アクセス許可についての制限や詳細を指定します。 | いいえ | この表の後の条件についての情報を参照してください。 | ### 条件 *条件*は、ステートメントのアクセス権限に関する制限のことです。ステートメントの中でも、記述が最も詳細になるのが、この条件部分です。*キー*は、リクエストの日時など、アクセス制限に使用される基本項目です。 制限は、条件とキーの両方を使用して定義します。たとえば、代理送信者が 2019 年 7 月 30 日以降はお客様の代わりに Amazon SES にリクエストを行うことができないように制限する場合、`DateLessThan` という条件を使用します。キーは `aws:CurrentTime` を使用し、値を `2019-07-30T00:00:00Z` に設定します。 SES は、以下の AWS全体のポリシーキーのみを実装します。 + `aws:CurrentTime` + `aws:EpochTime` + `aws:SecureTransport` + `aws:SourceIp` + `aws:SourceVpc` + `aws:SourceVpce` + `aws:UserAgent` + `aws:VpcSourceIp` これらのキーについては、「 [IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_ElementDescriptions.html#Condition)」を参照してください。 ## ポリシーの要件 ポリシーは、以下の要件をすべて満たしている必要があります。 + 各ポリシーには、少なくとも 1 つのステートメントが含まれている必要があります。 + 各ポリシーには、少なくとも 1 つの有効なプリンシパルが含まれている必要があります。 + 各ポリシーには、1 つのリソースを指定する必要があります。またそのリソースは、ポリシーがアタッチされている ID の ARN である必要があります。 + アイデンティティ所有者は、最大 20 のポリシーにそれぞれ一意のアイデンティティを関連付けることができます。 + ポリシーのサイズが 4 キロバイト (KB) を超えることはできません。 + ポリシー名が 64 文字を超えることはできません。また、英数字、ダッシュ、アンダースコアのみを含めることができます。 # Amazon SES の ID 承認ポリシーの作成 ID 承認ポリシーは、特定の ID に対して許可または拒否される API アクションとその条件を指定するステートメントで構成されます。 所有する Amazon SES ドメインまたはメールアドレスを承認するには、承認ポリシーを作成し、そのポリシーを ID にアタッチします。ID には、0、1、または多くのポリシーを含めることができます。ただし、1 つのポリシーは 1 つの ID にのみ関連付けることができます。 ID 承認ポリシーで使用できる API アクションのリストについては、[個別のポリシーに関するステートメント](policy-anatomy.md#identity-authorization-policy-statements) テーブルの「*アクション*」行を参照してください。 ID 承認ポリシーは、次のような方法で作成できます。 + **Policy Generator を使用して** – SES コンソールで Policy Generator を使用することによって、シンプルなポリシーを作成できます。SES API アクションに対するアクセス許可を許可または拒否するだけでなく、アクションを条件で制約できます。さらに、Policy Generator を使用して、ポリシーの基本構造をすばやく作成した後、ポリシーを編集することでカスタマイズすることもできます。 + **カスタムポリシーの作成 –** より高度な条件を含めたり、 AWS サービスをプリンシパルとして使用したりする場合は、SES コンソールまたは SES API を使用してカスタムポリシーを作成し、アイデンティティにアタッチできます。 **Topics** + [Policy Generatorの使用](using-policy-generator.md) + [カスタムポリシーの作成](creating-custom-policy.md) # Policy Generatorの使用 Policy Generator を使用し、次の手順に従ってシンプルな送信承認ポリシーを作成できます。 **Policy Generatorを用してポリシーを作成するには** 1. AWS マネジメントコンソール にサインインし、Amazon SES コンソール ([https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)) を開きます。 1. ナビゲーションペインの **[設定]** で、**[ID]** を選択します。 1. **[ID]** 画面の **[ID]** コンテナで、認可ポリシーを作成する検証済み ID を選択します。 1. 前のステップで選択した検証済み ID の詳細画面で、**[Authorization]** (承認) タブを選択します。 1. **[Authorization policies]** (承認ポリシー) ペインで、**[Create policy]** (ポリシーの作成) を選択し、ドロップダウンから **[Use policy generator]** (Policy Generator の使用) を選択します。 1. **[Create statement]** (ステートメントの作成) ペインで、**効果**フィールドの **[Allow]** (許可) を選択します。(この ID を制限するポリシーを作成する場合は、代わりに **[Deny]** (拒否) を選択します)。 1. **プリンシパル**フィールドに、*AWS アカウント ID*、*IAM ユーザー ARN*、または AWS サービスを入力して、この ID に対して認可するアクセス許可を受け取り、**追加**を選択します。(複数を承認する場合は、それぞれについて、この手順を繰り返します)。 1. **[Actions]** (アクション) フィールドで、プリンシパルに対して承認する各アクションのチェックボックスをオンにします。 1. (オプション) アクセス許可に限定的なステートメントを追加する場合は、**[Specify conditions]** (条件を指定) を展開します。 1. **[Operator]** (演算子) ドロップダウンから演算子を選択します。 1. **[Key]** (キー) ドロップダウンからタイプを選択します。 1. 選択したキータイプに応じて、その値を**値**フィールドに入力します。(条件をさらに追加する場合は、**[Add new condition]** (新しい条件を追加) を選択します。条件を追加するたびに、この手順を繰り返します) 1. **[Save statement]** (ステートメントを保存) を選択します。 1. (オプション) ポリシーにステートメントを追加する場合は、**[Create another statement]** (別のステートメントを作成) を展開して、ステップ 6～10 を繰り返します。 1. **[次へ]** を選択すると、**[ポリシーのカスタマイズ]** 画面で、**[ポリシーの詳細の編集]** コンテナには、ポリシーの **[名前]** と **[ポリシードキュメント]** 自体を変更またはカスタマイズできるフィールドが表示されます。 1. **[Next]** (次へ) を選択すると、**[Review and apply]** (確認して適用) 画面の **[Overview]** (概要) コンテナに、承認する検証済み ID と、このポリシーの名前が表示されます。**[Policy document]** (ポリシードキュメント) ペインには、追加した条件とともに、作成した実際のポリシーが表示されます。ポリシーを確認し、内容が正しい場合は、**[Apply policy]** (ポリシーの適用) をクリックします。(変更や修正の必要がある場合は、**[Previous]** (戻る) をクリックして、**[Edit policy details]** (ポリシーの詳細の編集) コンテナで作業を行います) # カスタムポリシーの作成 カスタムポリシーを作成してアイデンティティにアタッチする場合、次のオプションがあります。 + **Amazon SES API の使用** – [Amazon Simple Email Service API リファレンス](https://docs.aws.amazon.com/ses/latest/APIReference/) で説明されている `PutIdentityPolicy` API を使用し、テキストエディタでポリシーを作成してアイデンティティにアタッチします。 + **Amazon SES コンソールの使用** – テキストエディタを使用してポリシーを作成し、それを Amazon SES コンソールのカスタムポリシーエディタに貼り付けることでアイデンティティにアタッチします。以下の手順では、この方法について説明します。 **カスタムポリシーエディタを使用してカスタムポリシーを作成するには** 1. AWS マネジメントコンソール にサインインし、Amazon SES コンソール ([https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)) を開きます。 1. ナビゲーションペインの **[設定]** で、**[ID]** を選択します。 1. **[ID]** 画面の **[ID]** コンテナで、認可ポリシーを作成する検証済み ID を選択します。 1. 前のステップで選択した検証済み ID の詳細画面で、**[Authorization]** (承認) タブを選択します。 1. **[Authorization policies]** (承認ポリシー) ペインで、**[Create policy]** (ポリシーの作成) を選択して、ドロップダウンから **[Create custom policy]** (カスタムポリシーの作成) を選択します。 1. **[Policy document]** (ポリシードキュメント) ペインで、JSON 形式のポリシーのテキストを入力または貼り付けます。Policy Generator を使用すると、基本的な構造のポリシーをすばやく作成でき、ここでカスタマイズすることもできます。 1. **[ポリシーを適用]** を選びます。(カスタムポリシーを変更する必要がある場合は、**[Authorization]** (承認) タブのチェックボックスをオンにし、**[Edit]** (編集) を選択して、**[Policy document]** (ポリシードキュメント) ペインで変更を行ってから、**[Save changes]** (変更の保存) を選択します） # Amazon SES の ID ポリシーの例 ID 承認を使用すると、ID の API アクションを許可または拒否する条件をきめ細かく指定することができます。 **Topics** + [プリンシパルの指定](#identity-authorization-policy-example-delegate-user) + [アクションの制限](#sending-authorization-policy-example-restricting-action) + [複数のステートメントの使用](#identity-authorization-policy-example-multiple-statements) ## プリンシパルの指定 アクセス許可を付与するエンティティである*プリンシパル*は、、 AWS アカウント AWS Identity and Access Management (IAM) ユーザー、または同じアカウントに属する AWS サービスです。 次の例は、 AWS ID *123456789012* が が所有する AWS アカウント 検証済み ID *example.com* を制御することを許可するシンプルなポリシーを示しています*123456789012*。 ------ #### [ 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" ] } ] } ``` ------ 次のポリシー例では、検証済み ID *example.com* を制御するアクセス許可を 2 人のユーザーに付与します。ユーザーは、Amazon リソースネーム (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" ] } ] } ``` ------ ## アクションの制限 承認する制御のレベルに応じて、ID 承認ポリシーで指定できる複数のアクションがあります。 ``` 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" ``` ID 承認ポリシーでは、プリンシパルをそれらのアクションの 1 つだけに制限することもできます。 ------ #### [ 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" ] } ] } ``` ------ ## 複数のステートメントの使用 ID 承認ポリシーには複数のステートメントを含めることができます。以下のサンプルポリシーには、2 つのステートメントが含まれています。最初のステートメントでは、2 人のユーザーが同じアカウント `123456789012` 内の *sender@example.com* から `getemailidentity` にアクセスすることを拒否します。2 つ目のステートメントでは、同じアカウント `123456789012` 内のプリンシパル *Jack* に対して `UpdateEmailIdentityPolicy` を拒否します。 ------ #### [ 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" ] } ] } ``` ------ # Amazon SES の ID 承認ポリシーの管理 ポリシーの作成と ID へのアタッチに加えて、以下のセクションで説明するように、ID のポリシーを編集、削除、リスト、取得することができます。 ## Amazon SES コンソールを使用してポリシーを管理する Amazon SES ポリシーの管理では、Amazon SES コンソールを使用して、ID にアタッチされたポリシーを表示、編集、または削除する必要があります。 **Amazon SES コンソールを使用してポリシーを管理するには** 1. AWS マネジメントコンソール にサインインし、Amazon SES コンソール ([https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)) を開きます。 1. 左のナビゲーションペインで、[**ID の検証**] を選択します。 1. ID のリストで、管理する ID を選択します。 1. ID の詳細ページで、**[Authorization]** (承認) タブに移動します。ここでは、この ID に添付されているすべてのポリシーの一覧が表示されます。 1. 管理するポリシーのチェックボックスをオンにします。 1. 求める管理タスクに応じて、次のようにそれぞれのボタンを選択します。 1. ポリシーを表示する場合は、**[View policy]** (ポリシーを表示) を選択します。コピーが必要な場合は、**[Copy]** (コピー) ボタンを選択すると、クリップボードにコピーされます。 1. ポリシーを編集する場合は、**[Edit]** (編集) を選択します。**[Policy document]** (ポリシードキュメント) ペインで、ポリシーを編集してから、**[Save changes]** (変更の保存) を選択します。 **注記** アクセス許可を取り消すには、ポリシーを編集または削除します。 1. ポリシーを削除する場合は、**[Delete]** (削除) を選択します。 **重要** ポリシーの削除は永続的です。ポリシーを削除する前に、テキストファイルにポリシーをコピーアンドペーストして、ポリシーをバックアップすることをお勧めします。 ## Amazon SES API を使用してポリシーを管理する Amazon SES ポリシーの管理では、Amazon SES API を使用して、ID にアタッチされたポリシーを表示、編集、または削除する必要があります。 **Amazon SES API を使用してポリシーを一覧表示と表示するには** + [ListIdentityPolicies](https://docs.aws.amazon.com/ses/latest/APIReference/API_ListIdentityPolicies.html) API オペレーションを使用して、ID にアタッチされたポリシーをリストできます。[GetIdentityPolicies](https://docs.aws.amazon.com/ses/latest/APIReference/API_GetIdentityPolicies.html) API オペレーションを使用することでポリシー自体を取得することもできます。 **Amazon SES API を使用してポリシーを編集するには** + [PutIdentityPolicy API 操作](https://docs.aws.amazon.com/ses/latest/APIReference/API_PutIdentityPolicy.html)を使用して、ID にアタッチされたポリシーを編集できます。 **Amazon SES API を使用してポリシーを削除するには** + [DeleteIdentityPolicy API 操作](https://docs.aws.amazon.com/ses/latest/APIReference/API_DeleteIdentityPolicy.html)を使用して、ID にアタッチされたポリシーを削除できます。 # Amazon SES での送信承認の使用 Amazon SES を設定することで、別のユーザーが、そのユーザーの Amazon SES アカウントを使用して、自分が所有する（ドメインまたは E メールアドレス）IDからEメールを送信することを許可できます。*送信承認*機能では、IDのコントロールは維持されるため、いつでもアクセス許可を変更または取り消すことができます。たとえば、ビジネスの所有者は、送信承認を使用することで、サードパーティー (E メールマーケティング会社など) の E メールを、自分が所有するドメインから送信できるようにすることができます。 この章では、従来のクロスアカウント通知機能に代わる送信承認の詳細について説明します。まず、承認ポリシーの構造分析やポリシーの管理方法などの重要なトピックに関する [Amazon SES での ID 承認の使用](identity-authorization-policies.md) で説明されているように、承認ポリシーを使用した ID ベースの承認の基本を理解する必要があります。 ## クロスアカウント通知のレガシーサポート ID 所有者によって検証済み ID の 1 つから送信することを代理送信者が許可され、送信する E メールに関連付けられたバウンス、苦情、および配信に関するフィードバック通知は、従来、クロスアカウント通知を使用して設定されていました。この場合、代理送信者が所有していない ID にトピックを関連付けていました (これがクロスアカウントです)。ただし、クロスアカウント通知は、代理送信に関連して設定セットと検証済み ID を使用して置き換えられました。この場合、代理送信者は、ID 所有者によって、検証済み ID の 1 つを使用して E メールを送信することを承認されています。この新しい方法では、代理送信者であるか、検証済み ID の所有者であるかに応じて、バウンス、苦情、配信、およびその他のイベント通知を次の 2 つの構成で柔軟に設定できます。 + **設定セット** – 代理送信者は、自分の所有ではないが、承認ポリシーによって ID 所有者から送信を許可された検証済み ID から E メールを送信するとき、指定可能な独自の設定セットでイベント発行をセットアップできます。イベント発行を使用すると、バウンス通知、苦情通知、配信通知、およびその他のイベント通知を Amazon CloudWatch、Amazon Data Firehose、Amazon Pinpoint、Amazon SNS に発行できます。「[イベント送信先の作成](event-destinations-manage.md)」を参照してください。 + **検証済み ID** – ID 所有者は、代理送信者が検証済み ID のいずれかを使用して E メールを送信することを許可するだけでなく、代理送信者のリクエストに応じて、共有 ID でフィードバック通知を設定して、代理送信者が所有する SNS トピックを使用することもできます。代理送信者が SNS トピックを所有するため、代理送信者だけがこれらの通知を受け取ります。[「所有していない SNS トピック」を設定](sending-authorization-identity-owner-tasks-policy.md#configure-sns-topic-you-dont-own)する方法については、承認ポリシーの手順にあるステップ 14 を参照してください。 **注記** アカウント内で現在使用されているレガシークロスアカウント通知の互換性を保つため、クロスアカウント通知がサポートされています。このサポートは、Amazon SES クラシックコンソールで作成した現在のクロスアカウントの変更と使用に限られています。ただし、*新しい*クロスアカウント通知を作成することはできなくなっています。Amazon SES の新しいコンソールで新しいクロスアカウント通知を作成するには、[イベント発行](event-destinations-manage.md)を使用した設定セット、または[独自の SNS トピックで設定された](sending-authorization-identity-owner-tasks-policy.md#configure-sns-topic-you-dont-own)検証済み ID を利用して代理送信という新しい方法を適用します。 **Topics** + [クロスアカウント通知のレガシーサポート](#sending-authorization-cross-account-sunsetting) + [Amazon SESの送信承認の概要](sending-authorization-overview.md) + [Amazon SES送信承認を行うためのID所有者のタスク](sending-authorization-identity-owner-tasks.md) + [Amazon SESの送信承認を行うための代理送信者のタスク](sending-authorization-delegate-sender-tasks.md) # Amazon SESの送信承認の概要 このトピックでは、送信承認プロセスの概要を示し、送信承認と Amazon SES の E メール送信機能 (送信クォータや通知など) がどのように関係するかについて説明します。 このセクションでは以下の用語を使用します。 + **アイデンティティ** – Amazon SES ユーザーが E メールの送信に使用する E メールアドレスまたはドメイン。 + **アイデンティティ所有者** – 「[検証済みID](verify-addresses-and-domains.md)」の手順を使用して、E メールアドレスまたはドメインの所有権を検証した Amazon SES ユーザー。 + **代理送信者** – AWS アカウント、 AWS Identity and Access Management (IAM) ユーザー、または ID 所有者に代わって E メールを送信する認可ポリシーを通じて承認された AWS サービス。 + **送信承認ポリシー** – アイデンティティにアタッチすることで、そのアイデンティティを使用して送信できるユーザーとその条件を指定できるドキュメント。 + **Amazon リソースネーム (ARN)** – すべての AWS サービスで AWS リソースを一意に識別するための標準化された方法です。送信承認の場合、リソースは、ID 所有者が代理送信者に使用を許可した ID です。ARN の例は *arn:aws:ses:us-east-1:123456789012:identity/example.com* などです。 ## 送信承認プロセス 送信承認は、送信承認ポリシーに基づいています。代理送信者が代わりに送信できるようにする場合、Amazon SES コンソールまたは Amazon SES API を使用して、送信承認ポリシーを作成してポリシーを ID に関連付けます。代理送信者がお客様の代わりに Amazon SES を通じて E メールを送信するとき、代理送信者はリクエストまたは E メールのヘッダーで ID の ARN を渡します。 Amazon SES は、E メール送信リクエストを受け取ると、ID のポリシーを確認し（存在する場合）、代理送信者がその ID の代わりに送信することが承認されているかどうかを判断します。代理送信者が承認されている場合、Amazon SES は E メールを受け入れます。承認されていない場合、Amazon SES はエラーメッセージを返します。 次の図は、送信承認の各概念の間の全体的な関係を示しています。 ![\[送信承認の概要\]](http://docs.aws.amazon.com/ja_jp/ses/latest/dg/images/sending_authorization_overview.png) 送信承認のプロセスは、以下のステップで構成されています。 1. ID 所有者は、代理送信者が使用する検証済み ID を選択します。ID が検証済みでない場合は、「[検証済みID](verify-addresses-and-domains.md)」を参照してください。 **注記** 代理送信者のために選択した検証済み ID には、[デフォルト設定セット](managing-configuration-sets.md#default-config-sets)を割り当てることができません。 1. 代理送信者は、送信に使用する AWS アカウント ID または IAM ユーザー ARN を ID 所有者に知らせます。 1. 代理送信者が ID 所有者のいずれかのアカウントから送信することを許可するよう ID 所有者が同意した場合、ID 所有者は Amazon SES コンソールまたは Amazon SES API を使用して送信承認ポリシーを作成し、そのポリシーを選択した ID にアタッチします。 1. ID 所有者が代理送信者に承認済み ID の ARN を付与し、代理送信者が E メールの送信時に Amazon SES に ARN を提供できるようにします。 1. 代理送信者は、代理送信時に指定された設定セットで有効になっている[イベント発行](monitor-using-event-publishing.md)を使用して、バウンスや苦情の通知を設定できます。ID 所有者は、バウンスや苦情のイベントに関する E メールフィードバック通知を代理送信者の Amazon SNS トピックに送信するように設定することもできます。 **注記** ID 所有者が送信イベント通知を無効にする場合、代理送信者は、バウンスイベントと苦情イベントを Amazon SNS トピックまたは Firehose ストリームに公開するようにイベント発行を設定する必要があります。送信者は、送信する各 E メールにイベント発行ルールを含む設定セットも適用する必要があります。ID 所有者および代理送信者のいずれも、バウンスイベントと苦情イベントの通知を送信する方法を設定していない場合、または送信者がイベント公開ルールを使用する設定セットを適用しない場合は、ID 所有者が E メールのフィードバック転送を無効にしていても、Amazon SES は、E メールの Return-Path フィールドのアドレス (または Return-Path アドレスを指定しなかった場合はソースフィールド) に自動的にイベント通知を E メールで送信します。 1. 代理送信者は、リクエストまたは E メールのヘッダーで ID 所有者の ID の ARN を渡すことで、ID 所有者の代わりに Amazon SES を通じて E メールを送信します。代理送信者は、Amazon SES SMTP インターフェイスまたは Amazon SES API を使用して E メールを送信できます。Amazon SES は、リクエストを受け取ると、ID にアタッチされたポリシーを調べ、代理送信者が指定された 「From」アドレスと「Return Path」アドレスの使用を承認されている場合は E メールを受け入れます。承認されていない場合、Amazon SES はエラーを返し、メッセージを受け入れません。 **重要** 代理送信者の AWS アカウントは、検証されていないアドレスに E メールを送信するために使用する前に、サンドボックスから削除する必要があります。 1. ID 所有者が代理送信者の承認を解除する場合は、ID 所有者が送信承認ポリシーを編集するか、ポリシーを完全に削除します。ID 所有者は、Amazon SES コンソールまたは Amazon SES API を使用してどちらのアクションも実行できます。 ID所有者または代理所有者がこれらのタスクを実行する方法の詳細については、それぞれ「[ID所有者のタスク](sending-authorization-identity-owner-tasks.md)」または「[代理送信者のタスク](sending-authorization-delegate-sender-tasks.md)」を参照してください。 ## Eメール送信機能の属性 日次送信クォータ、返送と苦情、DKIM 署名、フィードバック転送などの Amazon SES E メール送信機能に関して、代理送信者とID所有者の役割を理解しておくことが重要です。属性は次のとおりです。 + **送信クォータ** – ID所有者のIDから送信される E メールは、代理送信者のクォータにカウントされます。 + **バウンスと苦情** – バウンスおよび苦情イベントは、代理送信者の Amazon SES アカウントに記録されます。したがって、代理送信者の評価に影響を及ぼします。 + **DKIM 署名** – アイデンティティ所有者がアイデンティティの Easy DKIM 署名を有効にした場合、そのアイデンティティから送信されるすべての E メール (代理送信者が送信した E メールを含む) が DKIM 署名されます。E メールが DKIM 署名されるかどうかをコントロールできるのはアイデンティティ所有者だけです。 + **通知** – アイデンティティ所有者と代理送信者のいずれも、バウンスと苦情に関する通知を設定できます。E メールのアイデンティティ所有者は、E メールのフィードバック転送を有効にすることもできます。通知のセットアップについては、「[Amazon SES 送信アクティビティのモニタリング](monitor-sending-activity.md)」を参照してください。 + **検証** – アイデンティティ所有者には、「[検証済みID](verify-addresses-and-domains.md)」の手順に従って、代理送信者に試用を許可する E メールアドレスとドメインを自分が所有していることを検証する責任があります。代理送信者は、送信許可用に指定されたEメールアドレスまたはドメインを検証する必要はありません。 **重要** 代理送信者の AWS アカウントは、検証されていないアドレスに E メールを送信するために使用する前に、サンドボックスから削除する必要があります。 + **AWS リージョン** – 代理送信者は、ID 所有者の ID が検証された AWS リージョンから E メールを送信する必要があります。代理送信者にアクセス許可を付与する承認の送信ポリシーは、その地域のアイデンティティにアタッチする必要があります。 + **請求** – 代理送信者のアカウントから送信されるすべてのメッセージ (代理送信者がアイデンティティ所有者のアドレスを使用して送信する E メールを含む) の料金は、代理送信者に請求されます。 # Amazon SES送信承認を行うためのID所有者のタスク このセクションでは、送信承認の設定時にアイデンティティ所有者が実行する必要がある手順について説明します。 **Topics** + [Amazon SESの送信承認を行うためのIDの検証](sending-authorization-identity-owner-tasks-verification.md) + [Amazon SESの送信承認に使用するID所有者通知の設定](sending-authorization-identity-owner-tasks-notifications.md) + [Amazon SESの送信承認を行うための代理送信者からの情報の入手](sending-authorization-identity-owner-tasks-information.md) + [Amazon SESの送信承認ポリシーの作成](sending-authorization-identity-owner-tasks-policy.md) + [送信ポリシーの例](sending-authorization-policy-examples.md) + [Amazon SESの送信承認に使用するID情報の代理送信者への提供](sending-authorization-identity-owner-tasks-identity.md) # Amazon SESの送信承認を行うためのIDの検証 送信承認を設定するための最初の手順は、代理送信者が E メールを送信する E メールアドレスまたはドメインを自分が所有していることを証明することです。検証手順については、「[検証済みID](verify-addresses-and-domains.md)」を参照してください。 E メールアドレスまたはドメインが検証されていることを確認するには、[https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/) の Verified Identities セクションでそのステータスを確認するか、 `GetIdentityVerificationAttributes` API オペレーションを使用します。 ユーザーまたは代理送信者が、検証されていない E メールアドレスに E メールを送信するには、アカウントを Amazon SES サンドボックスから削除するリクエストを送信する必要があります。詳細については、「[本稼働アクセスのリクエスト (Amazon SES サンドボックスからの移行)](request-production-access.md)」を参照してください。 **重要** 代理送信者 AWS アカウント の は、検証されていないアドレスとの間で E メールを送信するために使用する前に、サンドボックスから削除する必要があります。 アカウントがサンドボックス内にある場合、ドメインやメールアドレスが ID アカウントで検証済みであっても、アカウントで検証されていないメールアドレスに送信することはできません。 # Amazon SESの送信承認に使用するID所有者通知の設定 代理送信者がお客様の代わりに E メールを送信することを承認する場合、Amazon SES は、それらの E メールが生成するすべてのバウンスと苦情は、お客様ではなく代理送信者のバウンスと苦情の制限に対してカウントします。ただし、代理送信者から送信されたメッセージの結果、IP アドレスがサードパーティーのスパム対策 DNS ベースのブラックホールリスト (DNSBL) に表示される場合、ID の評価が損なわれる可能性があります。このため、お客様が ID 所有者である場合は、代理送信を許可した ID を含め、すべての ID に対して E メールフィードバック転送を設定する必要があります。詳細については、「[E メールを介したAmazon SES に関する通知の受信](monitor-sending-activity-using-notifications-email.md)」を参照してください。 代理送信者は、お客様が使用を許可した ID に対して、独自のバウンスおよび苦情の通知を設定する必要があります。[イベント発行](monitor-using-event-publishing.md)は、Amazon SNS トピックまたは Firehose ストリームにバウンスイベントや苦情イベントを発行するように設定できます。 ID 所有者および代理送信者のいずれも、バウンスイベントと苦情イベントの通知を送信する方法を設定していない場合、または送信者がイベント公開ルールを使用する設定セットを適用しない場合は、E メールのフィードバック転送を無効にしていても、Amazon SES は、E メールの Return-Path フィールドのアドレス (または Return-Path アドレスを指定しなかった場合はソースフィールド) に自動的にイベント通知を E メールで送信します。次のイメージは、このプロセスを示したものです。 ![\[Flowchart showing notification paths for bounce/complaint events based on various settings.\]](http://docs.aws.amazon.com/ja_jp/ses/latest/dg/images/feedback_forwarding.png) # Amazon SESの送信承認を行うための代理送信者からの情報の入手 送信承認ポリシーでは、少なくとも 1 つの*プリンシパル*を指定する必要があります。プリンシパルとは、検証済み ID のいずれかの代わりに送信できるようにアクセスを許可している代理送信者のエンティティです。Amazon SES 送信承認ポリシーの場合、プリンシパルは代理送信者の AWS アカウントまたは AWS Identity and Access Management (IAM) ユーザー ARN、または AWS サービスのいずれかになります。 簡単に言うと、*プリンシパル* (代理送信者) は被付与者であり、お客様 (ID 所有者) は承認ポリシーの付与者になります。お客様 (ID 所有者) が、E メール、raw E メール、テンプレートに基づく E メール、またはテンプレートに基づくバルク E メールの任意の組み合わせを、所有する*リソース* (検証済み ID) から送信するための *Allow*アクセス許可をプリンシパルに付与します。 できる限り細かくコントロールしたい場合は、代理送信者の AWS アカウントに含まれるすべてのユーザーではなく 1 人の代理送信者だけがお客様の代わりに送信できるように、IAM ユーザーの設定を代理送信者に依頼してください。代理送信者が IAM ユーザーを設定するための情報は、*IAM ユーザーガイド*の「[AWS アカウントでの IAM ユーザーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/Using_SettingUpUser.html)」にあります。 代理送信者に AWS アカウント ID または IAM ユーザーの Amazon リソースネーム (ARN) を問い合わせて、送信承認ポリシーに含めることができるようにします。代理送信者には、「[ID所有者への情報提供](sending-authorization-delegate-sender-tasks-information.md)」にあるこの情報を調べるための手順を参照してもらいます。代理送信者が AWS サービスである場合は、そのサービスのドキュメントを参照してサービス名を確認してください。 次のポリシー例は、ID 所有者のリソースからの送信を代理送信者に許可するために、ID 所有者が作成するポリシーで必要とされる基本的要素を示しています。ID 所有者は検証済み ID ワークフローに移動し、[Authorization] (認可) で Policy Generator を使用して、ID 所有者が所有するリソースの代わりに代理送信者が送信できるようにする次の基本ポリシーを最もシンプルな形式で作成します。 ------ #### [ 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": {} } ] } ``` ------ 上記のポリシーについては、次の凡例で主な要素とその所有者を説明します。 + **プリンシパル** – このフィールドには、代理送信者の IAM ユーザーの ARN が入力されます。 + **アクション** – このフィールドには、2 つの SES アクション (`SendEmail` および `SendRawEmail`) が入力されます。これらは、ID 所有者が代理送信者に ID 所有者のリソースからの実行を許可するものです。 + **リソース** – このフィールドには、代理送信者に送信を許可している ID 所有者の検証済みリソースが入力されます。 # Amazon SESの送信承認ポリシーの作成 [ID 承認ポリシーの作成](identity-authorization-policies-creating.md) で説明されている Amazon SES での承認ポリシーの作成と同様に、所有するメールアドレスまたはドメイン (*ID*) を使用してメールを送信することを代理送信者に許可するには、SES 送信 API アクションを指定してポリシーを作成し、そのポリシーを ID にアタッチします。 送信承認ポリシーで指定できる API アクションのリストについては、[個別のポリシーに関するステートメント](policy-anatomy.md#identity-authorization-policy-statements) テーブルの「*アクション*」行を参照してください。 送信承認ポリシーは、Policy Generator を使用するか、カスタムポリシーを作成することで作成できます。いずれの方法でも、送信承認ポリシーの作成に固有の手順が提供されています。 **注記** E メールアドレス ID にアタッチする送信承認ポリシーは、対応するドメイン ID にアタッチするポリシーよりも優先されます。例えば、*example.com* に対して代理送信者を許可しないポリシーを作成し、*sender@example.com* に対して代理送信者を許可するポリシーを作成した場合、代理送信者は *sender@example.com* からメールを送信できますが、*example.com* ドメイン内の他のアドレスからは送信できません。 代理送信者を許可する *example.com* のポリシーを作成し、代理送信者を拒否する *sender@example.com* のポリシーを作成した場合、代理送信者は *example.com* ドメインの任意のアドレスからメールを送信できますが、* sender@example.com* ドメインの他のアドレスから送信することはできません。 SES 承認ポリシーの構造に慣れていない場合は、[ポリシー分析](policy-anatomy.md) を参照してください。 承認する ID が[グローバルエンドポイント](global-endpoints.md)機能の一部としてセカンダリリージョンで複製されている場合は、プライマリリージョンとセカンダリリージョンの両方で ID の送信認可ポリシーを作成して、代理送信者が両方のリージョンでの送信のために、この ID を使用するためのアクセス許可を持つようにする必要があります。 ## Policy Generator を使用して送信承認ポリシーを作成する Policy Generator を使用し、次の手順に従って送信承認ポリシーを作成できます。 **Policy Generator を使用して送信承認ポリシーを作成するには** 1. AWS マネジメントコンソール にサインインし、Amazon SES コンソール ([https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)) を開きます。 1. ナビゲーションペインの **[設定]** で、**[ID]** を選択します。 1. **[Verified identities]** (検証済み ID) 画面の **[Identities]** (ID) コンテナで、代理送信者がお客様の代わりに送信することを許可する検証済み ID を選択します。 1. 検証済み ID の **[承認]** タブをクリックします。 1. **[Authorization policies]** (承認ポリシー) ペインで、**[Create policy]** (ポリシーの作成) を選択し、ドロップダウンから **[Use policy generator]** (Policy Generator の使用) を選択します。 1. **[Create statement]** (ステートメントの作成) ペインで、**効果**フィールドの **[Allow]** (許可) を選択します。(代理送信者を制限するポリシーを作成する場合は、代わりに **[Deny]** (拒否) を選択します) 1. **プリンシパル**フィールドに、代理送信者が共有した *AWS アカウント ID* または *IAM ユーザー ARN* を入力して、代理送信者がこの ID のアカウントの代わりに E メールを送信することを許可してから、**[Add]** (追加) を選択します。(複数の代理送信者を承認する場合は、各代理送信者に対してこの手順を繰り返します) 1. **アクション**フィールドで、代理送信者に許可する各送信タイプのチェックボックスをオンにします。 1. (オプション) 代理送信者アクセス許可に限定的なステートメントを追加する場合は、**[Specify conditions]** (条件を指定) を展開します。 1. **[Operator]** (演算子) ドロップダウンから演算子を選択します。 1. **[Key]** (キー) ドロップダウンからタイプを選択します。 1. 選択したキータイプに応じて、その値を**値**フィールドに入力します。(条件をさらに追加する場合は、**[Add new condition]** (新しい条件を追加) を選択します。条件を追加するたびに、この手順を繰り返します) 1. **[Save statement]** (ステートメントを保存) を選択します。 1. (オプション) ポリシーにステートメントを追加する場合は、**[Create another statement]** (別のステートメントを作成) を展開して、ステップ 6～10 を繰り返します。 1. **[次へ]** を選択すると、**[ポリシーのカスタマイズ]** 画面で、**[ポリシーの詳細の編集]** コンテナには、ポリシーの **[名前]** と **[ポリシードキュメント]** 自体を変更またはカスタマイズできるフィールドが表示されます。 1. **[Next]** (次へ) をクリックすると、**[Review and apply]** (確認して適用) 画面の **[Overview]** (概要) コンテナには、代理送信者に対して許可している検証済み ID と、このポリシーの名前が表示されます。**[Policy document]** (ポリシードキュメント) ペインには、追加した条件とともに、作成した実際のポリシーが表示されます。ポリシーを確認し、内容が正しい場合は、**[Apply policy]** (ポリシーの適用) をクリックします。(変更や修正の必要がある場合は、**[Previous]** (戻る) をクリックして、**[Edit policy details]** (ポリシーの詳細の編集) コンテナで作業を行います) 作成したポリシーにより、代理送信者がお客様の代わりに送信できるようになります。 1. (オプション) 代理送信者が自分が所有する SNS トピックを使用する場合、バウンスや苦情の受信時、または E メールが配信されたときにフィードバック通知を受信する場合は、この検証済み ID にその SNS トピックを設定する必要があります。(代理送信者は、自分の SNS トピック ARN を共有する必要があります) **[Notifications]** (通知) タブを選択し、**[Feedback notifications]** (フィードバック通知) コンテナの **[Edit]** (編集) を選択します。 1. **[Configure SNS topics]** (SNS トピックを設定) ペインのいずれかのフィードバックフィールド (バウンス、苦情、または配信) で、**[SNS topic you don't own]** (所有していない SNS トピック) を選択して、代理送信者が所有し、共有する **[SNS topic ARN]** (SNS トピックの ARN) を入力します。(代理送信者が SNS トピックを所有するため、代理送信者だけがこれらの通知を受け取ります。ID 所有者が受け取ることはありません) 1. (オプション) 元の E メールのヘッダーをトピック通知に含める場合は、各フィードバックタイプの SNS トピック名のすぐ下にある **[Include original email headers]** (元の E メールヘッダーを含める) ボックスにチェックを入れます。このオプションは、その通知タイプに Amazon SNS トピックを割り当てている場合にのみ使用できます。元の E メールヘッダーの内容については、[通知の内容](notification-contents.md)の `mail` オブジェクトを参照してください。 1. **[Save changes]** (変更の保存) をクリックします。通知設定に対する変更は、反映されるまでに数分かかる場合があります。 1. (オプション) 代理送信者が、バウンスや苦情に関する Amazon SNS トピック通知を受け取るため、この ID の送信に関するフィードバックを受信しない場合は、E メール通知を完全に無効にすることができます。バウンスや苦情に関する E メールフィードバックを無効にするには、**[Notifications]** (通知) タブの **[Email Feedback Forwarding]** (E メールのフィードバック転送) コンテナで、**[Edit]** (編集) を選択し、**[Enabled]** (有効) ボックスのチェックを外して、**[Save changes]** (変更の保存) を選択します。配信ステータス通知が、代理送信者が所有する SNS トピックにのみ送信されるようになりました。 ## カスタム送信承認ポリシーの作成 カスタム送信承認ポリシーを作成して、アイデンティティにアタッチする場合、次のオプションがあります。 + **Amazon SES API の使用** – [Amazon Simple Email Service API リファレンス](https://docs.aws.amazon.com/ses/latest/APIReference/) で説明されている `PutIdentityPolicy` API を使用し、テキストエディタでポリシーを作成してアイデンティティにアタッチします。 + **Amazon SES コンソールの使用** – テキストエディタを使用してポリシーを作成し、それを Amazon SES コンソールのカスタムポリシーエディタに貼り付けることでアイデンティティにアタッチします。以下の手順では、この方法について説明します。 **カスタムポリシーエディタを使用してカスタム送信承認ポリシーを作成するには** 1. AWS マネジメントコンソール にサインインし、Amazon SES コンソール ([https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)) を開きます。 1. ナビゲーションペインの **[設定]** で、**[ID]** を選択します。 1. **[Verified identities]** (検証済み ID) 画面の **[Identities]** (ID) コンテナで、代理送信者がお客様の代わりに送信することを許可する検証済み ID を選択します。 1. 前のステップで選択した検証済み ID の詳細画面で、**[Authorization]** (承認) タブを選択します。 1. **[Authorization policies]** (承認ポリシー) ペインで、**[Create policy]** (ポリシーの作成) を選択して、ドロップダウンから **[Create custom policy]** (カスタムポリシーの作成) を選択します。 1. **[Policy document]** (ポリシードキュメント) ペインで、JSON 形式のポリシーのテキストを入力または貼り付けます。Policy Generator を使用すると、基本的な構造のポリシーをすばやく作成でき、ここでカスタマイズすることもできます。 1. **[ポリシーを適用]** を選びます。(カスタムポリシーを変更する必要がある場合は、**[Authorization]** (承認) タブのチェックボックスをオンにし、**[Edit]** (編集) を選択して、**[Policy document]** (ポリシードキュメント) ペインで変更を行ってから、**[Save changes]** (変更の保存) を選択します） 1. (オプション) 代理送信者が自分が所有する SNS トピックを使用する場合、バウンスや苦情の受信時、または E メールが配信されたときにフィードバック通知を受信する場合は、この検証済み ID にその SNS トピックを設定する必要があります。(代理送信者は、自分の SNS トピック ARN を共有する必要があります) **[Notifications]** (通知) タブを選択し、**[Feedback notifications]** (フィードバック通知) コンテナの **[Edit]** (編集) を選択します。 1. **[Configure SNS topics]** (SNS トピックを設定) ペインのいずれかのフィードバックフィールド (バウンス、苦情、または配信) で、**[SNS topic you don't own]** (所有していない SNS トピック) を選択して、代理送信者が所有し、共有する **[SNS topic ARN]** (SNS トピックの ARN) を入力します。(代理送信者が SNS トピックを所有するため、代理送信者だけがこれらの通知を受け取ります。ID 所有者が受け取ることはありません) 1. (オプション) 元の E メールのヘッダーをトピック通知に含める場合は、各フィードバックタイプの SNS トピック名のすぐ下にある **[Include original email headers]** (元の E メールヘッダーを含める) ボックスにチェックを入れます。このオプションは、その通知タイプに Amazon SNS トピックを割り当てている場合にのみ使用できます。元の E メールヘッダーの内容については、[通知の内容](notification-contents.md)の `mail` オブジェクトを参照してください。 1. **[Save changes]** (変更の保存) をクリックします。通知設定に対する変更は、反映されるまでに数分かかる場合があります。 1. (オプション) 代理送信者が、バウンスや苦情に関する Amazon SNS トピック通知を受け取るため、この ID の送信に関するフィードバックを受信しない場合は、E メール通知を完全に無効にすることができます。バウンスや苦情に関する E メールフィードバックを無効にするには、**[Notifications]** (通知) タブの **[Email Feedback Forwarding]** (E メールのフィードバック転送) コンテナで、**[Edit]** (編集) を選択し、**[Enabled]** (有効) ボックスのチェックを外して、**[Save changes]** (変更の保存) を選択します。配信ステータス通知が、代理送信者が所有する SNS トピックにのみ送信されるようになりました。 # 送信ポリシーの例 送信承認では、代理送信者に代理送信を許可する際の細かい条件を指定することができます。 **Topics** + [送信承認に固有の条件](#sending-authorization-policy-conditions) + [代理送信者の指定](#sending-authorization-policy-example-sender) + [「From」アドレスの制限](#sending-authorization-policy-example-from) + [代理送信者による E メール送信時間に対する制限](#sending-authorization-policy-example-time) + [E メール送信アクションの制限](#sending-authorization-policy-example-action) + [E メール送信者の表示名の制限](#sending-authorization-policy-example-display-name) + [複数のステートメントの使用](#sending-authorization-policy-example-multiple-statements) ## 送信承認に固有の条件 *条件*は、ステートメントのアクセス権限に関する制限のことです。ステートメントの中でも、記述が最も詳細になるのが、この条件部分です。*キー*は、リクエストの日時など、アクセス制限に使用される基本項目です。 制限は、条件とキーの両方を使用して定義します。たとえば、代理送信者が 2019 年 7 月 30 日以降はお客様の代わりに Amazon SES にリクエストを行うことができないように制限する場合、`DateLessThan` という条件を使用します。キーは `aws:CurrentTime` を使用し、値を `2019-07-30T00:00:00Z` に設定します。 *IAM ユーザーガイド*の[「使用可能なキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_ElementDescriptions.html#AvailableKeys)」に記載されているすべての AWSキーを使用できます。または、承認ポリシーの送信に役立つ SES に固有の次のいずれかのキーを使用できます。 **** | 条件キー | 説明 | | --- | --- | | `ses:Recipients` | 受取人アドレスを制限します。To:、"CC"、"BCC" アドレスが含まれます。 | | `ses:FromAddress` | 「From」アドレスを制限します。 | | `ses:FromDisplayName` | 「From」表示名として使用される文字列の内容を制限します ("フレンドリ名" と呼ばれることもあります)。たとえば、"John Doe " の表示名は John Doe です。 | | `ses:FeedbackAddress` | 「Return Path」アドレス (E メールのフィードバック転送によりバウンスや苦情を送信できるアドレス) を制限します。E メールのフィードバック転送の詳細については、「[E メールを介したAmazon SES に関する通知の受信](monitor-sending-activity-using-notifications-email.md)」を参照してください。 | Amazon SES キーで `StringEquals` 条件および `StringLike` 条件を使用することができます。これらの条件は、大文字小文字を区別する文字列の一致を指定するために使用します。`StringLike` の場合、値には、複数文字一致のワイルドカード (\$1) または 1 文字一致のワイルドカード (?) を指定できます。文字列のどこにでも含めることができます。たとえば、次の条件は、先頭に「*invoicing*」、末尾に「*@example.com*」が付いた「From」アドレスからのみ代理送信者が送信できることを指定します。 ``` 1. "Condition": { 2. "StringLike": { 3. "ses:FromAddress": "invoicing*@example.com" 4. } 5. } ``` また、`StringNotLike` 条件を使用して、代理送信者が特定の E メールアドレスから E メールを送信できないようにすることもできます。例えば、*admin@example.com* や同様の E メールアドレス (*"admin"@example.com*、*admin\$11@example.com*、*sender@admin.example.com* など) からの送信を禁止するには、ポリシーステートメントに次の条件を含めます。 ``` 1. "Condition": { 2. "StringNotLike": { 3. "ses:FromAddress": "*admin*example.com" 4. } 5. } ``` 条件の指定方法の詳細については、[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) の「*IAM JSON ポリシーエレメント: 条件*」を参照してください。 ## 代理送信者の指定 アクセス許可を付与するエンティティである*プリンシパル*は、、 AWS アカウント AWS Identity and Access Management (IAM) ユーザー、または AWS サービスです。 次の例は、 AWS ID *123456789012* が検証済み ID *example.com* (*888888888888* が所有する AWS アカウント ) から E メールを送信することを許可するシンプルなポリシーを示しています。このポリシーの `Condition`ステートメントは、代理 (つまり、 AWS ID *123456789012*) がアドレス *marketing\$1.\$1@example.com* から E メールを送信することのみを許可します。*\$1* は、送信者が *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" } } } ] } ``` ------ 次のポリシー例では、IAM ユーザー 2人に、アイデンティティ *example.com* から送信するアクセス許可を付与します。IAM ユーザーは、自分の Amazon リソースネーム (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" ] } ] } ``` ------ 次のポリシー例では、 Amazon Cognito に、アイデンティティ *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" } } } ] } ``` ------ 次の例のポリシーでは、 AWS Organization 内のすべてのアカウントに、identity example.com から送信するアクセス許可が付与されます。 AWS Organization は、[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" } } } ] } ``` ------ ## 「From」アドレスの制限 検証済みドメインを使用する場合、代理送信者だけが特定の E メールアドレスから送信できるようにするポリシーを作成することをお勧めします。"From" アドレスを制限するには、キーで *ses:FromAddress* と呼ばれる条件を設定します。次のポリシーにより、 AWS アカウント ID *123456789012* は ID *example.com* から送信できますが、E メールアドレス *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" } } } ] } ``` ------ ## 代理送信者による E メール送信時間に対する制限 送信者の承認ポリシーを設定することで、代理送信者が E メールを送信できる日付と時間や、日付の範囲を限定することもできます。例えば、2021 年 9 月内で E メールキャンペーンの送信を予定している場合、次のポリシーを使用することで、代理送信者による E メール送信を、その月に限定することができます。 ------ #### [ 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" } } } ] } ``` ------ ## E メール送信アクションの制限 送信者が Amazon SES で E メールを送信するために使用できるアクションは、`SendEmail` と `SendRawEmail` の 2 つです。送信者が E メールの形式をどの程度コントロールするかに応じて決定します。送信承認ポリシーでは、代理送信者をこれらの 2 つのアクションのいずれかに制限できます。ただし、多くのアイデンティティ所有者は、ポリシーで両方のアクションを有効にすることで、E メール送信呼び出しの詳細を代理送信者に任せています。 **注記** 代理送信者が SMTP インターフェイスを介して Amazon SES にアクセスできるようにする場合、少なくとも `SendRawEmail` を選択する必要があります。 アクションを制限する必要がある場合、送信承認ポリシーにどちらかのアクションのみ含めることで制限することができます。次の例は、アクションを `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" ] } ] } ``` ------ ## E メール送信者の表示名の制限 E メールクライアントによっては、実際の「From」アドレスではなく、E メール送信者の「フレンドリ」名 (E メールヘッダーで指定されている場合) が表示されます。たとえば、"John Doe " の表示名は John Doe です。例として、*user@example.com* から E メールを送信しますが、E メールが *user@example.com* ではなく「*Marketing*」から送信されたものとして受信者に表示したいとします。次のポリシーでは、 AWS アカウント ID 123456789012 が ID *example.com* から送信できるようにしますが、「From」アドレスの表示名に *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" } } } ] } ``` ------ ## 複数のステートメントの使用 送信承認ポリシーには複数のステートメントを含めることができます。以下のサンプルポリシーには、2 つのステートメントが含まれています。最初のステートメントでは、「From」アドレスとフィードバックアドレスの両方がドメイン *example.com* を使用している限り、2 つの が *sender@example.com* から送信 AWS アカウント することを許可します。2 番目のステートメントは、受信者の E メールアドレスが *example.com* ドメインに属している場合に限り、IAM ユーザーが *sender@example.com* から E メールを送信することを承認します。 # Amazon SESの送信承認に使用するID情報の代理送信者への提供 送信承認ポリシーを作成してアイデンティティにアタッチしたら、代理送信者にアイデンティティの Amazon リソースネーム (ARN) を提供します。代理送信者は、E メール送信操作または E メールのヘッダーで ARN を Amazon SES に渡します。IDのARNを確認するには、次のステップを実行します。 **アイデンティティの ARN を調べるには** 1. AWS マネジメントコンソール にサインインし、Amazon SES コンソール ([https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)) を開きます。 1. ナビゲーションペインの**設定**で、**検証済み ID** を選択します。 1. ID のリストで、送信承認ポリシーをアタッチしたアイデンティティを選択します。 1. **[Summary]** (概要) ペインの 2 番目の列、**Amazon リソース名 (ARN)** に ID の ARN が含まれます。*arn:aws:ses:us-east-1:123456789012:identity/user@example.com* のような内容です。ARN 全体をコピーし、代理送信者に提供します。 **重要** 認可する ID が[グローバルエンドポイント](global-endpoints.md)機能の一部としてセカンダリリージョンで複製されている場合は、`us-east-1` などのリージョンパラメータを、`arn:aws:ses:*:123456789012:identity/user@example.com` のようにアスタリスク `*` に置き換えます。 # Amazon SESの送信承認を行うための代理送信者のタスク 代理送信者は、自分が所有していないが使用を許可された ID の代わりに E メールを送信します。ID 所有者に代わって送信している場合でも、バウンスと苦情は AWS アカウントのバウンスと苦情のメトリクスにカウントされ、送信するメッセージ数は送信クォータにカウントされます。ID所有者の E メールを送信するために送信クォータの増加が必要になった場合は、それをリクエストする責任も自分にあります。 代理送信者として、次のタスクを完了する必要があります。 + [ID所有者への情報提供](sending-authorization-delegate-sender-tasks-information.md) + [代理送信者通知の使用](sending-authorization-delegate-sender-tasks-notifications.md) + [ID 所有者の E メールの送信](sending-authorization-delegate-sender-tasks-email.md) # Amazon SESの送信承認を行うためのID所有者への情報提供 代理送信者は、ID 所有者に代わって E メールを送信するため、ID 所有者に AWS アカウント ID または IAM ユーザー Amazon リソースネーム (ARN) を提供する必要があります。ID 所有者は、検証済みの ID のいずれかから送信するためのアクセス許可を付与するポリシーを作成するために、ユーザーのアカウント情報を必要とします。 独自の SNS トピックを使用する場合は、バウンス、苦情、または配信に関するフィードバック通知が 1 つ以上の SNS トピックに送信されるように設定することを、ID 所有者にリクエストできます。これを行うには、SNS トピックを ID 所有者が送信を許可した検証済み ID で設定できるように、SNS トピック ARN を ID 所有者と共有する必要があります。 次の手順では、ID 所有者と共有するアカウント情報および SNS トピック ARN を検索する方法について説明します。 **AWS アカウント ID を検索するには** 1. [https://console.aws.amazon.com](https://console.aws.amazon.com/) AWS マネジメントコンソール で にサインインします。 1. コンソールの右上隅で名前/アカウント番号を展開し、ドロップダウンで **[My Account]** (マイアカウント) を選択します。 1. アカウント設定ページが開き、アカウント ID を含むすべての AWS アカウント情報が表示されます。 **IAM ユーザー ARN を検索するには** 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。 1. ナビゲーションペインで [**Users**] を選択します。 1. ユーザーのリストで、ユーザー名を選択します。**[Summary]** (概要) セクションに IAM ユーザー ARN が表示されます。ARN は次の例のようになります。*arn:aws:iam::123456789012:user/John*。 **SNSトピック ARN を検索するには** 1. Amazon SNS コンソールの[https://console.aws.amazon.com/sns/v3/home](https://console.aws.amazon.com/sns/v3/home)を開いてください。 1. ナビゲーションペインで、**[トピック]** を選択してください。 1. トピックのリストでは、SNS トピック ARN が **ARN** 列に表示されます。ARN は次の例のようになります。*arn:aws:sns:us-east-1:444455556666:my-sns-topic*。 # Amazon SESの送信承認を行うための代理送信者通知の使用 代理送信者は、自分が所有していないが使用を許可された ID の代わりに E メールを送信します。ただし、バウンスと苦情は、ID 所有者ではなく*代理送信者*のバウンスと苦情のメトリクスに対してカウントされます。 アカウントのバウンス率や苦情率が高くなりすぎる場合、アカウントが確認対象となり、アカウントのEメール送信機能を一時停止されるおそれがあります。したがって、通知を設定したり、通知を監視するためのプロセスを備えることが重要です。バウンスや苦情が発生しているアドレスをメーリングリストから削除するためのプロセスを備えることも重要です。 したがって、代理送信者は、自分が所有していないが、ID 所有者によって使用が許可されている ID の代わりに送信した E メールに対してバウンスまたは苦情イベントが発生した場合に、通知を送信するように Amazon SES を設定できます。Amazon SNS または Firehose にバウンスや苦情の通知を発行するように[イベント発行](monitor-using-event-publishing.md)をセットアップすることもできます。 **注記** Amazon SNS を使用して通知を送信するように Amazon SES を設定すると、受け取る通知に対して Amazon SNS の標準レートが課金されます。詳細については、「[Amazon SNS 料金](https://aws.amazon.com/sns/pricing)」ページを参照してください。 ## 新しい代理送信者通知を作成 代理送信通知は、[イベントパブリッシング](event-destinations-manage.md)を使用する設定セットか、[独自の SNS トピックで設定された](sending-authorization-identity-owner-tasks-policy.md#configure-sns-topic-you-dont-own)検証済みの ID を使用して設定できます。 次のいずれかの方法を使用して、新しい代理送信通知を設定するための手順を以下に示します。 + 設定セットを使用したイベント発行 + 所有する SNS トピックへのフィードバック通知 **代理送信用の設定セットを使用してイベント発行をセットアップするには** 1. AWS マネジメントコンソール にサインインし、Amazon SES コンソール ([https://console.aws.amazon.com/ses/](https://console.aws.amazon.com/ses/)) を開きます。 1. 「[イベント送信先の作成](event-destinations-manage.md)」の手順に従います。 1. 設定セットでイベント発行をセットアップした後、ID 所有者が送信を許可した検証済み ID を使用して、代理送信者として E メールを送信するときに、設定セットの名前を指定します。「[ID 所有者の E メールの送信](sending-authorization-delegate-sender-tasks-email.md)」を参照してください。 **代理送信用に所有する SNS トピックへのフィードバック通知を設定するには** 1. フィードバック通知に使用する SNS トピックを決定したら、手順に従って、[SNS トピック ARN を検索](sending-authorization-delegate-sender-tasks-information.md#find-sns-topic-arn)し、完全な ARN をコピーして、ID 所有者と共有します。 1. ID 所有者が送信を許可した共有 ID でフィードバック通知用の SNS トピックを設定するように、ID 所有者に依頼します。(ID 所有者は、承認ポリシー手順にある [SNS トピックの設定](sending-authorization-identity-owner-tasks-policy.md#configure-sns-topic-you-dont-own)用に指定された手順に従う必要があります) # Amazon SESの送信承認時のID所有者のE メールの送信 代理送信者とは、他の Amazon SES 送信者と同じ方法で E メールを送信しますが、ID 所有者により使用を承認された ID のAmazon リソース名（ARN）を指定する点のみ異なります。E メールを送信するために Amazon SES を呼び出すと、Amazon SES は送信を承認するポリシーが指定された ID にあるかどうかを確認します。 E メールを送信するときにアイデンティティの ARN を指定する方法はいくつかあります。使用できる方法は、E メールの送信に Amazon SES API オペレーションを使用するか、Amazon SES SMTPインターフェイスを使用するかで異なります。 **重要** E メールを正常に送信するには、ID 所有者が ID を検証した AWS リージョンの Amazon SES エンドポイントに接続する必要があります。 さらに、いずれかの AWS アカウントが検証されていないアドレスに E メールを送信する前に、ID 所有者と代理送信者**の両方**のアカウントをサンドボックスから削除する必要があります。詳細については、「[本稼働アクセスのリクエスト (Amazon SES サンドボックスからの移行)](request-production-access.md)」を参照してください。 使用が許可されている ID が[グローバルエンドポイント](global-endpoints.md)機能の一部としてセカンダリリージョンで複製されている場合: ID 所有者が、`us-east-1` などのリージョンパラメータを持つ ID ARN を、`arn:aws:ses:*:123456789012:identity/user@example.com` のようにアスタリスク `*` に置き換えて提供しているはずです。 ID 所有者が、プライマリリージョンとセカンダリリージョンの両方で送信認可ポリシーを作成しているはずです。 ## Amazon SES API の使用 Amazon SES E メール送信者と同様に、Amazon SES API を介して Amazon SES にアクセスする場合 (HTTPS から直接、または AWS SDK を介して間接的にアクセスする場合)`SendEmail`、、`SendTemplatedEmail`、 の 3 つの E メール送信アクションのいずれかを選択できます`SendRawEmail`。これらの API の詳細は「[Amazon Simple Email Service API Reference](https://docs.aws.amazon.com/ses/latest/APIReference/)」で説明されていますが、ここでは送信承認パラメータの概要を示します。 ### SendRawEmail `SendRawEmail` を使用して E メールの形式をコントロールできるようにする場合、次の 2 つの方法のいずれかを使用して委任された承認済み ID を指定できます。 + **オプションパラメータを `SendRawEmail` API に渡します**。必須のパラメーターを次の表で説明します。 **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ses/latest/dg/sending-authorization-delegate-sender-tasks-email.html) + **E メールに X ヘッダーを含める**。X ヘッダーは、標準的な E メールヘッダーに加えて使用できるカスタムヘッダーです (「From」、「Reply-To」、または「Subject」ヘッダーなど)。Amazon SES が認識する以下の 3 つの X ヘッダーを使用して、送信承認パラメータを指定することができます。 **重要** これらの X ヘッダーは、E メールの送信前に Amazon SES により削除されるため、DKIM 署名には含めないでください。 **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ses/latest/dg/sending-authorization-delegate-sender-tasks-email.html) Amazon SES は送信前に E メールからすべての X ヘッダーを削除します。X ヘッダーのインスタンスを複数含めた場合、Amazon SES は最初のインスタンスのみを使用します。 次の例は、送信認可 X ヘッダーを含む E メールを示しています。 ``` 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 と SendTemplatedEmail `SendEmail` または `SendTemplatedEmail` オペレーションを使用する場合、次のオプションパラメータを渡すことで委任された承認済み ID を指定できます。`SendEmail` または `SendTemplatedEmail` オペレーションを使用する場合、X ヘッダーは使用できません。 **** | パラメータ | 説明 | | --- | --- | | `SourceArn` | `SendEmail` または `SendTemplatedEmail` の `Source` パラメータで指定された E メールアドレスから送信することを許可する送信承認ポリシーに関連付けられたアイデンティティの ARN。 | | `ReturnPathArn` | `SendEmail` または `SendTemplatedEmail` の `ReturnPath` パラメータで指定された E メールアドレスを使用することを許可する送信承認ポリシーに関連付けられたアイデンティティの ARN。 | 次の例は、`SendEmail` または `SendTemplatedEmail` オペレーションおよび [SDK for Python](https://aws.amazon.com/sdk-for-python) を使用して、`SourceArn` および `ReturnPathArn` の各属性を含む E メールを送信する方法を示しています。 ``` 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']) ``` ## Amazon SES SMTP インターフェイスの使用 代理送信用の Amazon SES SMTP インターフェイスを使用する場合は、`X-SES-SOURCE-ARN`、`X-SES-FROM-ARN`、および `X-SES-RETURN-PATH-ARN` の各ヘッダーをメッセージに含める必要があります。これらのヘッダーは、SMTP 通信で `DATA` コマンドを発行した後に渡します。