ブログ

はじめに

Amazon Cognito ( 以下 Cognito ) は、AWSでユーザー認証が必要なシステムを構築するには欠かせないサービスです。自前で認証機能を実装することも可能ではありますが、Cognitoには認証に関わる様々な機能が存在するため、使用するメリットのほうが多いと考えています。

そんなCognitoを長年運用している中で、ある日突然問い合わせを受けたのが「認証メールが届かない」というものでした。それまでトラブルもなく安定的に稼働していたため、すぐには原因は思い当たりませんでした。

当初はCognitoの障害やAmazon Simple Email Service ( 以下 SES ) で何か異常があったのかと調査をしていました。結果としては、届いていたものの、迷惑メールに振り分けられていて気が付かなかったという状態でした。

そんな実体験を元に、本記事では、実際のプロジェクトで遭遇したCognitoのメール送信に関する課題と、その解決方法について解説します。特に、送信元メールアドレスの設定における推奨事項を、現場で得た知見を交えてご紹介します。

想定読者: CognitoとSESを使った認証システムを構築するエンジニア、メール配信の信頼性向上を目指す方

Cognitoにおける2種類のメール送信方法

まず、Cognitoでメールを送信する方法には、以下2種類の方法があります。

• デフォルトのメール送信
• SES連携による送信

それぞれの特徴を理解し、用途に応じて適切な方法を選択することが重要です。

デフォルトのメール送信

デフォルトのメール送信では、 no-reply@verificationemail.com というAWSが提供する共有アドレスから送信されます。設定が不要で、Cognitoの作成直後から使用できるため、ちょっとCognito使ってみようかなという段階では手軽に利用ができます。

特徴

• 設定不要で即座に利用開始可能
• 送信元アドレスは、 no-reply@verificationemail.com で固定

制限事項

• 送信制限: 1日あたり50通、1秒あたり1通
• カスタマイズ不可: 送信元アドレスを自社ドメインに変更できない
• 信頼性の低下: 汎用的なドメインからの送信は、スパムフィルターに引っかかりやすい
• 監視不可: 送信状況やエラーの詳細を把握できない

SES連携による送信

SESと連携することで、本番環境に適した高品質なメール送信が可能になります。それであれば最初からデフォルト送信を使わずにSESを使えばいいじゃないかと思うかもしれませんが、SESを本番環境で使用するには事前準備が必要となります。迷惑メールに振り分けられる対策からは脱線しますので、詳細は省きますが、SESを利用する場合にはサンドボックス環境に配置されているのを解除しなければ、機能を意図した通りに利用できません。

この解除にはAWSへ解除の申請が必要です。なぜこのような手順が必要になるかというと、SESを自由に使えてしまうと、それこそ迷惑メールを手軽に送信できてしまうため、利用用途や受信者による配信停止方法などを記載し、審査を通過しなければ制限の解除が行われないようになっています。

実際に申請理由が不十分で、初回の申請では承認されず、追加の内容確認をされたことがありますのでこれから申請を行うという方はご注意ください。

メリット

• 送信上限の大幅な拡大: 1日あたり数万通以上の送信が可能
• 独自ドメインの使用: noreply@kyoso.co.jp など、自社ドメインからの送信が可能
• 送信メトリクスの可視化: CloudWatchで送信数、バウンス、苦情などの集計データを確認
• 詳細ログの取得: CloudWatch LogsやOpenSearchに詳細なイベントログを出力可能
• 高い信頼性: DKIM署名により、メールの信頼性が大幅に向上

デメリット

• 事前準備に時間がかかる

比較表

項目	デフォルト送信	SES連携
設定の簡単さ	不要	DNS設定必要
送信数制限	50通 / 日	数万通 / 日
送信速度	1通 / 秒	数百通 / 秒
送信元アドレス	固定	カスタム可能
DKIM署名	なし	あり
メール信頼性	低い	高い
監視・ログ	不可	可能
コスト	追加料金なし	SES料金のみ
本番運用	非推奨	推奨

推奨 : 開発・検証段階ではデフォルト送信でも問題ありませんが、送信制限やメールの信頼性の観点から、本番環境ではSES連携が必須です。サンドボックスの解除には申請が必要となり、承認されるまで制限は解除されません。サポートが混雑していた際ですが、数日で承認されなかったケースがありましたので、時間には余裕をもって対応を進めましょう。

SES連携における2種類の認証方法

前章では、デフォルトのメール送信とSES連携を比較しました。次にSESでのメール送信にも種類があり、考慮が必要です。SESでメールを送信するためには送信元の認証が必要になります。

方法は以下2種類です。

• Eメールアドレス認証
• ドメイン認証

それぞれの特徴を後述しますが、結論、本番環境での運用は ドメイン認証 を推奨します。

Eメールアドレス認証

Eメールアドレス認証は、noreply@kyoso.co.jp のように個別のメールアドレスごとに認証を行う方法です。

メリット

• 設定が簡単で、すぐに利用開始できる
• DNS設定が不要 ( ドメイン管理権限がなくても使用可能 )

デメリット

• 送信元アドレスを変更・追加するたびに個別認証が必要
• DKIM署名が付与されない
• 複数のアドレスを使う場合、管理が煩雑

ドメイン認証

kyoso.co.jp のようにドメイン全体を認証する方法です。

メリット

