背景・目的

先日、SESを設定しましたが、DMARCの推奨事項が表示されたので調べたうえで試してみます。

まとめ

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

特徴	説明
DMARC	認証失敗時の対応策を定義 Domain-based Message Authentication, Reporting and Conformanceの略下記を使用して、Eメールのなりすまし、フィッシングを検出するEメール認証プロトコル・SPF ・DKIM DMARCに準拠するには、メッセージをSPFまたはDKIMで認証する必要がある理想的には両方をDMARCで使用すると、高いレベルの保護を確保できる
SPF	送信元メールサーバをIPアドレスで判別・DNSが使用するDNS TXTレコードを介してカスタムMAIL FROMドメインに変わってメールを送信できるメールサーバを特定する・受信者のメールシステムは、SPF TXTレコードを参照し、カスタムドメインからのメッセージが承認済みのメッセージサーバから送信されたかを判断する・SPFがはなりすまし防止で設計されている・実際は、SPFが影響を受けやすいなりすまし手法もある。そのためDMARCとともにDKIMも使用する必要がある
DKIM	電子署名使用して改ざんを検知・メールヘッダーのアウトバウンドメッセージにデジタル署名を追加する・受信メールシステムは、このデジタル署名を使用して、受信するメールがドメインが所有するキーによって署名されているかの検証に役立てる・メールシステムがメッセージを転送した場合、メッセージのエンベロープは SPF 認証を無効にするような方法で変更される・デジタル署名はメールヘッダーの一部であるため、メールメッセージに保持される。このため、メッセージがメールサーバー間で転送された場合でも、(メッセージコンテンツが変更されない限り) DKIM は機能する

概要

DMARCとは

下記を基に整理します。

DMARC (Domain-based Message Authentication, Reporting and Conformance) は、SPF (Sender Policy Framework) および DKIM (DomainKeys Identified Mail) を使用して、E メールのなりすましやフィッシングを検出する、E メール認証プロトコルです。DMARC に準拠するには、メッセージを SPF または DKIM で認証する必要があります。理想的には、両方を DMARC で使用すると、E メール送信に関して可能な限り高いレベルの保護を確保できます。

DMARCは、Domain-based Message Authentication, Reporting and Conformanceの略
下記を使用して、Eメールのなりすまし、フィッシングを検出するEメール認証プロトコル
- SPF
- DKIM
DMARCに準拠するには、メッセージをSPFまたはDKIMで認証する必要がある
理想的には両方をDMARCで使用すると、高いレベルの保護を確保できる

SPF と DKIM の機能と、DMARC がこの 2 つを連携する方法を簡単に説明します。

SPF – DNS が使用する DNS TXT レコードを介して、カスタム MAIL FROM ドメインに代わってメールを送信できるメールサーバーを特定します。受信者のメールシステムは、SPF TXT レコードを参照して、カスタムドメインからのメッセージが承認済みのメッセージングサーバーから送信されたかを判断します。基本的に、SPF はなりすまし防止目的で設計されているとはいえ、実際には SPF が影響を受けやすいなりすまし手法もあるため、DMARC とともに DKIM も使用する必要があります。

SPF
- Sender Policy Frameworkの略
- DNSが使用するDNS TXTレコードを介してカスタムMAIL FROMドメインに変わってメールを送信できるメールサーバを特定する
- 受信者のメールシステムは、SPF TXTレコードを参照し、カスタムドメインからのメッセージが承認済みのメッセージサーバから送信されたかを判断する
- SPFがはなりすまし防止で設計されている
- 実際は、SPFが影響を受けやすいなりすまし手法もある。そのためDMARCとともにDKIMも使用する必要がある

SPFのイメージを下記に載せます。

DKIM – E メールヘッダーのアウトバウンドメッセージにデジタル署名を追加します。受信 E メールシステムは、このデジタル署名を使用して、受信する E メールがドメインが所有するキーによって署名されているかの検証に役立てます。ただし、受信 E メールシステムがメッセージを転送した場合、メッセージのエンベロープは SPF 認証を無効にするような方法で変更されます。デジタル署名は E メールヘッダーの一部であるため、E メールメッセージに保持されます。このため、メッセージがメールサーバー間で転送された場合でも、(メッセージコンテンツが変更されない限り) DKIM は機能します。

DKIM
- DomainKeys Identified Mailの略
- メールヘッダーのアウトバウンドメッセージにデジタル署名を追加する
- 受信メールシステムは、このデジタル署名を使用して、受信するメールがドメインが所有するキーによって署名されているかの検証に役立てる
- メールシステムがメッセージを転送した場合、メッセージのエンベロープは SPF 認証を無効にするような方法で変更される
- デジタル署名はメールヘッダーの一部であるため、メールメッセージに保持される。このため、メッセージがメールサーバー間で転送された場合でも、(メッセージコンテンツが変更されない限り) DKIM は機能する

