DMARC

SPFとDKIMの限界を補完し、更になりすましメールを防止する

DMARCディーマーク(Domain-based Message Authentication, Reporting and Conformance)は、SPFとDKIMの弱点を補完しつつ、Fromアドレス詐称検出、ドメイン所有者からの処理の明示的指示、DMARCレポート受信、以上3つの機能を提供します。
これにより、メールの認証と送信ポリシーの適用が強化され、ドメイン所有者がセキュリティを向上させることができます。
DKIMの仕様は、2015年に公開されたRFC7489に記載されています。

1. DMARC Alignment(Fromアドレス詐称検出)

DMARC Alignmentの一致・不一致とは？

DKIMは、異なるドメインからのFromアドレス詐称を許してしまうという限界があります。
これは、DKIMの鍵のドメイン名（d=タグ）とFromアドレスが一致しているかどうかを検証する仕組みが存在しないためです。
詐称者は、自身のドメインでSPFとDKIMを設定し、Fromアドレスを詐称したいドメインに変更することで、なりすましメールを送ることが可能です。

そこで、DMARCは、Fromアドレスの詐称を検出するために、SPFやDKIMのテストが合格したら、Fromアドレスの真正性を確認するためにAlignmentチェックを行います。

DMARC Alignmentチェックは、SPFとDKIMを基準にしたものが双方行われます。
SPFについては、Return-Pathに入っているドメイン名、DKIMの場合はd=に入っているドメイン名と、Fromアドレスのドメイン名が一致するかどうかを確認します。

DMARC Alignment一致

Fromアドレスのドメイン名と、ヘッダ内のドメイン名が一致の状態。

DMARC Alignment不一致

Fromアドレスのドメイン名と、ヘッダ内のドメイン名が不一致の状態。

SPF、DKIM、それぞれを基準としたDMARC Alignmentチェック

DMARC Alignmentチェックは、SPF・DKIM、どちらかが合格していればOKです。
これは、SPFの場合、転送メールの場合は、SPFが不合格になります。
そこで片側だけが合格すればOKとなれば、転送メールであっても、メールの内容を変更してない場合はDKIMが合格し、Alignmentも一致するというわけです。

転送メールについては、DMARC Alignmentチェックが合格しない場合があるため、ARCという仕様で担保します。

SPFを基準にしたFromアドレス詐称検出

SPFを基準にしたFromアドレス詐称検出では、私たちがメールを読む際に目にするFromアドレス「Header From」と、メールヘッダ内のReturn-Pathを照合します。

「Return-Path」を「Envelope From」と同一と見做す人もいますが、厳密には異なります。
Return-Pathはメールヘッダに記載されますが、Envelope FromはSMTPプロトコルの一部です。
通常、両者は同じアドレスを指しますが、SMTPでのEnvelope Fromとヘッダ情報のReturn-Pathが分離することで、BCCの送信、メールの転送、代理送信など、多くの用途に対応が可能となります。

DKIMを基準にしたFromアドレス詐称検出

DKIMを基準にしたFromアドレス詐称検出では、私たちがメールを読む際に目にするFromアドレス「Header From」と、メールヘッダ内のDKIMの鍵のd=タグに記載されている鍵の所有者のドメイン名を照合します。

DKIMには、第三者認証という仕組みがあり、違うドメインでの秘密鍵・公開鍵での署名検証も対応しています。
その仕組みを悪用して、Fromアドレスを詐称してなりすましメールを送信される点が、DKIMの課題でした。
DMARCを運用する場合には、DKIMの鍵のドメインを、Fromアドレスと合致させる必要があります。

2. ドメイン所有者からの処理の明示的指示

SPFやDKIMは、受信側メールサーバが、試験の結果を以って、受け取るか、迷惑メールフォルダに入れるか、拒否するかを決めていました。
それに対して、DMARCは、ドメイン所有者が処理を指定できます。
この点が画期的な仕様です。

DMARCは、MTAやMDAと連動し、SPFやDKIMの機構と連動して動作します。
SPFかDKIMで不合格、また合格してもDMARC Alignment Checkで不適合のメールについて、隔離するか排除を受信メールサーバに指示できます。
言い方を替えると、SPFやDKIMの認証方法のいずれかに合格し、且つ、DMARC Alignment Checkで適合したメールはドメイン所有者の指示に従って受信箱に入ります。

p=none

認証失敗もしくは不適合のメールに対して、ドメイン所有者としては、受信側のメール処理に変更を加えない旨を通知。

p=quarantine

認証失敗もしくは不適合のメールを隔離するように受信サーバに指示。迷惑メールフォルダに振り分けられる。

p=reject

認証失敗もしくは不適合のメールは受信しないように受信サーバに指示。

これらのポリシーは、テキストのTXTレコードとしてDNSに登録し、公開します。

p=noneについての誤解

p=noneは、そのまま受信する、という意味ではありません。
DMARCが設定されていない場合は、SPFやDKIMでの判定後の処理は受信メールサーバ側で行います。
従来のSPFやDKIMの処理に従う、それを変えないという意味です。

