研究開発部 システム&セキュリティ担当の松倉です。
世間の DMARC 対応を加速させたといっても過言ではない Gmail におけるメール送信者のガイドラインが適用開始されてから 3 ヶ月近くが経ち、NFLabs. に届くメールでも DMARC ポリシーが設定されているドメインが多くなっています。
しかしながら、そのほとんどはポリシーが none であり、DMARC レポートを通じて影響範囲を見極めている、という企業がまだ多そうです。
受信側から見ると、ポリシーが quarantine または reject であればセキュリティ観点では安心感がある一方、正規のメールが検疫や破棄となる場合もあり悩まされることがあります。
DMARC 認証の失敗原因となりがちなのはメーリングリスト等のメール転送で、NFLabs. でもこれにより正規のメールが DMARC failとなって検疫される、という事例が発生しています。このようなケースの対策として、ARC を利用した DMARC 認証結果のオーバーライドがあります。
そこで、NFLabs. で利用している Microsoft 365 のメール環境である Exchange Online において、ARC がどのように使われているか調べてみました。
DMARC とは何か
読者の中にはこれから DMARC 対応を進めるドメイン所有者や企業の IT 担当者もいるかもしれませんので、改めて DMARC について簡単に解説しておきます（すでに知ってるよーという方は読み飛ばしちゃいましょう）。
DMARC (Domain-based Message Authentication, Reporting, and Conformance) は、メールの認証技術として普及している SPF と DKIM をベースに、なりすましやフィッシング、その他のサイバー攻撃からドメインを保護するためのメール認証技術です*1。
ものすごく大雑把に言うと、SPF か DKIM のどちらか一方の認証に成功しない限り DMARC の認証は失敗し、認証に失敗した時のメールの扱いをドメイン所有者が定める、という仕組みです（DMARC 認証に成功する条件の詳細は後述します）。
DMARC レコードと DMARC ポリシー
DMARC は SPF や DKIM と同様に、ドメイン所有者が DNS レコードに DMARC レコードを追加することで機能します。 例えば、gmail.com の DMARC レコードは以下のようになっています*2。
DMARC レコードは複数のタグで構成されており、必須のタグは v タグと p タグで、中でも重要なのが p タグです。このタグで設定している内容は DMARC ポリシーと呼ばれ、DMARC の認証に失敗した時のメールの扱いを定めています。DMARC ポリシーは以下の3種類から指定します。
- none : 認証の成否に関わらずアクションを要求しない。すなわち、受信者のメールサーバで受信されたすべてのメールが受信トレイに到達する。
- quarantine : 認証に失敗した場合、メールの隔離処理を要求する。例えば、スパムフォルダに配置する、検疫し受信者に届かないようにする、といった処理が行われる。
- reject : 認証に失敗したすべてのメールの受信拒否または破棄を要求する。
DMARC ポリシーに沿った具体的な処理内容はメール受信側に委ねられます。例えば、受信側が Microsoft 365 の場合、DMARC 認証に失敗したドメインの DMARC ポリシーが quarantine や reject に設定されていると、そのメールは検疫（隔離）され宛先のメールボックスには配送されません。
また、名称に Reporting とあるように、DMARC ではメールが受信サーバに届いた際に行われた認証の結果を DMARC レポートとして受け取ることが可能です。レポートは 2 種類あり、レポートの種類ごとに送付先を DMARC レコードの rua タグまたは ruf タグで指定できます*3。
DMARC 認証のおさらい
本題に入る前に、そもそもなぜ DMARC fail となってしまうのか、その原因をおさらいします。
DMARC は SPF と DKIM、およびそれぞれのアライメントによって認証されます。最終的に DMARC が pass となる条件をまとめると以下のようになります。
SPF と DKIM の認証結果は Authentication-Results ヘッダ*4で確認できますが、各アライメントの認証結果はヘッダに明示的には表示されません。そのため、 以下のように SPF と DKIM を pass しているのに DMARC fail という場合もあります。
それぞれどのような条件で pass となるのかは以下にまとめます。
SPF pass の条件
ドメインの DNS レコードに記載された IP アドレスから送られてきているかどうかを検証し、一致すれば pass となります。
例えば、メールサービスとして Exchange Online を利用している場合、以下のような SPF レコードを記載していると思います*5。
この場合、include しているドメイン spf.protection.outlook.com の DNS レコードに含まれる IP アドレスから送られてきていれば pass となります*6。
SPF アライメント pass の条件
SPF で検証するのはヘッダのエンベロープ From のドメインです。SPF アライメントは、エンベロープ From のドメインとヘッダ From のドメインが同一かを検証し、一致すれば pass となります。
Exchange Online の場合、エンベロープ From のドメインは Authentication-Results ヘッダの smtp.mailfrom フィールドで確認できます。
先ほどの Authentication-Results ヘッダで確認すると、エンベロープ From とヘッダ From は（一部マスクしていますが）一致していないので、このメールでは SPF アライメントの認証に失敗していることがわかります。
DKIM pass の条件
ドメインの DNS レコードに記載された公開鍵を使って、DKIM-Signature ヘッダに記録された電子署名を検証し、成功すれば pass となります。
DKIM アライメント pass の条件
DKIM-Signature の d フィールドに記載されたドメインとヘッダ From のドメインが同一かを検証し、一致すれば pass となります。
Exchange Online の場合、Authentication-Results ヘッダの header.d フィールドが DKIM 署名で識別するドメインとなっているため、ここで確認することもできます。
先ほどの Authentication-Results ヘッダで確認すると、header.d フィールドとヘッダ From は（一部マスクしていますが）一致していないので、このメールでは DKIM アライメントの認証に失敗していることがわかります。
メール転送における DMARC fail 対策 - ARC
冒頭でも述べたように、メーリングリスト等のメール転送サービスを利用すると DMARC fail となるケースは非常に多くなります。
この問題を解決するのが ARC (Authenticated Received Chain) です。ARC は、メール配送で経由しているメールサーバを、Received ヘッダではなく Authentication-Results ヘッダを使って辿れるようにすることで、認証の連鎖を確認できるようにする技術です。
ARC を活用することで MTA (Mail Transfer Agent) ごとの認証情報の変化を追跡することが可能となり、誤検知の防止やメール到達率の向上につながります。例えば、正規のメール受信時に DMARC の認証に失敗したとしても、ARC の認証結果を参照することで正規のメールと判断してメールクライアントの受信トレイに配送する、といったことが期待できます。
ARC ヘッダ
ARC の仕組みは、経由する MTA で以下の 3 つのヘッダを追加することで実現されます。
- ARC-Authentication-Results (AAR)
- ARC-Message-Signature (AMS)
- ARC-Seal (AS)
ARC ヘッダは MTA ごとに作成されることになるため、何番目に追加された ARC ヘッダかが i フィールドに記録されます。
また、i フィールドの値が同じ 3 つの ARC ヘッダを「ARC セット」と呼びます。
ARC-Authentication-Results (AAR)
各 MTA がメールを受け取った際の SPF, DKIM, DMARC の検証結果が記録されるヘッダです。
性質上 Authentication-Results ヘッダと似ていますが、特徴的なのは i=2 以上の AAR ヘッダには arc フィールドが記録されていることです。
これは後述する AS ヘッダの cv フィールドと同様に、1つ前の ARC-Seal が有効なものかどうかを検証した結果を示しています。
ARC-Message-Signature (AMS)
各 MTA において作成される電子署名で、DKIM 署名とほぼ同じ役割を持ちます。
AMS ヘッダは MTA ごとにメール本文の内容やヘッダが改変されていないことを保証します。
ARC-Seal (AS)
AMS が DKIM のようにメール本文やヘッダの完全性を保証するのに対し、AS ヘッダは ARC ヘッダそのものの完全性を保証する電子署名です。
署名作成時に存在する他のすべての ARC ヘッダに対して署名を行います。
AS ヘッダにおいて重要なのは cv フィールドであり、これは署名作成時点で認証の連鎖が有効であるかどうか（1 つ前の ARC セットヘッダに対する検証に成功しているか）を記録します。
ARC が有効に機能するには、i=2 以上のすべての AS ヘッダにおいて cv=pass となる必要があります。
Trusted ARC Sealer
Exchange Online には Trusted ARC Sealer という設定があります。これは、特定の ARC-Seal を作成したドメインを信頼することによって、その ARC-Seal に紐づく ARC-Authentication-Results の内容により DMARC の認証結果をオーバーライドすることができる仕組みです。
例えば、最新の ARC-Seal が i=3 だった場合、i=2 の ARC-Seal を作成したドメイン (AS ヘッダの d フィールドに記録されているドメイン) を信頼することによって、i=3 の ARC-Authentication-Results をメール認証時に参照するようになります。
ライセンス要件
Trusted ARC Sealer の構成には以下のいずれかのライセンスが必要です。
Exchange Online Protection は Exchange Online のメールボックスを持つすべての組織に適用されるため、Exchange Online を利用している場合は設定可能と考えて問題ありません。
代表的なところでは、以下のプランを利用している場合は設定可能です。
- Microsoft 365 Business Basic, Standard, Premium
- Office 365 E1, E3, E5
- Microsoft 365 E3, E5
設定方法
Trusted ARC Sealer の設定は管理ポータルまたは PowerShell からできます。
どちらの方法も上記リンクに掲載されていますが、今回は管理ポータルから設定してみます。
Microsoft Defender ポータルから、メールとコラボレーション > ポリシーとルール > 脅威ポリシー を選択します。
[ルール] セクションから メールの認証の設定 を選択します。
ARC タブで [編集] を選択することで ARC-Seal を信頼するドメインを追加することができます。
挙動確認
Exchange Online ではメール受信時に AS ヘッダがあると、メッセージの配信後に最新の AAR ヘッダをチェックします。
ARC をメール認証で利用するには、この AAR ヘッダにおいて arc=pass と oda=1 となっている必要があります。
ARC を使用して DMARC 認証結果をオーバーライドしたかどうかは Authentication-Results ヘッダで確認できます。
compauth=pass かつ reason=130 であれば、Trusted ARC Sealer により DMARC の認証に成功していることを示します。
なお、Trusted ARC Sealer は 3rd party が作成する ARC-Seal のドメインに対して設定するもののようで、Microsoft により作成される ARC-Seal のドメイン (microsoft.com) については設定しなくても信頼対象となっているようです。
また、検証したところ google.com ドメインについても明示的に設定しなくても信頼対象となっているようです。もしかしたら他にも暗黙的に信頼されているドメインがあるかもしれません。
おわりに
電子メールは IT 的にはかなり枯れた技術であるもの、その認証技術については直近の DMARC 対応で話題になったり、BIMI*7 のように比較的新しい認証規格が登場したりもしています。
まだまだビジネスでは欠かせない電子メールに関して、企業のセキュリティやブランド保護のためにこの記事が少しでも役に立てば幸いです。
*1:さらに詳しく知りたい方は DMARC、DKIM、SPFとは何ですか？ | Cloudflare などを読むとよいでしょう
*2:無料DMARCチェッカー＆検証ツール を利用して調べています
*3:実際には、ruf タグで指定した宛先に送られる Failure レポートは、悪用される可能性があるためかほぼ届きません。DMARC の仕様を定めている RFC 7489 では、セキュリティに関する考慮事項の中で Failure レポートの懸念点が挙げられています
*4:ヘッダ内の各フィールドの内容は スパム対策メッセージ ヘッダー - Microsoft Defender for Office 365 | Microsoft Learn で確認できます
*5:SPFチェッカー - 無料のSPFテストツール を利用して調べています
*6:このような動作を DNS のルックアップといい、SPF ではルックアップ回数が 10 回までという制限があります
*7:Brand Indicators for Message Identification
