はじめに
SESのカスタム MAIL FROMの必要性について、メールの送信ドメイン認証の基本を復習しながらまとめてみました。
SESとは
SESについて、AWSの公式ドキュメントの記載を引用します。
ざっくりいうと、Eメールを配信することができるマネージドサービスです。
Amazon Simple Email Service (Amazon SES) は、ユーザー自身の E メールアドレスとドメインを使用して E メールを送受信するための、簡単でコスト効率の高い方法を提供する E メールプラットフォームです。
例えば、特価販売などのマーケティング E メールや、注文確認などの取引 E メール、ニュースレターなどのその他のタイプの通信文の送信に使用できます。Amazon SES を使用してメールを受信するときは、E メール自動応答システム、E メール登録解除システム、受信 E メールからカスタマーサポートのチケットを生成するアプリケーションなどのソフトウェアソリューションを開発できます。
本題に入る前に、メール送信の基本について振り返りたいと思います。
メール送信の流れ
メール送信は以下の流れで行われます。
① 送信元コンピュータのメールソフトからメールを送信します。
② 送信元のメールサーバが、宛先のドメイン情報をDNSに問い合わせる
メールアドレス（例：BBB@anotherdomain.com）の「anotherdomain.com」の部分を元に、DNSサーバにMXレコードを問い合わせ、宛先メールサーバの名前（ホスト名）を取得します。
※ドメイン名をIPアドレスに変換するため、DNSが必要です。
③ 宛先となるメールサーバへメールが転送されます。
④ 宛先となるコンピュータのメールソフトでメールを受信します。
メールで利用するプロトコルの補足
メールに利用するプロトコルについて、以下に補足します。
メール送信時にSMTP、メール受信時にPOP・IMAPを利用します。
- SMTP：メールソフトからメールサーバへメールを送信する際に利用するメール送信用のプロトコル
- POP：ユーザがメールサーバから自分宛のメールを取り出す際に使用するメール受信用のプロトコル
- IMAP：ユーザがメールサーバ上の自分宛メールへアクセスして操作するためのプロトコル
SMTP
SMTPについて追加で補足します。
SMTPで送信するメッセージは、以下の3つの要素で構成されます。
・Envelope：メールがインターネットを通じて正しく配信されるために必要な送信情報を含みます。
送信元（MAIL FROM）と宛先（RCPT TO）のメールアドレスが記載され、メールサーバ同士のやり取りで使用されます。
・Header：メールの「表紙」のようなもので、送信者（From）、受信者（To）、件名、送信日時などのメタデータを含みます。
エンドユーザーがメールソフトで見る情報の大半がここに含まれます。
・Body：実際のメールの内容が書かれている部分です。
ここで、「From」と「To」のアドレスがEnvelopeとHeaderの両方に登場する点に注目しましょう。
それぞれの目的と使われ方は以下の通りです。
Envelope アドレス（メール配送時に使用）
・Envelope To：
受信者のメールサーバにメールを配送する際に使用される配送先アドレスです。SMTP通信中にサーバ間で利用されます。
・Envelope From：
メールの配送中に何らかの理由でエラー（例：宛先不明）が発生した場合、エラーメールの返送先として使用されます。
Envelope アドレス（メール内容として利用）
・Header To：
受信者のメールソフトに表示される宛先アドレスです。ユーザーが誰宛てに来たメールかを確認するために使われます。
・Header From：
メールの差出人情報として表示され、返信時の宛先としても使用されます。実際の送信者名として扱われます。
送信ドメイン認証
実際にメールを送信する際には、「送信者が本物か？」「内容が改ざんされていないか？」を検証するために、送信ドメイン認証が行われます。
ここでは、代表的な認証方式であるSPF、DKIM、DMARCについて解説します。
これらの仕組みは、Amazon SES でカスタム MAIL FROM ドメインを使用するかどうかを判断するうえで、非常に重要なポイントになります。
SPF
SPF（Sender Policy Framework）は、あるメール送信者が本当にそのドメインからメールを送信する権限があるかどうかを検証する仕組みです。
送信者は、メールを送信する前に「SPFレコード」をDNSに登録します。
このレコードには、Envelope Fromに記載された送信ドメイン（例：example.com）に対して、許可された送信メールサーバ（IPアドレス）を定義します。
受信側のメールサーバは、メールを受信する際にEnvelope FromのドメインのDNSに問い合わせて、その送信元IPアドレスがSPFレコードに登録されているかどうかを確認します。
正規の送信メールサーバ A.A.A.A は、example.comドメインのSPFレコードに登録されています。
この場合、DNS照会の結果と照合し、正当な送信元であると判断されるため、メールは受信されます。
一方、攻撃者が別の送信サーバ（C.C.C.C）を使って example.comを名乗りメールを送ってきた場合、C.C.C.C はexample.comのSPFレコードに含まれていないため、受信メールサーバはそのメールを拒否、またはスパムとして処理します。
一方、SPFには以下の弱点があるため、他のドメイン認証技術と組み合わせて補完的に対処します。
① SPFレコードが正しく管理されていないと機能しない
② メール転送に弱い
③ 「Header From」アドレスを検証しないため、改ざん検知に弱い
DKIM
DKIMは、メールの内容に電子署名を付けることで、送信者の正当性や改ざんの有無を検証する技術です。
送信者は、あらかじめDNSに「DKIMレコード」を登録しておきます。
このレコードには、メールの署名を検証するための公開鍵が含まれており、Header Fromのドメインまたはサブドメインに設定します。
メールを送信する際、送信側のメールサーバは秘密鍵を使って電子署名を作成し、メールのヘッダーにDKIM-Signature として付与します。
受信者側のメールサーバは、送信元ドメインのDNSから公開鍵を取得し、その署名が正しいかどうかを検証します。
たとえば、メールが途中で改ざんされたり、悪意のある中継サーバを経由して不正に内容が書き換えられた場合、電子署名の検証に失敗するため、受信側はそのメールを信用できないものとして処理（拒否・隔離など）します。
一方で、DKIM単体では、「誰が署名したかは確認できても、それが“正しい送信者か”までは保証できない」という弱点があります。
①ドメイン自体が信頼されていない場合でも、形式だけ整えばPASSになる
②メーリングリストなどで署名が壊れる
③Header Fromの検証を行わない
DMARC
DMARCは、SPFやDKIMの弱点を補完するために設計された送信ドメイン認証技術です。
SPFやDKIMによる認証結果に基づき、認証に失敗したメールを受信側でどう扱うかをポリシーとして指定できます。
DMARCの仕組み
送信者は、メールを送信する前にDMARCレコードをDNSに登録します。
このレコードには、以下の情報が含まれます：
・認証ポリシー（none / quarantine / reject）
・レポート送信先（集計・個別レポート）
受信メールサーバは、Header From のドメインにDMARCレコードがあるかをDNSで確認し、
SPFまたはDKIMの認証結果＋アライメント（整合性）をもとに認証成功/失敗を判定します。
アライメントとは、メールの送信元ととして「見えているドメイン（Header From）」と、「SPFまたはDKIMの認証に使われたドメイン」が一致しているかどうかを確認することです。
認証に失敗した場合は、DMARCポリシーに従ってメールを処理し、
必要に応じて送信元にレポートを送信します。
DMARCを利用する場合、メールは以下のいずれかに合格する必要があります。
- SPF認証
- SPFアライメント
- DKIM認証
- DKIMアライメント
SPFとDKIMのどちらかが認証とアライメントをPASS（合格）できていれば、もう一方は未導入あるいはFAIL（失敗）となっていてもDMARC認証にPASSすることができます。
ただし、SPFとDKIMの認証がどちらも合格していたとしても、アライメントが両方とも失敗している場合、FAILとなります。
※後述しますが、DKIMアライメントはDKIM認証が成功している前提のものとなります。
SPFとDKIMの認証については先述の通りなので、アライメントについて説明します。
アライメントでは、Header Fromに対する検証を行います。
これは、Header Fromは自由に設定可能で第三者により無関係なドメインを偽ることが容易であるためです。
そのため、SPFとDKIMのアライメントでは以下を検証します。
- SPFアライメント：Envelope FromとHeader Fromが同一のドメインまたはサブドメインであるかを検証します。
- DKIMアライメント：第三者署名ではなく送信者署名であるかを確認します。
- 第三者署名：中継サーバや転送サービスで署名
- 送信者署名：Header Fromのサブドメインで署名
| 認証方式 | 比較するもの | 目的 |
|---|---|---|
| SPF | Envelope FromとHeader From | なりすまし送信の防止 |
| DKIM | 電子署名したドメインとHeader From | 改ざんされてないことの保証・なりすまし対策 |
SESでのデフォルト設定
Amazon SESでは、Envelope FromとHeader Fromのドメインがデフォルトで異なります。
- Envelope From：amazonses.com（またはそのサブドメイン）
- Header From：ユーザが設定した任意のドメイン
また、DKIM署名はSES側による署名（第三者署名）となります。
- DKIM署名：amazonses.comのサブドメインで署名されます
SESのデフォルト設定
SESのデフォルト設定での送信ドメイン認証について以下にまとめます。
〇 SPF認証：SESの送信サーバーのIPアドレスが amazonses.com のドメインと一致するため、SPF認証自体はPASSします。
〇 DKIM認証：SESのDKIM署名は有効のためPASSします。
× DMARC認証：
DMARCでは、「認証成功 ＋ アライメント（整合性）一致」が必要ですが、SPFとDKIMの両方で、アライメント（Header Fromとの一致）がFAILとなります。
そのため、DMARC認証全体としてはFAILになります。
そのため、SESでDMARCを利用したい場合以下の対応が必要となります。
- カスタムMAIL FROMを利用してEnvelope FromとHeader Fromのドメインを一致させる。
- DKIMの電子署名はHeader Fromのサブドメインで付与する。
本ブログでは、カスタムMAIL FROMについて取り上げたいと思います。
カスタムMAIL FROMとは
カスタムMAIL FROMは、AWSのデフォルト設定となっているEnvelope Fromをユーザ側で設定することができる機能です。
設定方法については省略させていただきます。
以下を参考にしてください。
カスタムMAIL FROMを設定するメリットを以下に示します。
認証におけるリスク低減
認証の安定性を高め、受信側の動作に左右されにくくなります。
- SPFアライメントの不一致を排除できる
- Envelope FromとHeader Fromのドメインを一致することができるため、DMARKにおけるSPFの認証とアライメントが確実に通るようになります。これにより、DMARKがPASSします。
- DKIMアライメントへの依存を減らせる
- SPFアライメントが確保されることで、DKIMアライメントに頼る必要が減ります。
- DKIM署名の検証は受信側の実装に依存するため、環境によっては正しく処理されない可能性があります。
信頼性の向上
- 一部のメール受信プロバイダでは、Envelope FromとHeader Fromのドメインが異なる場合に、不審なメールと判定されることがあります。
- Envelope FromとHeader Fromを一致させることで、なりすましに見えにくくなり、メールの信頼性が向上します。
- Envelope Fromを自社の正規ドメインに設定すれば、その情報が受信側のメールサーバに残るため、送信者の正当性を明確に示すことができます。
- その結果、SPF認証の失敗リスクが低下し、受信側での信頼性が向上します。
運用・トラブルシューティング
- 先述のとおり、SESのデフォルト設定ではEnvelope Fromがamazonses.comのため、SPF認証はAmazon側の設定に依存します。
- 一方、カスタムMAIL FROMを使えば、自社ドメインをEnvelope Fromに設定できるため、自分でSPFレコードを管理可能になります。
- SPFレコードは、DNSのTXTレコードとして登録されるため、ポリシー変更や送信サーバの追加などに応じて、柔軟に管理・更新が可能です。
例：新しい送信サーバを追加したい場合や、セキュリティポリシー変更時など
結論
- SESを利用してDMARC認証をしたい場合、以下の設定を推奨します。
- カスタムMAIL FROMを設定し、Envelope Fromを自身のドメインで設定する。
- カスタムMAIL FROMに設定したドメインに対してSPFレコードを登録する
- DKIMの電子署名はHeader Fromのドメインで設定する。
さいごに
長くなりましたが、送信ドメイン認証とSESについてまとめることができてよかったです。
今回取り上げたDMARCについては、DMARCポリシーを適切に設定して運用しないと導入したところで意味がありません。メールが届かなくなるならすべてnoneで。といったような形骸化した形となっているケースが多くあると思います。そもそもちゃんと運用できるのか考えて導入することが重要ですね。
次はメールの認証済み受信チェーンについてARCを勉強したいと思います。