Amazon SES（ドメインID）を試してみた

# 背景・目的
以前、SESを整理しましたが今回は、実際に試してみます。

https://qiita.com/zumax/items/0a538c11e15537b5afaf

# まとめ
下記に特徴をまとめます。

|特徴|説明|
|:--|:--|
|IDタイプ|メールアドレスと、ドメインレベルの２つがある|
|ドメインレベルのID|・検証はサブドメイン・ドメインレベル<BR>・単純なEメール送信に限定<BR>・検証時にドメイン名は大文字・小文字は区別されない|
|メールアドレスのID|・明示的に個別に検証<BR>・高度な送信が可能<BR>・検証時にメールアドレスは大文字・小文字は区別される|
|ドメインレベルとメールアドレスを両方検証|・サブドメインは親ドメインからの検証を継承<BR>Eメールアドレスは明示的に検証される<BR>・高度な送信に使用|
|複数のAWSリージョンで同一ドメイン、<BR>メールアドレスからメールを送信する場合|・リージョンごとに個別のIDを作成し検証する必要がある<BR>・リージョンごとに最大10,000個のIDを検証できる|
|検証のドメイン|検証した最も細かいレベルで適用される<BR>・検証済みメールアドレスIDは、検証済みドメインIDをオーバライド<BR>・検証済みサブドメインはIDは、検証済みドメインIDをオーバーライド
|ラベルの使用|追加の検証手順を実行せずに、検証済みEメールアドレスにラベルを追加できる<BR>ラベルは、アカウント名と@の間に「＋」をつけてテキストラベルをつける|
|ドメインIDの検証|・ドメインIDの作成では、DKIMベースの検証が含まれる<BR>・Amazonがドメインの所有権を検証するために使用するEメール認証方法<BR>・受信メールサーバは、Eメールの信頼性を検証するために使用する<BR>・Easy DKIM、BYOD KIMのどちらかを選択する|
|送信ドメイン認証技術|送信元IPと電子署名を利用するものに分かれる。<BR>DKIMは電子署名を利用する|
|電子署名の検証|電子署名の検証に必要となる公開鍵は送信元ドメインのDNSサーバで公開される。<BR>受信者は受け取ったメール内の署名者に関する情報からドメインを特定し、DNSサーバへ問い合わせることで公開鍵を取得する|
|DKIM|・DomainKeys Identified Mail<BR>・電子メールにおける送信ドメイン認証技術の一つ<BR>・メールを送信する際に送信元が電子署名を行い、受信者がそれを検証する<BR>・送信者のなりすまし、メールの改ざんを検知できる|
|SESの設定セット|設定セットは、検証済みのIDに適用できるルールのグループ<BR>メールに構成セットを適用するとすべてのルールが適用される|
|IP プールの割り当て|IPプールには、共有と2つの専用がある<BR>専用では、標準とマネージドがある|
|共有IPプール|SESユーザで共有|
|専用（標準）IPプール|手動で管理|
|専用（マネージド）IPプール|IPの追加・削除やウォームアップなどAWSに任せられる|

# 概要
機能や特徴については、下記をご覧いただけますと幸いです。

https://qiita.com/zumax/items/0a538c11e15537b5afaf

ここでは、その他の内容を記載します。

## SESのIDタイプ
下記を基に整理します。

https://docs.aws.amazon.com/ja_jp/ses/latest/dg/creating-identities.html

> Amazon ではSES、ドメインレベルで ID を作成することも、E メールアドレス ID を作成することもできます。これらの ID タイプは相互に排他的ではありません。ほとんどの場合、ドメイン ID を作成することで、特定の E メールアドレスにカスタム構成を適用しない限り、個々の E メールアドレス ID の作成と検証を行う必要がなくなります。ドメインを作成してそのドメインに基づいて E メールアドレスを利用する場合も、個別の E メールアドレスを作成する場合もメリットがあります。選択する方法は、以下で説明するように、特定のニーズによって異なります。