• 一度設定すれば、同じドメインの任意のアドレスを使用可能
• DKIM署名により、メールの信頼性が大幅に向上
• なりすまし対策が強化され、迷惑メール判定されにくい
• メール到達率の向上 ( 実際の運用で迷惑メール振り分けが解消 )
• 送信元アドレスの追加・変更が柔軟に対応可能

デメリット

• DNSレコードの設定が必要 ( ドメイン管理権限が必要 )
• 設定手順がやや複雑
• DNS設定ミスによる問題発生のリスク

比較表

項目	Eメール認証	ドメイン認証
設定の簡単さ	簡単	やや複雑
DNS設定	不要	必要
DKIM署名	なし	あり
SPF/DMARC	限定的	対応
複数アドレス対応	個別登録必要	ドメイン内で自由
メール信頼性	低い	高い
なりすまし対策	弱い	強固
コスト	SES料金のみ	SES料金 + Route53料金
本番運用	非推奨	推奨

推奨 : 本番環境ではドメイン認証を使用しましょう。サンドボックスの解除はされている状態のため、送信回数等の機能制限については差はありませんが、メールの到達率や信頼性に差が出ます。

Eメール認証でも、リリース前のテストなどでは特に問題が発生せず、メールが届くことを確認できれば、手間をかけてまでドメイン認証をする必要があるのかとなるかもしれません。

それでも長期的にみて迷惑メールとなる可能性を下げられるのであれば、ドメイン認証を採用するメリットが大きいと考えます。

送信方法の分岐

ドメイン認証の設定

ここまで説明したように、本番環境ではドメイン認証を使用することが推奨されます。理由としては、DKIM、SPF、DMARCという3つの認証技術を活用するためです。 ( 各技術の詳細は本題ではないため、概要のみ記載します。興味がある方は調べてみてください。 )

デメリットとして記載したように、ドメイン認証の設定はDNS ( AWSではAmazon Route 53 ) の知識が無いと難しいと感じるかもしれません。

そういった方々も安心してください。AWSの場合はコンソールでの設定がサポートされていて簡単な手順で行えます。本章では、ドメイン認証の具体的な設定方法を解説します。

メール認証技術の概要

DKIM ( DomainKeys Identified Mail )

メールに電子署名を付与し、送信元ドメインの正当性とメール内容の改ざん防止を保証する技術です。受信側はDNSで公開されている公開鍵を使って署名を検証します。

SPF ( Sender Policy Framework )

送信元IPアドレスを検証することで、なりすましメールを防ぐ技術です。ドメインの所有者がDNSレコードで許可された送信サーバーのIPアドレスを公開し、受信側がそれを確認します。

DMARC ( Domain-based Message Authentication, Reporting and Conformance )

DKIMとSPFの検証結果に基づいて、メールの処理方法 ( 配送、隔離、拒否 ) を指定する技術です。また、認証失敗時のレポートを送信元に通知する機能も提供します。

これら3つの技術を組み合わせることで、「なりすましメール」や、「改ざんされていない」ことを証明できるため、メールの信頼性を向上させ、迷惑メールと判定されないように対策を行います。

設定手順

SESのページでIDを作成

AWSのコンソールにログインしてSESのページを開きます。

右上のIDの作成ボタンを押すとIDの設定ページへ移動します。

移動したページで以下の項目を入力します。

IDの詳細

• IDタイプ: 「ドメイン」を選択
• ドメイン: 任意のドメインを入力
• カスタム MAIL FROM ドメインの使用: チェックボックスをON
• MAIL FROM ドメイン: 任意のメールアドレスを設定
• DNS レコードの Route53 への発行: 有効化

ドメインの検証

DKIM の詳細設定

• IDタイプ: Easy DKIMを選択
• DKIM 署名キーの長さ: RSA_2048_BITを選択
• DNS レコードのRoute53 への発行: 有効化
• DKIM 署名: 有効化

IDの作成

右下の「IDの作成」ボタンを押下すると、Cognitoのメール送信で利用するSESのIDが作成されます。

DMARCの設定

IDを作成後DMARCの欄が表示されます。

右上の「DNSレコードのRoute53への発行」ボタンを押下すると、自動でRoute 53に設定されます。

Route 53 の確認

ここまでの作業でドメイン認証および、各認証の有効化を行えます。

念の為、Route 53の設定を確認しましょう。

意図した設定となっていれば以上でSESの設定作業は完了です。

Cognitoのメール設定

最後にCognitoのページで、作成したIDを送信元メールアドレスとして設定しましょう。

「送信元のEメールアドレス」として作成したIDが選択できるようになっているはずです。

まとめ

Cognitoのメールが届かない主な原因は、送信元の信頼性不足が考えられます。

したがって、Cognitoのメール送信を本番環境で利用する際には、送信先で迷惑メールとならないようにSESと連携した上で、ドメイン認証を行うことを推奨します。

実際に迷惑メールに振り分けられていた問題は、ドメイン認証に切り替え、各種の認証を有効にすることで解消しています。

私自身ネットワーク関連のサービスを常日頃から運用しているわけではなく、ドメイン認証を設定する際にRoute 53の設定を変更するのは間違えると影響が大きいので慎重になっていました。ただ、同じことを思っていた人が多く要望があったのか、実際にやってみると想像以上に簡単にRoute 53の操作なしで設定できるようになっていました。心理的にハードルが高く、まだ導入していないというのであれば、ぜひ取り入れてみてはいかがでしょうか？