MailData

DomainKeys Identified Mail

DMARC

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

DMARCディーマーク(Domain-based Message Authentication, Reporting and Conformance)は、SPFとDKIMという既存のメール認証システムを拡張し、ドメイン所有者がなりすましメールの送信を防止するための仕様です。
これにより、メールの認証と送信ポリシーの適用が強化され、ドメイン所有者がセキュリティを向上させることができます。
DKIMの仕様は、2015年に公開されたRFC7489に記載されています。

DMARCには、3つの大きな役割があります。

  1. DMARCアライメント
  2. 送信側ドメイン所有者が処理を決める
  3. メールの監査に必要なレポートを受信する

1. DMARCアライメント

以前に説明したように、DKIMには限界があり、SPFとDKIMが設定されていても、なりすましメールを送信することが可能です。
なりすましメールを送信する側は、自分のドメインでSPFとDKIMを設定し、Fromアドレスを詐称したいドメインに変更するだけで済みます。
Fromアドレスは、メールソフトウェアでも簡単に書き換えることができます。

DMARCは、Fromアドレスが送信元ドメインと一致しているかどうかを検証し、Fromアドレスの詐称をチェックします。

この仕組みにより、Fromアドレスを詐称したメールを検出してブロックすることが可能になります。

DMARCアライメント

Envelope FromとReturn-Pathの違い

Return-Pathと似ているものにEnvelope Fromがあります。
厳密には、この2つは異なります。

Envelope From
SMTPプロトコルにおいてメールの送信元を識別するために使用されるアドレスです。
これは、メールの配送プロセス中に使用され、通常は受信者には表示されません。
送信プロセスで使うことを目的としています。
Envelope Fromは、2008年に公開されたRFC5321に記載されています。
Return-Path
メールヘッダーに記載されるEnvelope Fromの値が設定されたアドレスです。
こちらは、受信者がヘッダ情報を確認すると記載されています。
受信プロセスで使うことを目的としています。
Return-Pathは、2008年に公開されたRFC5322に記載されています。

要するに、エンベロープFromとReturn-Pathは、同じ目的で使用されることが一般的です。
エンベロープFromはSMTPプロトコルの一部であり、Return-Pathはメールヘッダーに記載される点で異なります。
両者は通常、同じアドレスを指します。

SMTPでのEnvelope Fromと、ヘッダ情報のReturn-Pathが分離することで、以下のような用途に対応が可能となります。

DMARCアライメントで利用するのは、Envelope Fromではなく、Return-Pathです。

2. 送信側ドメイン所有者が処理を決める

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

DMARCは、MTAやMDAと連動し、SPFやDKIMの機構と連動して動作します。
SPFやDKIMの認証方法のいずれも合格しなかった場合、DMARCを設定していないと、メール受信側が、合格しなかったメールをどうするか決めます。
DMARCを設定すると、送信側ドメインが、受信先のメールシステムに対して、合格しなかったメールの処理を指示する事が可能になります。

DMARCの検査処理
p=none
認証に失敗したメールに対して、何もしないよう受信サーバに指示。違反があった場合はDMARCレコードのmailto:にレポートを送信。
p=quarantine
認証に失敗したメールを隔離するよう受信サーバに指示。迷惑メールフォルダに振り分けられる。
p=reject
認証に失敗したメールは無条件に拒否するよう受信サーバに指示。100%認証に成功したメールのみが受信トレイに到達し、それ以外は削除。

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

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

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

特定の送信者ドメインに対する対応
信頼できる送信者ドメインがDMARCポリシーを適切に設定していない場合、ローカルポリシーを使用して、そのドメインからのメールに対する独自のDMARCポリシーを適用することができます。
緩やかなポリシーの適用
送信者ドメインのDMARCポリシーが厳格すぎると判断される場合、ローカルポリシーを使用して、より緩やかなポリシーを適用することができます。
これにより、正当なメールが誤って拒否されるリスクを軽減できます。
組織内の特定の部門やユーザに対するポリシー
組織内の特定の部門やユーザに対して、独自のDMARCポリシーを適用する必要がある場合、ローカルポリシーを使用して個別に設定できます。
ARCヘッダの参照
受信者側の組織は、ローカルポリシーを使用して、ARCヘッダを参照し、DMARC検証プロセスにどのように影響を与えるかを決定できます。
このようなローカルポリシーの適用により、組織はDMARCの効果を最大限に活用し、転送されたメールに対しても信頼性を確保することができます。
Gmailでは、ローカルポリシーを利用してARCヘッダを参照しています。

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

互換性
ローカルポリシーは、すべての受信者側のメールシステムでサポートされているわけではありません。
そのため、実装時には、システムの互換性を確認してください。
適切な設定
ローカルポリシーは、DMARCポリシーを上書きするため、適切に設定されていないと、誤った結果を生むことがあります。
そのため、ポリシーの設定には十分注意してください。
メンテナンス
ローカルポリシーは、組織内で独自に管理されるため、定期的なメンテナンスが必要です。
変更や更新が必要な場合は、適切にローカルポリシーを更新し、効果的なDMARCポリシーの適用を維持してください。
送信者とのコミュニケーション
ローカルポリシーを適用する前に、信頼できる送信者ドメインとコミュニケーションを取り、DMARCポリシーの問題や不適切な設定について話し合ってください。
可能であれば、送信者が自身のDMARCポリシーを適切に設定することが望ましいです。

3. メールの監査に必要なレポートを受信する

DMARCには、自社のドメインのアドレスでどのくらいの通数のメールが受信されているかを確認するためのレポート機能があります。
送信されたメールではなく、受信されたメールであることに注目して下さい。
これによって、勝手になりすましメールを送られても、受信側からレポートされるので、把握が可能になります。

RUA
"Reporting URI(s) for aggregate data"の略。
メール受信側から、受信したメールについて、SPF、DKIM、DMARC Alignmentに合格したかどうかのデータがXMLで送られる。
RUF
"Reporting URI(s) for failure data"の略。
メール受信側から、受信したメールについて、SPF、DKIM、DMARC Alignmentに不合格だったメールのヘッダ情報がXMLで送られる。
現在、対応しているプラットフォームが少なく、Microsoftからは送られてくるが、Googleからは送って来ない。

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ポリシーは以下のようになります。

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

DMARCの限界

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

認証ステータスの確認

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

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

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

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

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