- ドメインレベルとEメールアドレスの2つがある
- 殆どの場合、ドメインIDを作成することで、特定のEメールアドレスにカスタム構成を適用しない限り、個々のEメールアドレスIDの作成と検証を行う必要がない


> E メールアドレス ID の作成と検証は、 で開始する最も速い方法ですがSES、ドメインレベルで ID を検証する利点があります。E メールアドレス ID を検証する場合は、その E メールアドレスのみでしかメールを送信できませんが、ドメイン ID を検証する場合、個別に検証することなく、検証済みドメインの任意のサブドメインまたは E メールアドレスから E メールを送信できます。例えば、example.com というドメイン ID を作成して検証する場合、a.example.com、a.b.example.com などの個別のサブドメイン ID や、user@example.com、user@a.example.com などの個別の E メールアドレス ID を作成する必要はありません。

- メールアドレスベースを検証するのが早く始められる。しかしメールアドレスのみを使用してメール送信が出来る
- ドメインレベルでIDを検証すると、検証済みドメイン・サブドメインから、個別に検証することはない

> ただし、ドメインから継承された検証を使用している E メールアドレス ID は、単純な E メール送信に限定されることに注意してください。より高度な送信を行う場合は、E メールアドレス ID として明示的に検証する必要もあります。高度な送信には、設定セットでの E メールアドレスの使用、委任送信のポリシー承認、およびドメイン設定を上書きする設定が含まれます。

- ドメインレベルのEメールアドレスは、単純なEメール送信に限定される
- 高度な送信にはメールアドレスとして明示的な検証が必要


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/c846e196-c596-47a0-bbe0-4361d2475b28.png)

出典：https://docs.aws.amazon.com/ja_jp/ses/latest/dg/creating-identities.html

> 複数の で同じドメインまたは E メールアドレスから E メールを送信するには AWS リージョン、リージョンごとに個別の ID を作成して検証する必要があります。各地域で 10,000 個までの ID を検証することができます。

- 複数のAWSリージョンで同一ドメイン、メールアドレスからメールを送信する場合
    - リージョンごとに個別のIDを作成し検証する必要がある
    - リージョンごとに最大10,000個のIDを検証できる

### 検証時の注意点
> - 個別に検証することなく、検証済みドメインの任意のサブドメインまたは E メールアドレスから E メールを送信できます。たとえば、example.com の ID を作成して検証する場合、a.example.com、a.b.example.com、user@example.com、user@a.example.com などの個別の ID を作成する必要はありません。

> - RFC 1034 で指定されているように、各DNSラベルには最大 63 文字を含めることができ、ドメイン名全体が合計 255 文字を超えることはできません。

> - ルートドメインを共有するドメイン、サブドメイン、および E メールアドレスを検証する場合、ID 設定 (フィードバック通知など) は検証した最も細かいレベルで適用されます。
>    - 検証済み E メールアドレスID設定は、検証済みドメインのID設定をオーバーライドします。
>    - 検証済みサブドメインID設定は、検証済みドメインのID設定をオーバーライドします。より低いレベルのサブドメイン設定は、より高いレベルのサブドメイン設定をオーバーライドします。
>    たとえば、user@a.b.example.com、a.b.example.com、b.example.com、および example.com を検証するとします。これらは、以下のシナリオで使用される検証済みのアイデンティティ設定です。
>       - user@example.com (特別には検証されないEメールアドレス) から送信される E メールは、example.com の設定を使用します。
>       - user@a.b.example.com (特別に検証されるEメールアドレス) から送信される E メールは、user@a.b.example.com の設定を使用します。
>       - user@b.example.com (特別には検証されないEメールアドレス) から送信される E メールは、b.example.com の設定を使用します。