RFC7489のnoneの説明の箇所では、以下のように定められています。

To enable Domain Owners to receive DMARC feedback without impacting existing mail processing, discovered policies of "p=none" SHOULD NOT modify existing mail disposition processing.

ドメイン所有者が既存のメール処理に影響を与えることなくDMARCのフィードバックを受け取れるようにするために、発見された "p=none "のポリシーでは、既存のメール処理に変更を加えるべきではない。

ローカルポリシーによる上書き

ローカルポリシーは、受信者側のメールシステムが独自に設定する、DMARCポリシーを上書きするためのポリシーです。
これにより、特定の送信者ドメインに対して、組織独自のDMARCポリシーを適用することができます。
以下は、ローカルポリシーを使用する場合の例です。

特定の送信者ドメインに対する対応

信頼できる送信者ドメインがDMARCポリシーを適切に設定していない場合、ローカルポリシーを使用して、そのドメインからのメールに対する独自のDMARCポリシーを適用することができます。

緩やかなポリシーの適用

送信者ドメインのDMARCポリシーが厳格すぎると判断される場合、ローカルポリシーを使用して、より緩やかなポリシーを適用することができます。
これにより、正当なメールが誤って拒否されるリスクを軽減できます。

組織内の特定の部門やユーザに対するポリシー

組織内の特定の部門やユーザに対して、独自のDMARCポリシーを適用する必要がある場合、ローカルポリシーを使用して個別に設定できます。

ARCヘッダの参照

受信者側の組織は、ローカルポリシーを使用して、ARCヘッダを参照し、DMARC検証プロセスにどのように影響を与えるかを決定できます。
このようなローカルポリシーの適用により、組織はDMARCの効果を最大限に活用し、転送されたメールに対しても信頼性を確保することができます。
Gmailでは、ローカルポリシーを利用してARCヘッダを参照しています。

ローカルポリシーを使用する際には、以下の注意点を考慮する必要があります。

互換性

ローカルポリシーは、すべての受信者側のメールシステムでサポートされているわけではありません。
そのため、実装時には、システムの互換性を確認してください。

適切な設定

ローカルポリシーは、DMARCポリシーを上書きするため、適切に設定されていないと、誤った結果を生むことがあります。
そのため、ポリシーの設定には十分注意してください。

メンテナンス

ローカルポリシーは、組織内で独自に管理されるため、定期的なメンテナンスが必要です。
変更や更新が必要な場合は、適切にローカルポリシーを更新し、効果的なDMARCポリシーの適用を維持してください。

送信者とのコミュニケーション

ローカルポリシーを適用する前に、信頼できる送信者ドメインとコミュニケーションを取り、DMARCポリシーの問題や不適切な設定について話し合ってください。
可能であれば、送信者が自身のDMARCポリシーを適切に設定することが望ましいです。

3. DMARCレポート

DMARCレポートとは、自社のドメイン名義アドレスで、どのくらいの通数のメールが受信されているかを監査するためのレポートです。
これは、受信MTA側から、1日に1回送られてきます。
送信されたメールではなく、受信されたメールであることに注目して下さい。

なりすましメールは、自社のメールサーバなどから送信されることは少なく、自社のメールサーバをチェックするだけでは把握できません。
受信側からレポートが送られてくるので、把握が可能になります。

RUAレポート・RUFレポート

DMARCレポートには、RUAレポートとRUFレポートの二つがあります。

DMARC運用の本格化：p=rejectやquarantine設定後にRUAレポートを継続的に確認する理由

多くの組織がDMARCのp=rejectやquarantineに設定した後、「これで安全」と考え、RUAレポートを無視する傾向があります。
しかし、実際にはDMARCの運用において、RUAレポートを継続的に受信・確認することが重要です。

継続的な監視と改善

RUAレポートは、DMARCの検証結果を含む詳細な情報を提供します。
これにより、組織は自身のメールシステムの認証状況や、不正なメールの送信元を特定することができます。
定期的にRUAレポートを確認することで、DMARCポリシーの適用状況を監視し、改善の余地がある場合には適切な対策を講じることができます。

新たな脅威への対応

インターネットの脅威は日々進化しており、攻撃者は新たな手口でなりすましやスパムを送信することがあります。
RUAレポートを定期的に確認することで、新たな脅威に対応し、組織のメール環境をより安全に保つことができます。

誤設定や不正アクセスの検出

RUAレポートを確認することで、組織内のメールシステムや送信ドメインに誤設定がないか、または不正アクセスがあったかどうかを把握することができます。
これにより、問題が発覚された場合に迅速に対処し、メールの信頼性を維持することができます。

セキュリティポリシーの遵守

多くの組織は、情報セキュリティポリシーを定めており、メールのセキュリティを向上させるための方針や手順が規定されています。
RUAレポートの定期的な確認は、組織がセキュリティポリシーを遵守し、情報セキュリティの向上に努めていることを示す一助となります。

コンプライアンス・レポートの元データ

コンプライアンス担当者がコンプライアンス・レポートを作成する際に、RUAレポートの分析結果があると定量的データとして役立ちます。

