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

DMARC Alignmentチェックとは？

SPFは、送信を許可したMTAのリストをDNSから取得し、送信元の正当性を検証します。
しかし、共用MTA環境ではSPFが突破されやすいという課題があります。
また仕様上の問題もあり、SPF Bypass攻撃では、SPFの認証で参照するドメインがHeaderFromとHELO/EHLOの2つを選べることを利用し、Header Fromとは異なるドメインから送信しつつ、HELO/EHLO検証でSPFで合格させる手法が用いられます。

一方、DKIMは、各MTAがメール本文に署名を付与して改竄防止を実現しますが、署名ドメイン（d=タグ）とHeader Fromの一致を検証しないため、攻撃者は自身のドメインで署名しながらHeader Fromを偽装することが可能です。

そこでDMARCは、SPFやDKIMの検証結果に加え、Fromアドレスと認証済み識別子との一致（Alignment）をチェックすることで、なりすましメールを検出します。
いずれかの検証が合格し、かつAlignmentが一致すれば、そのメールは正当と判断されます。

DMARC Alignment一致

Header Fromのドメインと、メールヘッダ内の検証済みドメインが一致している状態です。
(SPFベースのDMARC Alignmentチェックで使うEnvelope FromはSMTPコマンドで指定されるため、ユーザーが直接確認できることは少ないですが、ここでは説明の便宜上、Return-Pathとして表示される値を参照しています。)

DMARC Alignment不一致

Header Fromのドメインと、メールヘッダ内の検証済みドメインが一致しない状態です。

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

DMARCは単にSPFやDKIMの検証結果を利用するだけでなく、RFC7489 Section 6.6.2に基づいた処理プロセスを実施します。
以下の手順で、DKIMやSPFの検証結果がDMARC評価に反映されます。

1. RFC5322.Fromドメインをメールから抽出する。
2. DNSでDMARCポリシーレコードを問い合わせ、存在すれば評価を続行し、無ければ終了する。
3. DKIM署名検証チェックを実施し、各署名の"d="タグの値を取得する。
4. SPF検証チェックを実施し、使用されたドメイン名を記録する。
5. 認証済み識別子とRFC5322.Fromドメインの一致（Identifier Alignment）を確認する。
6. ポリシーに基づき、認証失敗メールの処理を決定する。

SPFまたはDKIMのいずれかが合格し、さらにAlignmentが一致すればメールは正当と判断されます。
転送メールでは、多くの場合、送信MTAが最初に送信したMTAと違うのでSPFが失敗しますが、DKIMが合格すれば問題ありません。
転送メール検証の難点には、ARC仕様で対応できます。

DKIMを基準としたDMARC Alignmentチェック

メールヘッダーのFromに記載されたドメインと、DKIM署名内のd=タグに記載されたドメインが一致する署名が1つ以上存在するかどうかを検証します。

SPFを基準としたDMARC Alignmentチェック

メールヘッダーのFromに記載されたドメインと、SMTPセッション中に指定されるEnvelope From（通常、Return-Pathヘッダーに転記される）のドメインが一致するかどうかを検証します。
(Envelope FromはSMTPコマンドで指定されるため、ユーザーが直接確認できることは少ないですが、ここでは説明の便宜上、Return-Pathとして表示される値を参照しています。)

SPFベースのDMARC AlignmentチェックにおけるEnvelope FromとReturn-Pathの関係

SPF検証では、SMTPセッション中に送信者が提示する情報として、HELO/EHLOで提示されたホスト名や、MAIL FROMコマンドで指定されるEnvelope Fromのドメインが利用されます。
DMARCのSPF Alignmentチェックでは、SPF認証に使用されたIdentifier、通常はMAIL FROMに対応するEnvelope Fromのドメインと、メールヘッダーのFromのドメインとの整合性（Alignment）が評価されます。
なお、Return-Pathは通常、受信サーバーでEnvelope Fromの値に基づいて生成されるため、多くの場合、実際のEnvelope Fromと同一のドメイン情報が記録されます。しかし、転送処理でのSRSや受信サーバー独自の処理により、これらの値が異なるケースも存在します。