> - 追加の検証手順を実行せずに、検証済みの E メールアドレスにラベルを追加することができます。E メールアドレスにラベルを追加するには、アカウント名と「at」記号 (@) の間にプラス記号 (+) を付け、続いてテキストラベルを付けます。例えば、sender@example.com をすでに検証している場合は、sender+myLabel@example.comを E メールの「From」または「Return-Path」アドレスとして使用できます。この機能を使用して、可変エンベロープリターンパス () を実装できますVERP。その後、 VERPを使用して、メーリングリストから配信不能の E メールアドレスを検出して削除できます。
> - ドメイン名では大文字と小文字は区別されません。example.com を検証する場合は、EXAMPLE.comから送信することもできます。
> - E メールアドレスでは、大文字と小文字が区別されます。sender@EXAMPLE.comを検証する場合、sender@example.com も検証しない限り、sender@example.com から E メールを送信することはできません。
> - 各 で AWS リージョン、最大 10,000 個の ID (任意の組み合わせでドメインと E メールアドレス) を検証できます。

- 検証した最も細かいレベルで適用される
    - 検証済みメールアドレスIDは、検証済みドメインIDをオーバライド
    - 検証済みサブドメインはIDは、検証済みドメインIDをオーバーライド
- 追加の検証手順を実行せずに、検証済みEメールアドレスにラベルを追加できる
    - ラベルは、アカウント名と@の間に「＋」をつけてテキストラベルをつける
- ドメイン名は大文字・小文字は区別されない
- メールアドレスは大文字・小文字は区別される
- リージョンごとに最大10,000個のIDを検証できる


## ドメインIDの作成

> ドメイン ID の作成には、 DKIMベースの検証の設定が含まれます。 DomainKeys識別メール (DKIM) は、Amazon がドメインの所有権を検証SESするために使用する E メール認証方法であり、受信メールサーバーは E メールの信頼性を検証するために使用します。Easy DKIMまたは Bring-Your-Own DKIM (BYODKIM) のいずれかDKIMを使用して を設定することを選択できます。また、選択に応じて、プライベートキーの署名キーの長さを次のように設定する必要があります。

> - Easy DKIM - Amazon のSESデフォルトである 2048 ビットを受け入れるか、1024 ビットを選択して上書きします。
> - BYODKIM - プライベートキーの長さは、1024 ビット以上 2048 ビット以下である必要があります。

- DomainKeys Identified Mailの略
- ドメインIDの作成では、DKIMベースの検証が含まれる
- Amazonがドメインの所有権を検証するために使用するEメール認証方法
- 受信メールサーバは、Eメールの信頼性を検証するために使用する
- 下記から選択しDKIMを検証する
    - Easy DKIM
        - 2048ビットまたは1024ビットを選択する
    - BYOD KIM
        - 1024ビット以上、2048ビット以下とする

### DKIM
下記を基に整理します。

https://www.nic.ad.jp/ja/basics/terms/dkim.html

> DKIM (DomainKeys Identified Mail)は、 電子メールにおける送信ドメイン認証技術の一つであり、 メールを送信する際に送信元が電子署名を行い、 受信者がそれを検証することで、 送信者のなりすましやメールの改ざんを検知できるようにするものです。

- DKIM
    - DomainKeys Identified Mail
    - 電子メールにおける送信ドメイン認証技術の一つ
    - メールを送信する際に送信元が電子署名を行い、受信者がそれを検証する
    - 送信者のなりすまし、メールの改ざんを検知できる

> 送信ドメイン認証技術は、送信元のIPアドレスを利用するものと、 電子署名を利用するものとに大きくわかれますが、DKIMは電子署名を利用し、 その電子署名の検証に必要となる公開鍵は送信元ドメインのDNSサーバで公開されます。 受信者は受け取ったメール中の署名者に関する情報からドメインを特定し、 そのDNSサーバへ問い合わせることで公開鍵を取得します。

- 送信ドメイン認証技術
    - 送信元IPと電子署名を利用するものに分かれる
    - DKIMは電子署名を利用する
    - 電子署名の検証に必要となる公開鍵は送信元ドメインのDNSサーバで公開される
    - 受信者は受け取ったメール内の署名者に関する情報からドメインを特定し、DNSサーバへ問い合わせることで公開鍵を取得する

