Amazon WorkMail で独自ドメインの E メール環境を 5 分で構築する
- 公開日
- カテゴリ:AWS
- タグ:AWS,WorkMail,SES

先日、急遽独自ドメインのメール環境が必要になったのですが、 Amazon WorkMail を利用して E メールのプラットフォームを構築したところとても体験が良かったので記録に残します。
Contents
Amazon WorkMail
Amazon WorkMail は、 E メールのプラットフォームを構築できるマネージド型サービスです。
https://aws.amazon.com/jp/workmail/
- 1 ユーザーあたり 1 か月につき 4 USD
- 1 ユーザーあたり 50 GB のストレージ
- メールボックスを iOS、Android、Amazon Fire、および Windows Phone デバイスと同期可能
E メール、カレンダー、および連絡先にアクセスするためのウェブクライアントも用意されています。
サポートされているプロトコルには、EWS、ActiveSync、IMAP、SMTP など。
つまり WorkMail を利用すれば、Gmail や outlook, Thunderbird のようなメールクライアントを使った E メールの送受信を可能にするプラットフォームを構築できます。
Amazon SES と WorkMail の違い
AWS の E メール関連サービスに Amazon Simple Email Service (Amazon SES) があります。
Amazon SES とは?
https://docs.aws.amazon.com/ja_jp/ses/latest/dg/Welcome.html
SES は基本的には配信のための仕組みです。
受信もできますが E メールを受信するための POP サーバーや IMAP サーバは含まれていないため、outlook などメールクライアントからは利用できません。
E メールクライアントを使用して送信と受信の両方が可能なソリューションが必要な場合は、Amazon WorkMail の使用が推奨されています。
Amazon SES の E メール受信の概念とユースケース
https://docs.aws.amazon.com/ja_jp/ses/latest/dg/receiving-email-concepts.html
利用の制限事項
2023 年 6 月時点で利用できるリージョンは以下の 3 つ
- 米国東部(バージニア北部)
- 米国西部(オレゴン)
- 欧州(アイルランド)
つまり国内でのメールデータ保管が必須であれば東京や大阪のリージョンが対応するのを待つ必要はあります。
導入
では利用までのセッティングを行っていきます。
Organization 作成
create organization ボタンを押下します。
organization 作成画面に遷移するので必要な項目を入力していきます。
Email domain
メールアドレスに使用するドメインを選択します。
- Existing Route 53 domain(既存の Route 53 ドメイン)
- Route 53 ホストゾーンで管理するドメイン名を選択します。
- New Route 53 domain(新しい Route 53 ドメイン)
- Amazon WorkMail で使用する新しい Route 53 ドメイン名を登録します。
- External domain(外部ドメイン)
- 外部 DNS プロバイダーで管理するドメイン名を入力します。
- Free test domain(無料のテストドメイン)
- Amazon WorkMail が提供する無料のテスト ドメインを使用します。ドメインは後で追加できます。
Route 53 に登録済みのドメインを使うと素早く環境を構築できます。今回は Route 53 に登録済みのドメインを使用しています。
Route 53 hosted zone(Route 53 ホストゾーン)
organization で使用する Route 53 ホストゾーンを選択します。
Alias(エイリアス)
エイリアスを選択します。
ウェブクライアントを利用する際は、ここで入力したエイリアス名が URL(サブドメイン)に反映されます。(https://<alias_name>.awsapps.com/mail)。
エイリアスは最大 45 文字です。小文字 (a ~ z)、数字 (0 ~ 9)、およびダッシュ (-) のみを含めることができます。
Advanced settings(高度な設定)
今回はデフォルトのままですが、より高度な設定を行えます。
User directory(ユーザーディレクトリ)
ユーザーを管理するディレクトリを選択します。
- Create Amazon WorkMail directory(Amazon WorkMail ディレクトリを作成する)
- ディレクトリを作成し、そこにユーザーを追加します。 このディレクトリは WorkMail 専用であり、他の AWS サービスやアプリケーションでは使用できません。
- Use existing directory(既存のディレクトリを使用する)
- Active Directory などの既存のディレクトリを使用してユーザーを管理します。
Encryption(暗号化)
データを保護するために暗号化キーを選択します。 暗号化キーはアカウントの AWS Key Management Service (AWS KMS) にあります。
- Use Amazon WorkMail managed key(Amazon WorkMail 管理キーを使用する)
- アカウントで作成した暗号化キーを使用します。
- Use existing customer managed key (CMK)(既存のカスタマー マネージド キー (CMK) を使用する)
- AWS KMS で作成した既存の CMK を使用します。
入力が終わったら「Create organization」ボタンを押下します。
organization の作成が始まり、数秒で作成が完了しました。
ドメイン設定(DNS レコード追加)
作成した organization に E メールで使うドメインの DNS レコード設定していきます。
ただし Route53 に登録済みのドメインを指定した場合、ほとんどの設定は設定済みの状態になっていました。
メールアドレスとしてこのドメインを使うのは初めてなので、SPF と DMARC, そして MAIL FROM domain の設定のみここで行います。
SPF, DMARC の設定
SPF(Sender Policy Framework) と DMARC(Domain-based Message Authentication, Reporting, and Conformance) は、メール認証のためのプロトコルです。
SPF(Sender Policy Framework)
SPFは、ドメインの送信元認証を提供するための技術です。メールサーバーは送信ドメインの SPF レコードを確認し、メール送信元の IP アドレスが正当な送信元であるかを検証します。
SPF の設定にはドメインの DNS レコードに特定の設定を追加する必要があるため、ここでも TXT レコードの登録が必要です。
- SPF を設定するメリット:
- メールの送信元を偽装するスプーフィング攻撃を防ぐことができます。
- SPFをサポートする受信サーバーは、SPF に合致しないメールをスパムとしてマークすることができます。
- SPFを設定しないデメリット:
- SPF を設定しない場合、メール送信者のドメインの信頼性が低下し、受信者のメールフィルターによってスパムとしてマークされる可能性が高まります。
DMARC(Domain-based Message Authentication, Reporting, and Conformance)
DMARC は、ドメイン認証に基づいたメール送信者認証および報告のためのプロトコルです。DMARC では、SPF および DKIM の結果を組み合わせてドメインの認証を行い、不正なメール送信を防止します。
- DMARCを設定するメリット:
- ドメインの認証により、送信元ドメインの信頼性を高めることができます。
- メール送信者ドメインのスプーフィング攻撃を防ぎ、受信者に信頼性のあるメール送信を提供します。
- DMARCレポートを受信することで、ドメインの送信状況や潜在的な不正利用の警告を受けることができます。
- DMARCを設定しないデメリット:
- メール送信者のドメインの信頼性が低下し、受信者のメールフィルターによってスパムとしてマークされる可能性が高まります。
つまるところ SPF も DMARC もメール送信の信頼性が低下しないように要設定項目。ということで設定していきます。
SPF と DMARC に関しては簡単で、画面右上の「Update all in Route 53」ボタンを押下するだけで設定が完了します。
ボタン 1 つで TXT レコードの登録が完了し、SPF と DMARC に関しても Verified になりました。
カスタム MAIL FROM ドメインの設定
続いてカスタム MAIL FROM ドメインの設定を行っていきます。
Custom MAIL FROM domain は、Amazon SES を使用して送信されるメールの送信者アドレスを自分のドメインに基づいたアドレスにカスタマイズする機能です。これにより、メールの信頼性と認識性を向上させることができます。
この設定は Amazon SES の画面から行います。
編集ボタンを押して表示される画面から、 MAIL FROM ドメインを入力し、「変更の保存」ボタンを押下します。
保存したら、このドメインを MAIL FROM として設定するために発行された MX レコードと SPF レコードをドメインの DNS プロバイダーに発行する必要があるのですが、これも「DNS レコードの Route53 への発行」ボタンを押下するだけで完了します。
これで晴れて、全てのドメイン関連の設定が完了しました。ここまでで 3 分程度です。
ユーザーの作成
E メール環境を構築できたので、ユーザーを作成して利用してみます。
メールアカウント名など、必要な情報を入力して作成ボタンを押下します。
これでユーザーも作成完了です。
test_user として E メールを使い始められます。
ここまででおよそ 5 分。あっという間です。
web クライアントからメールの送受信を行ってみる
E メールの環境構築が終わったので、ウェブクライアントから作成したユーザーで E メールの送受信を行ってみます。
ウェブクライアントの URL は、https://<alias_name>.awsapps.com/mail です。
ログインしました。シンプルな画面で使いやすそうです。(ただし執筆時点では日本語の UI には未対応でした)
メールを送信してみます。
無事にメールが送信され、送信先で受信できました。
返信してみましたが受信も問題なくできました。
まとめ
Amazon WorkMail は「セキュリティに優れた企業向け E メールおよびカレンダーのマネージド型サービス」であるわけですが、個人としてもとても有用なサービスだと感じました。
急に独自ドメインのメール環境が必要になった時にこうして一瞬で作成できるのはとても助かりますし、 Route 53 に登録済みのドメインから数分で環境を構築できるのはとても便利でした。
と、今回は構築スピードだけにフォーカスしたので最後に Amazon WorkMail の優れている点を紹介して終わりにします。
- セキュリティ
- データの暗号化・ファイアウォールの保護・不正アクセスからの防御など、厳格なセキュリティ対策を実施している。組織の機密情報や個人データを保護するための強力なセキュリティ機能を提供する。
- 信頼性
- Amazon のクラウドインフラを活用するため高可用性とスケーラビリティが実現されている。メールの受信と送信が確実に行われ、業務における重要なコミュニケーションの信頼性を確保できる。
- 他サービスとの連携
- Google Workspace でいうところの email(Gmail), storage(drive), web meeting(meets) は、AWS では WorkMail, WorkDocs, Chime で代替が可能。
特に WorkMail, WorkDocs, Chime の連携はどんな体験になるのか気になります。次の機会に試してみることにします。