DKIMのイメージを下記に載せます。

DMARC – SPF と DKIM の少なくともいずれかでドメインのアライメントがとれていることを確認します。SPF と DKIM を単独で使用しても、送信元アドレスが認証されるかは保証されません (これは受信者が E メールクライアントで目にするメールアドレスです)。SPF は、MAIL FROM アドレスで指定されたドメインのみをチェックします (受信者には表示されません)。DKIM は、DKIM 署名で指定されたドメインのみをチェックします (これも受信者には表示されません)。DMARC は、SPF または DKIM のいずれかでドメインのアライメントが適切であることを求めることで、このような 2 つの問題に対処します。

DMARC
- SPFとDKIMの少なくともいずれかでドメインのアライメントが取れていることを確認する
- SPFとDKIMを単独で利用しても、送信元アドレスが認証されるか保証できない
  - SPFは、MAIL FROMアドレスで指定されたドメインのみをチェックする
  - DKIMは、DKIM署名で指定されたドメインのみをチェックする

SPF が DMARC アライメントで適格になるには、送信元アドレスのドメインが MAIL FROM アドレス (Return-Path やエンベロープ送信元アドレスとも呼ばれます) のドメインと一致する必要があります。Return-Path (MAIL FROM) は、プロバイダー (SES) が所有するアドレスを使用して追跡するバウンスや苦情に使用されます。このため、転送されたメールの場合には削除され、ほぼ不可能です。またはサードパーティーの一括 E メールプロバイダー経由でメールを送信する場合にもほとんど不可能です。

SPFがDMARCアライメントで適格になるには、MAIL FROMアドレスのドメインと一致する必要がある
- Return-Pathはプロバイダーが所有するアドレスを使用して追跡するバウンスや苦情に使用される

DKIM が DMARC アライメントに適格になるには、DKIM 署名で指定されたドメインが、送信元アドレスのドメインと一致する必要があります。お客様の代理でメールを送信するサードパーティーの送信者やサービスを使用する場合、サードパーティーの送信者が DKIM 署名向けに適切に設定され、お客様のドメイン内に適切な DNS レコードが追加されていることを確認することで、これを実現できます。その後、受信側メールサーバーは、サードパーティーから送信されたメールをドメイン内でアドレスを使用する権限が付与されたユーザーから送信されたメールであるかのように検証を行うことができます。

DKIMがDMARCアライメントで適格になるには、DKIM署名で指定されたドメインが送信元のアドレスと一致している必要がある
- 利用者の代理でメールを送信するサードパーティーの送信者やサービスを使用する場合、サードパーティーの送信者がDKIM署名向けに適切に設定され、利用者のドメイン内に適切なDNSレコードが追加されていることを確認することで実現できる

DMARC を使用した仕組みの構築
上記の DMARC アライメントチェックは、SPF、DKIM、DMARC すべてが連携し、ドメインの信頼性と受信トレイへの E メールの配信を向上させる方法です。DMARC は、受信者に表示される送信元アドレスが SPF または DKIM のいずれかによって認証されることを必須とすることでこれを実現します。

説明したとおり SPF または DKIM チェックのいずれかまたは両方で適格性が認められた場合、メッセージは DMARC で適格性が認められます。

説明したとおり SPF または DKIM チェックの両方で適格性が認められないと、メッセージは DMARC で不適格と見なされます。

したがって、DMARC が送信メールを認証する可能性を最大限に向上するには、SPF と DKIM の両方が必要であり、これら 3 つをすべて活用することで、送信ドメインが完全に保護されることが保証されます。

DMARC を使用する場合、ユーザー設定のポリシーを使用して、DMARC 認証に失敗した E メールの処理方法を E メールサーバーに指示することもできます。これについては、次のセクション「ドメインでの DMARC ポリシーのセットアップ」で説明します。このセクションには、送信する E メールが SPF と DKIM の両方を介して DMARC 認証プロトコルに準拠するように SES ドメインを設定する方法に関する情報が提供されています。

DMARC アライメントチェックは、SPF、DKIM、DMARC すべてが連携し、ドメインの信頼性と受信トレイへの E メールの配信を向上させる方法
DMARC は、受信者に表示される送信元アドレスが SPF または DKIM のいずれかによって認証されることを必須とすることでこれを実現する
DMARC が送信メールを認証する可能性を最大限に向上するには、SPF と DKIM の両方が必要
DMARC を使用する場合、ユーザー設定のポリシーを使用して、DMARC 認証に失敗した E メールの処理方法を E メールサーバーに指示することもできる

ドメインでの DMARC ポリシーのセットアップ