> 電子署名の作成は、送信者自身が必ずしも行う必要は無く、 他にメール送信者の利用するメール中継サーバ(MTA)、送信メールサーバ(MSA)、 あるいは信頼した第三者が行うことが可能です。 このような特徴を利用して、 例えば電子署名の作成をメールサーバで行うように設定を行い、 エンドユーザーのメールに対して透過的にDKIMを用いた署名を付加することなどができます。

- 電子署名の作成
    - 送信者自身が必ずしも行う必要はない。他に下記が行える
        - メール送信者の利用するメール中継サーバ（MTA）
        - 送信メールサーバ（MSA）
        - 信頼した第三者

> 最近では、同じ送信ドメイン認証技術でも送信元のIPアドレスを利用するSPF (Sender Policy Framework)と、 DKIMとを組み合わせたDMARC (Domain-based Message Authentication, Reporting and Conformance)と呼ばれるメール認証技術の導入に伴い、 DKIMの普及が進んでいます。

- DKIMは、最近では送信元のIPアドレスを使用するSPFとDKIMを組み合わせたDMRARCと呼ばれるメール認証技術が導入されている

## SESの設定セット
> 設定セットは、検証済みの ID に適用できるルールのグループです。検証済みのID とは、Amazon SES 経由で E メールを送信するために使用するドメイン、サブドメインまたはE メールアドレスです。E メールに構成セットを適用すると、その構成セットに含まれるすべてのルールが E メールに適用されます。

- 設定セットは、検証済みのIDに適用できるルールのグループ
- メールに構成セットを適用するとすべてのルールが適用される

> 設定セットを使用すると、送信する E メールに次のタイプのルールを適用できます。これらのいずれかまたは両方を含めることも、いずれも含めないこともできます。

> - イベント送信先 – 送信する E メールごとに、送信数、配信数、開封数、クリック数、バウンス数、苦情数などの E メール送信メトリクスを他の AWS 製品に発行できます。例えば、E メールのメトリクスを Amazon Data Firehose の送信先に送ってから、Amazon Managed Service for Apache Flink を使用して分析できます。または、Amazon SNS にバウンスや苦情の情報を送信し、これらのイベントが発生したときに即座に通知を受け取ることができます。

> - IP プールの管理 - 専用の IP アドレスをリースして Amazon SES で使用する場合、専用 IP プールと呼ばれるアドレスのグループを作成して、特定のタイプの E メールを送信するときに使用できます。例えば、専用 IP プールを設定セットに関連付けて、マーケティングコミュニケーションの送信や、取引の E メールの送信に使用できます。取引 E メールの送信者の評価はマーケティング E メールの送信者の評価とは切り離されています。


- 下記のタイプのルールのいずれか、または両方を適用できる
    - イベント送信先
        - 送信するメールごとに下記のメトリクスをAWSサービスに発行できる
            - 送信先
            - 配信数
            - 開封数
            - クリック数
            - バウンス数
            - 苦情数
        - AWSサービスで分析などが可能
    - IPプールの管理
        - 専用のIPプールと呼ばれるアドレスのグループを作成し、特定のタイプのメールを送信するときに使用できる
            - 専用IPプールを設定セットを関連付けてマーケティングコミュニケーションの送信
            - 取引のメール送信に使用できる


> 次の方法で、検証済み ID に設定セットを関連付けます。

> - E メールのヘッダーに、設定セットへの参照を含めます。E メールの設定セットの指定の詳細については、メールの送信時に設定セットを指定する を参照してください。

> - ID の作成中、または検証済み ID の編集中に使用される、デフォルトの設定セットを指定します。デフォルトの設定セットを理解する を参照してください。

<!--
### 追跡オプション
下記を基に特徴をまとめます。

https://docs.aws.amazon.com/ja_jp/ses/latest/dg/configure-custom-open-click-domains.html

-->



## Amazon SES での IP プールの割り当て
下記を基に特徴をまとめます。

https://docs.aws.amazon.com/ja_jp/ses/latest/dg/managing-ip-pools.html