Envelope FromはSMTPセッション中にMAIL FROMコマンドで指定される送信元アドレスであり、バウンス通知の宛先として利用されます。
一方、Return-Pathは通常、受信サーバーがEnvelope Fromの値に基づいて自動生成するヘッダーで、実際のEnvelope Fromの情報を反映しています。
そのため、Return-Pathを確認することで、間接的にEnvelope Fromの値を把握できる場合が多いですが、SRSなどによる転送処理が行われると、Return-Pathのドメインが変更されることがあります。

また、MAIL FROMが空の場合、SPF検証ではHELO/EHLO情報から合成されたアドレスが使用され、通常はReturn-Pathも空となるため、バウンスメールなど特定のケースでこの挙動が見受けられます。

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

従来、SPFやDKIMでは受信側メールサーバが検証結果に基づいてメールの処理（受信、隔離、拒否）を決定していました。
しかしDMARCでは、ドメイン所有者がメール処理の方法を明示的に指定できます。

DMARCはMTAやMDAと連携し、SPF・DKIM検証結果に基づいて以下の処理を指示します。

p=none

認証失敗や不適合メールに対して既存のメール処理を変更せず、フィードバックのみを行います。

p=quarantine

認証失敗メールを隔離し、迷惑メールフォルダへ振り分けるよう指示します。

p=reject

認証失敗メールの受信自体を拒否するよう指示します。

これらのポリシーは、DNSのTXTレコードとして公開され、受信側サーバが参照します。

目標とすべきポリシーはreject

最終的に設定目標とすべきポリシーはp=rejectです。
p=rejectにすると、SMTPコネクションを張っている時点で、DMARCに適合していないと、コネクションを切断されてしまいます。
結果として、迷惑メールボックスにすら入りません。

p=quarantineをまずは適用することが推奨されているものの、p=quarantineでは、迷惑メールボックスに入ったことを送信側が検知できません。
そこで、弊社では、最初からp=rejectにすることをお勧めしています。
そうすれば、送信時にDMARCで合格できなくて送信に失敗したことが即座に判明するからです。

また、p=quarantineでは、なりすましメールが減らないことも、過去の分析データから判明しています。
p=rejectにすると、大体2～3週間ほどで、DMARCのコンプライアンス率は99%を超えます。
なりすましメールを送っている攻撃者も、送っても無駄なドメインについては、送信しなくなるからです。

攻撃者がp=rejectにしたドメインについて、引き続き攻撃する場合には、全く関係の無いドメインを使って、SPF/DKIM/DMARCを合格させてメールを送ってきます。
メールクライアントの多くがアドレスを表示せず、名前だけを表示する点を利用して、ヘッダーFromのアドレスも関係のないドメインを使い、なりすましメールを送ります。
これについては、DMARCでは防御できないため、BIMIを実装することで視覚的に防御することになります。

p=noneについての補足

p=noneは「全てのメールをそのまま受信する」指定ではなく、DMARC未設定時の従来の処理を変更しないことを示します。
従って、SPF、DKIM単体検証の時のように、受信MTA側の処理判断に従います。
詳細はRFC7489をご参照ください。

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"のポリシーはメール処理を変更すべきではありません。

尚、現在、p=noneのドメイン名を利用して、なりすましメールを送る攻撃が多発しているので、できるだけ早期にp=rejectにすることをお勧めします。

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

ローカルポリシーは、受信側組織が独自に設定することで、特定の送信者ドメインに対してDMARCポリシーを上書きできます。
これにより、信頼できる送信者のポリシーが不十分な場合や、特定の状況に応じた緩和策が適用可能です。

特定送信者への対応

信頼できる送信者が適切なDMARC設定を行っていない場合、ローカルポリシーで独自の設定を適用できます。

緩やかなポリシーの適用

厳格すぎる送信者のDMARCポリシーに対し、より緩やかなポリシーを設定することで誤拒否を防止できます。

部門やユーザ別のポリシー

組織内の特定部門やユーザに対して、個別のDMARCポリシーを適用することが可能です。

ARCヘッダの参照

一部メールシステム（例：Gmail）は、ARCヘッダを参照してローカルポリシーを適用しています。

ローカルポリシーを設定する際は、システムの互換性、適切な設定、定期的なメンテナンス、送信者との連携に十分注意してください。

3. DMARCレポート