DMARC をセットアップするには、ドメインの DNS 設定を変更する必要があります。ドメインの DNS 設定に、ドメインの DMARC 設定を指定する TXT レコードが含まれている必要があります。DNS 設定に TXT レコードを追加する手順は、DNS またはホスティングプロバイダーによって異なります。Route 53 を使用する場合、Amazon Route 53 デベロッパーガイドの「レコードで作業」を参照してください。別のプロバイダーを使用する場合、DNS 設定についてはプロバイダーのドキュメントを参照してください。

作成する TXT レコードの名前は、_dmarc.example.comの必要があります。ここで、example.comはお客様のドメインです。TXT レコードの値には、ドメインに適用される DMARC ポリシーが含まれています。以下に、DMARC ポリシーを含む TXT レコードの例を示します。

DMARC をセットアップするには、ドメインの DNS 設定を変更する必要がある
ドメインのDNSを設定に、ドメインのDMARCを指定するTXTレコードが含まれている必要がある
作成するTXTレコードの名前は、_dmarc.{ドメイン}の必要がある

※出典：https://docs.aws.amazon.com/ja_jp/ses/latest/dg/send-email-authentication-dmarc.html#send-email-authentication-dmarc-dns

上記の DMARC ポリシー例では、このポリシーは E メールプロバイダーに以下を実行するように指示します。

認証に失敗したメッセージについてはすべて、ポリシーパラメータ p=quarantine で指定されているとおり、スパムフォルダに送信します。その他のオプションには、p=none を使用して何もしない、または p=reject を使用してメッセージを完全に拒否する、などがあります。

次のセクションでは、これら 3 つのポリシー設定の使用方法と、使用すべきケースについて説明します。適切でない設定を適切でないタイミングで使用すると、E メールが配信されなくなる可能性があります。「DMARC の実装のベストプラクティス」を参照してください。

レポートパラメータ rua=mailto:my_dmarc_report@example.com (rua は集約レポートのレポート URI の略) で指定されるとおり、認証に失敗したすべての E メールに関するレポートをダイジェスト (つまり、イベントごとに個別のレポートを送信するのではなく、特定の期間のデータを集約したレポート) で送信します。ポリシーはプロバイダーごとに異なりますが、通常、E メールプロバイダーは 1 日 1 回レポートを送信します。

例
- p=quarantine
  - スパムフォルダに送信する
  - その他オプションは、p=none何もしない、p=reject完全に拒否しない
- rua=mailto:my_dmarc_report@example.com
  - 認証に失敗したすべてのメールに関するレポートをダイジェストで送信
  - 通常 1日1回レポートを送信する

DMARC の実装のベストプラクティス

メールフローのその他の部分が中断しないように、DMARC ポリシーの実施は段階的なアプローチで実装することをお勧めします。以下のステップに沿ったロールアウトプランを作成して実装します。まず各サブドメインでこれらの手順を実行し、最後に組織内のトップレベルのドメインで実行してから、次の手順に進みます。

DMARC (p=none) の実装の影響をモニタリングします。

まず、メール受信組織に、そのドメインを使用して受信したメッセージに関する統計を送信するように要求するサブドメインまたはドメインのシンプルなモニタリングモードレコードから始めます。モニタリングモードレコードとは、ポリシーがなし p=none に設定されている DMARC TXT レコードです。

DMARC を介して生成されたレポートには、これらのチェックに合格したメッセージ数とメッセージの送信元が記載されます。正当なトラフィックがどの程度カバーされているか、またはカバーされていないかを簡単に確認できます。コンテンツが変更されると、転送されたメッセージは SPF と DKIM に失敗するため、転送のマークが表示されます。送信された不正なメッセージの数と送信元も表示されます。

このステップの目的は、次の 2 つのステップのいずれかを実装するとどのような E メールが影響を受けるかを把握し、サードパーティーまたは承認済みの送信者の SPF ポリシーまたは DKIM ポリシーへのアライメントを確保することにあります。

既存のドメインに最適です。

2.外部メールシステムに、DMARC (p=quarantine) に失敗したメールを隔離するようリクエストします。

正当なトラフィックのすべてまたはほとんどが SPF または DKIM のいずれかでドメインアライメントが確認されて送信されていることが確実であり、DMARC を実装することの影響を把握している場合に、隔離ポリシーを実装できます。隔離ポリシーとは、ポリシーが隔離 p=quarantine に設定されている DMARC TXT レコードです。これを実施することで、DMARC 受信者に、DMARC に失敗したドメインからのメッセージを、顧客の受信トレイではなく、スパムフォルダと同等のローカルの場所に配置するように要求することになります。

ステップ 1 で DMARC レポートを分析したドメインの移行に最適です。

3.外部メールシステムに、DMARC (p=reject) に失敗したメールを受け取らないようリクエストします。