- 特定の用途や目的に応じて、メール送信用のIPアドレスをグループ化したものを指す
- 異なる種類のメールを送信する際に、使用するIPアドレスを分けることが可能。各メールの送信者評価を個別に管理できる
- SESでは下記のIPプールが提供されている
    - 専用IPプール
        - 標準
            - ユーザが手動で管理する専用IPアドレスのグループ
            - 各IPアドレスのウォームアップ、スケーリングを手動で行う
        - マネージド
            - SESが自動的に設定・管理する専用IPアドレスのグループ
            - 送信パターンに基づいて最適な数のIPアドレスが自動的に割り当てられる
            - ウォームアップ、スケーリングも自動で行われる
    - 共有IPプール
        - SESユーザ間で共有されるIPアドレスのグループ
        - 特定のIPプールを使用しない限り、デフォルトで使用される
- IPプールの活用方法
    - 送信者評価の分離
        - マーケティングメール取引メールで異なるIPプールを使用することで、一方のメール種別で問題が発生しても他方の評価に影響を与えない
    - 送信パターンの管理
        - 特定のIPプールを特定の用途に割り当てることで、各用途に応じた送信パターンを維持できる
    - 柔軟なスケーリング
        - マネージドIPを使用し、送信量の増減に応じてIPの数が自動的に調整される
        - 効率的なリソース管理が可能


専用IPプールについて、クラスメソッド様の記事がわかりやすかったので参考にさせていただきました。感謝です。

https://dev.classmethod.jp/articles/release-ses-managed-ip-pool/

| IPプールの種類|専用IP（標準）|専用IP（マネージド）|
|:--|:--|:--|
|レピュテーションの分類|共有IPでは実現できない<BR>メールレピュテーションの分離が可能<BR><BR>他のSES利用者と分離ができる点や、自分たちでもIPプールを使い分けることが可能|左記と同様|
|IPアドレスの固定化|異なるIPアドレスを固定化出来る<BR>メールプロバイダーのホワイトリストなどに送信元IPアドレスを登録する必要がある場合、専用IP（標準）を利用することになる|固定化できない<BR>専用のIP管理をSESに任せる|
|料金|専用IP自体に発生<BR>標準の場合、メール送信に利用してなくても発生|アカウントごとの費用<BR>メール送信件数に応じて従量課金|
|柔軟性（IPアドレスの追加・削除）|AWSサポートを介して専用のIPを払い出す|追加・削除の際にAWSサポートへのリクエストは不要<BR>メール送信パターンに基づいて自動で追加と削除を起こってくれる<BR><BR>特定プロバイダーへの送信クォーターが低いとSESが検出された場合、自動でIPプールをスケールアウトして多くのIPプロバイダーを割り当てる|
|ウォームアップ|専用IPは、IP毎にウォームアップが必要<BR>IPを取得しても実績がないのですぐに大量メールを送信できない。<BR>デフォルトでは自動ウォームアップ機能によりSESが数日かけて各メールプロバイダー対して少しづつメール送信を送ってくれる|インテリジェントウォームアップと呼ばれる機能により、メールプロバイダー毎に自動で送信を行ってくれる<BR><BR>ウォームアップが十分になるまで対象プロバイダーに対して他のSESユーザとの共有IPを使って送信する機能がある|

# 実践
下記を基に試します。

https://docs.aws.amazon.com/ja_jp/ses/latest/dg/creating-identities.html

## 前提：Amazon SES の設定セット
下記を基に試します。

https://docs.aws.amazon.com/ja_jp/ses/latest/dg/using-configuration-sets.html

1. マネコンにサインインし、SESに移動します
1. ナビゲーションペインで「設定セット」をクリックします
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/cf01cfa5-ce4a-4d78-a614-e6a84f808c19.png" width=150 />

1. 「セットの作成」をクリックします
1. 下記を入力し、「セットの作成」をクリックします
    - 設定セット名：任意
    - IPプール：ses-shared-pool
    - TLS：チェック
    - 評判オプション：有効化
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/214f5a50-1554-4e4e-a4d5-9de308ae9f41.png)
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/cbe58856-91d4-4e12-8054-0d0fac7a6648.png)

1. できました
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/65480d31-3a19-4a01-a86e-963b2dc9db48.png)