サイバーデューデリジェンス（査定）

M&A（合併・買収）に乗り出す前に情報漏洩などの可能性を調べる「サイバーデューデリジェンス（査定）」が最近注目されています。
買収先が抱えるリスクの大きさを金額で評価する際に、RUAレポートによる継続的監査が行われていない場合に、サイバー攻撃を受けるリスクが高いと見なされる可能性があります。

メール配信率の最適化

DMARCのp=rejectやquarantine設定を行った後も、RUAレポートを確認することで、メールの配信率が最適化されているかどうかを評価できます。
配信率が低下する原因を特定し、適切な対策を講じることで、メールの配信率を向上させることができます。

DMARCの本格的な運用には、p=rejectやquarantine設定後もRUAレポートの継続的な確認が不可欠です。これにより、組織はメール環境の安全性や信頼性を維持し、新たな脅威への対応やセキュリティポリシーの遵守など、さまざまな面で最適な運用が可能となります。

DMARCの構文

以上の3つの機能について、DMARCのポリシーを定めて、DNSにTXTレコードとして追加します。
受信側のメールサーバは、このTXTレコードを参照し、が送信元ドメインの認証結果を評価するために使用します。
DMARCポリシーの構文は、以下のようなタグと値のペアで構成されています。

v=DMARC1

DMARCバージョンを示します。
現在のバージョンは"DMARC1"です。

p=none|quarantine|reject

DMARCポリシーを示します。
noneはモニタリングモードで、ポリシー違反を報告するだけで何も行動を起こしません。
quarantineは、ポリシー違反メールを受信者のスパムフォルダに配置するように求めます。
rejectは、ポリシー違反メールを拒否するように求めます。

sp=none|quarantine|reject（オプション）

サブドメインに適用されるDMARCポリシーを示します。
このタグがない場合、APEXドメインのポリシー（pタグ）が適用されます。

rua=mailto:address（オプション）

アグリゲートリポートを送信するメールアドレスを指定します。
これらのリポートは、一定期間（通常24時間ごと）に送信され、ドメイン全体の認証統計を含みます。

ruf=mailto:address（オプション）

フォレンジックリポートを送信するメールアドレスを指定します。
これらのリポートは、DMARCポリシー違反の個々のメールに対して送信されます。

pct=0-100（オプション）

DMARCポリシーを適用するメールトラフィックの割合を示します。
例えば、pct=50は、受信者のメールサーバに対して、送信元であるドメインからのメール全部の内50％のメールを標本抽出して適用するよう求めます。
このタグがない場合、デフォルト値は100％です。

adkim=r|s（オプション）

DKIMアラインメントモードを示します。
rはリラックスモードで、サブドメインも含めたドメイン全体を照合します。
sは厳格モードで、厳密に送信ドメインと照合します。
デフォルトはリラックスモード（r）です。

aspf=r|s（オプション）

SPFアラインメントモードを示します。
rはリラックスモードで、サブドメインも含めたドメイン全体を照合します。
sは厳格モードで、厳密に送信ドメインと照合します。
デフォルトはリラックスモード（r）です。

これらのタグを組み合わせて、DMARCポリシーを定義することができます。
例えば、次のようなDMARCレコードが考えられます。

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc_agg@example.com; ruf=mailto:dmarc_for@example.com; adkim=s; aspf=s; pct=100;

この例では、DMARCポリシーは以下のようになります。

• APEXドメインのメールは、DMARC検証に失敗した場合、拒否（reject）されます。
• サブドメインのメールは、DMARC検証に失敗した場合、隔離（quarantine）されます。
• アグリゲートリポートは、dmarc_agg@example.comに送信されます。
• フォレンジックリポートは、dmarc_for@example.comに送信されます。
• DKIMとSPFのアラインメントモードは、厳格モード（s）です。
• メールトラフィックの100％に対して、DMARCポリシーが適用されます。

これらの設定を適切に組み合わせることで、ドメイン所有者は、なりすましやフィッシング攻撃を防ぐために、DMARCポリシーをカスタマイズすることができます。

DMARCの限界

DMARCはメールのセキュリティを向上させるための有益な技術ですが、いくつかの限界が存在します。

認証ステータスの確認

ユーザがDMARCの検証に合格しているかどうかを確認するには、メールクライアントが明示的にそのステータスを表示する機能を実装していない限り、メールのヘッダ情報を確認する必要があります。

類似ドメイン名によるなりすまし

DMARCは、送信元ドメインの認証を行いますが、攻撃者が類似したドメイン名を利用してなりすましメールを送信する場合には、DMARCの効果は限定的です。
例えば、攻撃者が正規のドメイン名に似せた別のドメイン名を登録し、SPFとDKIMを適切に設定した上でメールを送信すると、DMARCはそのメールを正規のものとして認証してしまうことがあります。
これにより、受信者はなりすましメールに気づかず、誤って開いてしまう可能性があります。

DMARCの限界を超えるためのBIMI

以上のように、SPF、DKIM、DMARCの3点セットの設定では、メールセキュリティの限界があります。
そこでBIMIが登場します。