通常、拒否ポリシーの実装が最後のステップとなります。拒否ポリシーとは、ポリシーが拒否 p=reject に設定されている DMARC TXT レコードです。これを実施すると、DMARC 受信者に DMARC チェックに失敗したメッセージを受け入れないように依頼することになります。つまり、これらのメッセージは、スパムフォルダや迷惑メールフォルダに隔離されることもなく、完全に拒否されます。

拒否ポリシーを使用すると、拒否によって SMTP バウンスが発生するため、DMARC ポリシーに失敗したメッセージを正確に把握できます。隔離の場合、集約データは、SPF チェック、DKIM チェック、DMARC チェックで適格または不適格となった E メールの割合に関する情報を提供します。

以前の 2 つのステップを実施した後の新しいドメインまたは既存のドメインに最適です。

メールフローのその他の部分が中断しないように、DMARC ポリシーの実施は段階的なアプローチで実装することを推奨
各サブドメインでこれらの手順を実行し、最後に組織内のトップレベルのドメインで実行する
下記の順で検証する
1. DMARC (p=none) の実装の影響をモニタリング
2. 外部メールシステムに、DMARC (p=quarantine) に失敗したメールを隔離するようリクエスト
3. 外部メールシステムに、DMARC (p=reject) に失敗したメールを受け取らないようリクエスト

SPF を介した DMARC への準拠

E メールが SPF に基づいて DMARC に準拠するためには、次の両方の条件を満たすことが求められています。

メッセージは、カスタム MAIL FROM ドメインの DNS 設定に発行した有効な SPF (タイプは TXT) レコードに基づいて SPF チェックで適格性が認められる必要があります。

E メールヘッダーの送信元アドレスのドメインは、MAIL FROM アドレスで指定されているドメイン、またはサブドメインとのアライメントが認められる (一致する) 必要があります。SES との SPF アラインメントを確保するために、ドメインの DMARC ポリシーで strict の SPF ポリシー (aspf=s) を指定することは避けます。

メールがSPFに基づいてDMARCに準拠するには下記の条件を満たす
- メッセージはカスタムMAIL FROMドメインのDNS設定に発行した有効なSPFレコードに基づいてSPFチェックで適格性が認められる必要がある
- メールヘッダーの送信元アドレスのドメインは、MAIL FROM アドレスで指定されているドメイン、またはサブドメインとのアライメントが認められる (一致する) 必要がある
  - ※SES との SPF アラインメントを確保するために、ドメインの DMARC ポリシーで strict の SPF ポリシー (aspf=s) を指定することは避ける

これらの要件に準拠するためには、次のステップを実行します。

カスタムMAILFROMドメインの使用の手順を実行して、カスタム MAIL FROM ドメインを設定します。

送信元ドメインが SPF に relaxed ポリシーを使用していることを確認します。ドメインのポリシーアラインメントを変更していない場合は、デフォルトで SES と同様に relaxed のポリシーが使用されます。

実践

DMARCの設定

AWSにサインインします
SESに移動します
ナビゲーションペインで、「ID」をクリックします
推奨事項に、DMARCが見つからない旨表示されています
「DNSレコードのRoute53への発行」をクリックします
正常に実行された旨が表示されます

Route 53の確認

Route 53に移動します
ホストゾーンをクリックします
レコードが追加されていました

推奨事項の確認

SESに移動します
ナビゲーションペインで、「ID」をクリックします
推奨事項で、「推奨事項を確認する」をクリックします
2分程で、「MAIL FROMレコードが調整されていません。」が表示されました
次の「カスタム MAIL FROM ドメインの設定」を設定します

カスタム MAIL FROM ドメインの設定

カスタムMAIL FROMドメインで「編集」をクリックします
下記を指定して、「変更の保存」をクリックします
- ①：カスタムMAIL FROMドメインの使用
- ②：MAIL FROMドメイン：任意
- ③：MX障害時の動作：デフォルトのMAIL FROMの使用（amazonses.comのサブドメイン） or メッセージを拒否
「正常に編集されました」のメッセージが表示されました
①「MAIL FROM設定のステータス」は保留中となりました。②「DNSレコードの Route 53への発行」をクリックします
「レコードを Route53 に正常に発行しました。」と表示されます
「MAIL FROM設定のステータス」は成功になりました。

Route 53の確認

Route 53に移動します
ホストゾーンをクリックします
レコードが追加されていました
MXとTXTレコードが追加されていました

推奨事項の確認

SESに移動します
ナビゲーションペインで、「ID」をクリックします
推奨事項で、「推奨事項を確認する」をクリックします
推奨事項が消えました

考察

今回、DMARC認証プロトコルと、DKIM、SPCを学びました。これらの技術によりなりすましを検知し、エラー時の対応を定義する方法が理解できました。また、SESでの実装も試しました。
引き続き、他の機能についても試してみる予定です。

参考