## ドメイン ID
### ドメインIDの登録
下記を基に試します。

https://docs.aws.amazon.com/ja_jp/ses/latest/dg/creating-identities.html#verify-domain-procedure

1. マネコンにサインインし、SESに移動します
1. ナビゲーションペインで「ID」をクリックします
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/f0407f30-18f6-4a31-ad18-d89f9740e96e.png" width=150 />

1. 「IDの作成」をクリックします
1. 下記を選択し、「IDの作成」をクリックします
    - IDタイプ：ドメイン
    - ドメイン：登録済みのドメイン（今回は、Route 53に登録済みのドメインを使用しています）
    - デフォルト設定セット：上記の「前提：Amazon SES の設定セット」で作成したものを使用
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/53e47adb-3c01-485d-8bc9-82834e90b65e.png)
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/6f0eee8c-52be-4bca-a581-3e1b2024b500.png)

1. 作成されましたが、検証中（設定中）というステータスでした。またCNAMEも登録されていました。
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/f68e9269-a694-4c75-b533-3da1002c0eb7.png)

1. しばらくすると検証済みに変わりました
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/0cec038d-2685-48c0-ae2f-e4f1ea7a7751.png)

1. またメールでも「DKIM setup SUCCESS for XXXXX in Asia Pacific (Tokyo) region」のメールでDKIM のセットアップが完了した旨の連絡が来ます



### DNS プロバイダーとのDKIMドメイン ID の検証
:::note info
どうやら、Route 53の場合は、不要なようです。通常はCNAMEを管理しているホストゾーンのDNSレコードに登録するようです。
:::

### Route 53の確認
1. Route 53に移動します
1. 対象のホストゾーンのDNSレコードを確認すると、CNAMEが登録されていました
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/6b00b7fd-6ec2-4131-9fb7-730dd275724b.png)


### テストメール送信
#### 設定セットの編集
1. ナビゲーションペインで「設定セット」をクリックします
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/cf01cfa5-ce4a-4d78-a614-e6a84f808c19.png" width=150 />
1. 「イベント送信先」タブをクリックします
1. イベント送信先の追加をクリックします
1. イベントタイプを選択します
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/c65b3f7f-7a2c-4695-96b1-194df1864922.png)

1. ①送信先オプションに「SNS」を選択し、②「SNSトピックの作成」をクリックします
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/cee9248d-d3d4-497f-92de-5dc4d99ee1c2.png)
1. トピック作成のポップアップが表示されるので任意の名称を入力します
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/9aae2faf-5553-4396-bdc7-6dee88320a5a.png)

1. 次へをクリックします
1. 送信先を追加をクリックします




#### メール送信
1. ナビゲーションペインで「ID」をクリックします
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/f0407f30-18f6-4a31-ad18-d89f9740e96e.png" width=150 />
1. 検証済みのIDをクリックします
1. 「テストEメールの送信」をクリックします
1. 下記を入力し、「テストEメールの送信」をクリックします
    - Eメール形式：フォーマット済み
    - From-address：アカウントを指定
    - シナリオ：配信の成功
    - 件名：任意
    - 本文：任意
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/66364988-ebc6-4c43-8f1b-caa67df87dbe.png)

1. 「Amazon SES Email Event Notification (Amazon SES メールイベント通知)」という件名でメールが届きました


<!--
## メールアドレスID
https://docs.aws.amazon.com/ja_jp/ses/latest/dg/creating-identities.html#verify-email-addresses-procedure
-->

# 考察
今まで、SESを利用したことはありませんが、設定項目や機能が豊富にあり、すべてを理解するのに時間を要しそうです。引き続きまなんでいきたいとおもい

# 参考
https://qiita.com/zumax/items/0a538c11e15537b5afaf

https://docs.aws.amazon.com/ja_jp/ses/latest/dg/creating-identities.html

https://docs.aws.amazon.com/ja_jp/ses/latest/dg/setting-up.html

https://www.nic.ad.jp/ja/basics/terms/dkim.html

https://dev.classmethod.jp/articles/release-ses-managed-ip-pool/