DMARCレポートは、自社ドメイン名義で受信されたメールの統計情報を、受信MTAから定期的（通常1日1回）に送信される監査レポートです。
ここで重要なのは、送信されたメールではなく「受信されたメール」の情報である点です。
なりすましメールは自社のメールサーバから送信されるケースが少ないため、受信側のレポートがセキュリティ監視に非常に有用です。

RUAレポート・RUFレポート

DMARCレポートには、以下の2種類があります。

RUA

"Reporting URI(s) for aggregate data" の略。
受信メールのSPF、DKIM、DMARCの検証結果の統計情報がXML形式で送信されます。
メールの詳細データは含まれず、個人情報も一切入っていません。

RUF

"Reporting URI(s) for failure data" の略。
認証に失敗したメールのヘッダ情報がXML形式で送信されます。
宛先、件名、Fromアドレスなどの詳細が含まれます。
現在、殆どのメール配信プラットフォームが送って来ないです。

RUAレポート確認の重要性

p=reject設定後に「これで安全」と考えがちですが、RUAレポートを継続的に確認することで以下の効果が期待できます。

継続的な監視と改善

SPF/DKIM/DMARCは、DNSに大きく依存しているため、DNSのレスポンスタイム次第でTemperrorが発生します。
また、サードパーティのSPFやDKIMの設定の不具合が、自社ドメインのメールの認証を大きく左右します。
そこで、詳細な検証結果をもとに、システム運用の改善や設定の見直しが可能となります。

新たな脅威への対応

攻撃手法の変化に応じた迅速な対策が可能になります。

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

システムの設定ミスや不正アクセスの兆候を早期に把握できます。

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

組織のセキュリティ方針に沿った運用が維持されているか確認できます。

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

定量的なデータとして、コンプライアンス報告の基礎資料となります。

サイバーデューデリジェンス

M&Aなどの際、セキュリティリスク評価の根拠データとして利用できます。

メール配信率の最適化

配信率低下の原因を特定し、対策を講じるための重要なデータとなります。

このように、DMARCの運用にはp=reject設定後もRUAレポートの継続的な確認が不可欠です。

4. DMARCの構文

DMARCは、前述の機能を実現するために、DNSにTXTレコードとして公開されるポリシーです。
ポリシーは以下のタグと値のペアで定義されます。

v=DMARC1

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

p=none|quarantine|reject

ポリシーを示します。
noneはモニタリングのみ、quarantineは隔離、rejectは拒否を意味します。

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

サブドメインに適用するポリシーを指定します。指定がない場合、APEXドメインのポリシーが適用されます。

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

アグリゲートレポート送信用のメールアドレスを指定します。通常、24時間ごとに送信されます。

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

フォレンジックレポート送信用のメールアドレスを指定します。認証失敗メールの詳細情報が含まれます。

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

DMARCポリシーを適用するメールトラフィックの割合を示します。
例：pct=50なら全体の50%のメールに適用（指定がない場合は100%）。

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

DKIMのアラインメントモードを指定します。
rはリラックス（サブドメインも含む）、sは厳格（一致のみ）です（デフォルトはリラックス）。

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

SPFのアラインメントモードを指定します。
rはリラックス、sは厳格です（デフォルトはリラックス）。

例えば、以下のような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;

この設定は、APEXドメインのメールに対しては認証失敗時に拒否、サブドメインでは隔離、レポートは指定アドレスへ送信し、DKIMおよびSPFは厳格な一致を要求、かつ全メールに適用されることを示します。

5. DMARCの限界

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

認証ステータスの確認

メールクライアントがDMARC検証ステータスを明示的に表示しない場合、詳細はメールヘッダの確認が必要です。

自社管理外のドメインからの送信によるなりすまし

DMARCは自社で管理しているドメインについての認証を行います。
攻撃者が自社で管理していないドメインを使い、適切なSPF・DKIM・DMARC設定を行いメールを送信した場合、DMARC検証は合格してしまいます。
これは、多くのメールソフトで、メールの送信元の表示で名前だけ表示して、メールアドレスを表示しない仕様を利用した攻撃になります。

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

DMARCにも限界があるため、追加の信頼性向上策として、BIMI (Brand Indicators for Message Identification) が登場しました。