この記事は みらい翻訳のカレンダー | Advent Calendar 2023 - Qiita の 2 日目です。
こんにちは。プラットフォーム開発部でリードエンジニアをしている chance です。
今回は AWS SES でのドメイン認証の設定のポイントについてお話しします。
TL; DR
- SESではデフォルトでドメイン認証の設定がされています。単純に「ドメイン認証をPASSさせる」だけならカスタム設定は不要なのですが、「自身のドメインでのドメイン認証をPASSさせる」ための設定にはなっていません。
- カスタム MAIL FROM ドメインを設定して EnvelopeFrom と HeaderFrom を揃え、DKIMで作成者署名を設定し、DMARCを設定しましょう。
はじめに
AWS SES(Simple Email Service) はその名の通りEメール送信のためのマネージドサービスです。本来、メールサーバを運用するにはメールに関する専門知識やエンジニアが必要ですが、このようなサービスを利用することで誰でも簡単にセキュアなメール送信が可能になります。便利な世の中になったものです。
一方で、何も知らなくてもAPIを呼ぶだけでメールが送信できてしまいますので、商用サービスの運用を続けていたら実は一部のユーザにはメールが届いていなかった、という事態も出てくるかもしれません。
誤解のないように、SES 自体としてはメールサーバとして十分セキュアな設定がされています。ただし、自身のドメインでメールを送ることに最適化されているわけではない、ということになります。
今回の記事では、メール配信のセキュリティ対策として必須であるドメイン認証の仕様とともに、SESで何を設定をしたらよいかをお話しできればと思います。具体的な設定方法については公式のドキュメントにもしっかり記載されていますので深く扱わず、ここでは「どのような仕組みで、どのような懸念があり、なぜ設定が必要なのか」をイメージとして掴んでもらえれば幸いです。
SESに対する誤解
まず、今日のお話のポイントを提示します。
端的には、SESのデフォルト設定では「SESから（すなわちAWSから）メールを送ること」に対する認証設定となっています。実際にSESを利用する際、大抵の場合は送信元のメールアドレスに自身のドメインを指定することになると思いますが、「自身のドメインからメールを送ること」のドメイン認証としては設定されていないのです。
AWSからの認証済みということで、これによって全くメールが届かないということはありませんが、メールを受信するプロバイダによっては「メールの差出人と送信元システムが違う」と判定されてしまい、迷惑メールフォルダに落ちたり最悪の場合は受信拒否される可能性も出てきてしまいます。有名なところでは、日本の携帯キャリアのメールアドレスなどではこの傾向が見られるようです。
公式のドキュメントの方でもドメイン認証を独自のドメインで設定するメリットや方法についてきっちり記載されています。
しかし、メールの仕様に対する知識がないと膨大なドキュメントの中から必要な設定であると把握するのは難しいかもしれません。結果として、デフォルト設定のままでも受信したメールではSPFもDKIMも判定としてはPASSしますので、これで問題ないと誤解される方も多いかと思われます。
送信元メールアドレスは2つ存在する
ドメイン認証の説明に入る前に、SMTPの仕様についてお話しします。送信元メールアドレスの正当性を検証するにあたり、その対象となるFromアドレスは常に2種類存在します。これはドメイン認証を理解する上で大事な概念となりますので、先に解説します。
SMTP のメッセージは Envelope Header Body という 3 つの要素で構成されます。
Envelope がいわゆる「封筒」のイメージです。送信元（MAIL FROM）と送信先（RCPT TO）の情報を持っていて、サーバ間通信では Envelope の From/To が利用されます。
メール受信後、封筒の中にある Header と Body が受信者に表示されます。私たちに馴染みのあるメールの内容（差出人、タイトル、本文など）は Header と Body の内容であり、通常 Envelope の From を直接目にすることはありません。（メールヘッダにある Return-Path が Envelope From とほぼ一致します。）
これ以降、本記事ではEnvelopeのMAIL FROMのメールアドレスのことを EnvelopeFrom 、HeaderのFromのメールアドレスのことを HeaderFrom と呼びます。
このように、SMTPでメールを送る際はFromアドレスが2種類あることを覚えておいてください。
ドメイン認証の仕様を理解する
ドメイン認証で代表的な技術はSPF/DKIM/DMARCの3つになります。細かくは他の仕様もありますが、SESを利用する上ではこの3つを押さえておけばよいかと思います。
SPF
SPF (Sender Policy Framework)は、メールの送信者がそのドメインからメールを送信する権限があるかどうかを検証するための仕組みです。この時のドメインは、EnvelopeFrom が用いられます。具体的には、送信元IPアドレスがそのドメインの許可リストに含まれているかどうかを確認します。
# SPFの設定例 mail.example.com. 3600 IN TXT "v=spf1 ip4:11.22.33.44 ~all"
EnvelopeFrom は偽装が可能ですが、送信元IPアドレスの偽装は難しいです。DNSの設定はドメインの管理者しか行えないため、SPFレコードを設定しておくことでEnvelopeFromのなりすましを見抜くことができます。
注意すべき点として、送信元IPアドレスの直指定だけでなくDNSのincludeも可能なのですが、includeの参照回数は10回が上限となります。特にDNSの参照先でさらにincludeしていたりすると、それも累計して合計10個までです。SESをはじめとした外部サービスのメール送信を利用する場合、include機能を利用することが多くなるため注意しましょう。
その他にもSPFには以下のような弱点があります。
- メールの転送設定などで送信元 IP アドレスが変わってしまうと認証失敗となる。
- HeaderFromの改ざんには気付けない。
- 悪意を持ってSPFレコードを設定されても、形式上SPFはPASSしてしまう。
このような弱点に対しては、他のドメイン認証技術と組み合わせることで補完的に対処します。
DKIM
DKIM (DomainKeys Identified Mail)は、メールの内容に対する電子署名をメールヘッダに付与して、メールの内容になりすましや改ざんがないかどうかを検知します。この電子署名を検証するための公開鍵を、HeaderFromドメインのサブドメインとしてDNSで公開します。
# DKIMの設定例
{セレクタ}._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p={公開鍵};"
DKIMには、「送信者署名」と「第三者署名」の2種類があります。
| 種類 | 概要 |
|---|---|
| 送信者署名 | HeaderFromのサブドメインで署名すること |
| 第三者署名 | 中継サーバや転送サービスが署名すること |
SESはデフォルトで amazonses.com のサブドメインでの署名を付与するため、第三者署名の一形態と呼べます。この時点では送信者署名は付与されていません。送信者署名を付与する場合は、追加で設定が必要となります。この際、署名自体はやはりSESで行われるのですが、DKIMのセレクタが個別のものとして発行されます。個別のセレクタを含むDKIMレコードに対して、自身のドメインをCNAMEレコードとしてDNS登録することで送信者署名を実現することになります。
また、DKIMにも弱点があります。
- SPFと比べて設定手順が複雑で難易度が高いため、普及率がSPFより低い。
- メーリングリストなどで HeaderFrom が変わってしまうと認証失敗する可能性がある。
- 悪意を持ってDKIMレコードを設定してDKIM署名されても、形式上DKIMはPASSしてしまう。
こちらもSPFと同じく、他のドメイン認証技術と組み合わせることで補完的に対処します。
DMARC
DMARC (Domain-based Message Authentication, Reporting, and Conformance)は、SPF や DKIM が認証失敗した場合に受信側でメールをどう扱うかを指定します。
また、DMARCでは HeaderFrom に対する検証が行われます。SPFであれば、SPF自体がPASSすることに加えてEnvelopeFromとHeaderFromが同一のドメイン（またはサブドメイン）であることが条件となります。DKIMであれば、同じくDKIM自体がPASSすることに加えて、第三者署名でなく送信者署名であることが条件となります。
- DNSにレコード登録する
# DMARCの設定例 _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:postmaster@example.com"
認証失敗した場合の取り扱い方法は3種類から選択します。プラクティスとしてはnoneから始めて運用状況を見ながら制限を強くしていくのがよいようです。
| DMARCポリシー | 意味 |
|---|---|
| none | 認証に失敗しても受信トレイには入れる |
| quarantine | 認証に失敗したら迷惑メールフォルダに入れる |
| reject | 認証に失敗したら受信しない（バウンスになる） |
また、DMARCを正しく運用するためには認証失敗時のレポートを受け取る仕組みが必要となります。レポートの受け取り先を指定せずにDMARCを設定することも可能ですが、より効果的にDMARCを活用したい場合はレポートを受け取るようにします。レポートサーバの用意やレポートの分析・対処などの運用が必要なことがDMARC導入の一番の障壁かと思われます。SESから話題はそれますが、メール配信機能をまとめて扱ってくれるSaaSサービスなどを利用すると、この辺りの運用も任せられるかもしれません。
DMARCはDKIMよりもさらに普及率が低いようです。おそらく、レポートサーバの準備など運用難易度の高さも影響しているでしょう。また、p=noneの場合、実際にメールは届いてしまうため意味がないとする指摘もありますが、効果が最大化できないというだけで全く意味がないとは思いません。まずはp=noneから始めて少しでも信頼性を高めておき、メールの運用を本格化する際にはレポートサーバを備えて制限を強くする検討をしていくのがよいかと思います。
EnvelopeFrom と HeaderFrom を揃える
ここまでの説明を踏まえて、あらためてSESのデフォルトの設定を整理します。
- EnvelopeFrom は
amazonses.com（またはそのサブドメイン） - HeaderFrom は自身で設定したドメイン（ここではexample.com としておきます）
- SPF は
amazonses.comとして登録されているため、PASSする - DKIMは
amazonses.comのサブドメインで署名され、PASSする（第三者署名にあたる） - DMARCは自身のドメインでは通らない（EnvelopeFromとHeaderFromが違う上、DKIMが送信者署名ではない）
前述の通り、メール受信プロバイダの中には EnvelopeFrom と HeaderFrom のドメインが異なる場合は不審なメールと判断するものがあります。特別な理由がない限り、EnvelopeFrom と HeaderFrom のドメインは一致させましょう。SES の「カスタム MAIL FROM ドメイン」を設定して、EnvelopeFrom を指定することができます。また、それだけでは SPF が失敗するので、併せて DNS にSPFレコードを追加します。具体的な設定値は カスタム MAIL FROM ドメインの設定時に指示がでます。
DKIMに関しても、自身のドメインで署名ができるように設定を行いましょう。こちらも公式の手順に従えば難しい点はないかと思います。
EnvelopeFromとHeaderFromが揃い、送信者署名ができるようになったことで、自身のドメインとしてDMARCの登録も可能になります。DNSにDMARCポリシーを設定しましょう。
まとめ
AWS SES はデフォルト設定のままでもドメイン認証は通っていますが、あくまでも「AWSとして」の認証です。自身のドメインからのメールとして正しくドメイン認証をするためには以下の設定が必要となります。
- カスタムMAIL FROMドメイン設定でEnvelopeFromを設定する
- EnvelopeFromのドメインに対してSPFレコードを登録する
- HeaderFromのドメインでDKIMを設定をする
- 自身のドメインに対してDMARCを設定する
これらの設定を行わない場合、送信先のプロバイダのポリシーによってはメールを受け取ってもらえない可能性があります。特に、携帯キャリアのメールなどの利用が想定される場合は気をつけた方がよいでしょう。
今回の記事が、ドメイン認証やSESでの設定に対する理解の一助になれれば幸いです。
最後に
みらい翻訳では、エンジニアを募集しています。
ご興味のある方は、ぜひ下記リンクよりご応募・お問い合わせをお待ちしております。
