DMARCの誤検知の原因と修正方法および防止ガイド
著者: Ahona Rudra
翻訳: 古川 綾乃
この記事はPowerDMARCのブログ記事 DMARC False Positives: Causes, Fixes, and Prevention Guideの翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。
DMARCは、SPFおよびDKIMを基盤とするメール認証プロトコルです。
認証に失敗したメールをどのように扱うかを、ドメイン所有者が受信側に指示できる仕組みです。
主なDMARCポリシーには、none、quarantine、rejectがあります。
これにより、認証に失敗したメールを通常どおり配信するか、迷惑メールとして隔離するか、あるいは受信を拒否するかを制御できます。
DMARCの誤検知とは、本来は正規のメールであるにもかかわらず、認証結果が「fail」と判定されてしまう現象を指します。
これは、SPF、DKIM、またはDMARCの設定不備や誤構成が原因となることがあります。
主な原因としては、ドメインの不一致、DKIM署名の欠落、十分な検証を行わずに厳格なポリシーを適用してしまうことなどが挙げられます。
こうした不備により、業務メールが届かなかったり、迷惑メールに振り分けられたりすることがあります。
その結果、業務の遂行や円滑なコミュニケーション、さらにはブランドイメージにも重大な影響を及ぼすおそれがあります。
主なポイント
- DMARCの誤検知とは、誤構成やアライメントの問題により、正当なメールがDMARCチェックに失敗することを指します。
- これらの問題は、メールの到達率の低下や、評判の悪化、投資対効果（ROI）の悪化などにつながる可能性があります。
- 一般的な原因としては、SPFやDKIMの不整合、メール転送、期限切れのDKIMキー、許可されていない第三者送信者の存在などが挙げられます。
- 誤検知は、DMARCの失敗レポートやバウンスログの増加、社内外のメールが想定外に拒否されるといった形で確認されることがあります。
- DMARCポリシーの継続的な監視と適切な調整、第三者サービスの正式な承認、メール転送への適切な対応を行うことで、誤検知の発生を大幅に減らすことができます。
DMARCの誤検知はなぜ発生するのか？
DMARCの誤検知は、さまざまな要因によって発生する可能性があります。
- DNSレコードの不適切な管理
- DNSレコードは、受信側がSPF・DKIM・DMARC認証を検証するための情報を提供し、これらを参照してDMARCは送信元ドメインの正当性を確認します。
SPF・DKIM・DMARCのDNSレコードを適切に管理することで、受信サーバはメールを正しく認証できます。
一方で、DMARCレコードが設定されていない場合は受信側がDMARCポリシーを適用できず、その結果ドメインはなりすまし攻撃に対して無防備な状態になります。 - DNSレコードの不適切な管理
- DNSレコードは、受信側がSPF・DKIM・DMARCの認証結果を検証するための情報を提供し、これらの情報をもとにDMARCは送信元が正規であるかどうかを判断します。
SPF・DKIM・DMARCのDNSレコードを適切に管理することで、受信サーバはメールを正しく認証できるようになります。
一方で、DMARCレコードが設定されていない場合は受信側でポリシーを適用できず、ドメインはなりすまし攻撃に対して十分な防御ができない状態となります。 - SPF／DKIMのアライメント不整合
- DMARCでは、「From」ヘッダーのドメインが、SPFおよびDKIM認証で使用されるドメインと一致している必要があります。
アライメントポリシーを厳格に設定しすぎると、これらのドメインが一致しない場合に、正当なメールであっても認証に失敗することがあります。
具体的には、SPFで認証されたドメイン（通常はReturn-Pathに基づく）や、DKIMの署名ドメインが「From」アドレスと一致しない場合、DMARCの失敗につながる可能性があります。 - メール転送
- 転送されたメールは、送信者のSPFレコードに含まれていない中継サーバを経由することが多く、その結果SPFが失敗する場合があります。
転送はSPFに影響を与えやすい一方で、転送先やメーリングリスト側で本文やヘッダーが変更されない限り、DKIM署名は通常そのまま維持されます。
しかし、SPFまたはDKIMのいずれかが正しく機能していない場合、DMARC認証が失敗する可能性があります。 - メーリングリスト
- メーリングリストでは、フッターやヘッダーの追加などによりメール本文が変更されたり、場合によっては「From」アドレスが書き換えられたりすることがあります。
これらの変更によりDKIM署名が無効になったり、バウンスアドレスが元の送信者と異なることでSPFの不整合が発生したりします。
その結果、DMARC認証が失敗することがあります。 - 期限切れまたはローテーションされたDKIMキー
- DKIMキー自体が自動的に期限切れになることはありませんが、セキュリティ対策として定期的なローテーションが推奨されます。
一部のDKIM署名には、有効期限を示す「x=」タグが含まれる場合がありますが、これは任意設定であり、必須ではありません。
キーをローテーションする際は、古いキーで署名されたメールがすべて配信されるまで公開鍵を維持するなど、慎重な運用が求められます。 - 動的IPアドレスの使用
- DMARCは、固定された安定的なIPアドレス環境のほうが適切に機能します。
動的IPアドレスは頻繁に変更されるため、送信元の信頼性評価が安定せず、配信に影響を及ぼすことがあります。
また、動的IPアドレスは、メールレピュテーションサービスによって評価が不安定になりやすく、ブロック対象になりやすい傾向があります。
さらに、逆引きDNS（PTRレコード）が一貫していない場合もあり、これが認証や配信トラブルの要因になることがあります。 - 許可されていない第三者送信者
- ドメインのSPFまたはDKIMレコードに含まれていない第三者サービスから送信されたメールは、認証に失敗する可能性が高くなります。
その結果、DMARCが失敗し、正規の業務メールであっても誤検知が発生することがあります。
たとえ正規の送信であっても、DNS上で正式に認可されていなければ認証は通りません。
DMARCの誤検知を検出する方法
以下は、DMARCの誤検知を検出する主な方法です。
- DMARC集計レポート（RUA）
- DMARC集計（RUA）レポートを確認することで、メール通信におけるpass／failの傾向を把握し、継続的な監視が可能になります。
XML形式のレポートは、DMARCレコードに指定したアドレス宛てに通常は日次で送信され、SPFおよびDKIMの認証結果の概要が含まれています。
これにより失敗の異常な増加を検出でき、想定外の増加は誤検知が発生している可能性を示す重要な兆候となります。 - フォレンジックレポート（RUF）
- DMARCフォレンジック（RUF）レポートを有効にすると、DMARCチェックに失敗したメールに関する詳細な診断情報を受け取ることができます。
レポートにはメッセージ単位の情報が含まれており、送信元情報、件名、認証結果などが確認できます。
これにより、どの正規メールが迷惑メール扱いになっているのか、あるいは拒否されているのかを特定しやすくなります。 - メールのバウンスログ
- メールサーバのバウンスログや拒否ログを確認することも、誤検知を特定する有効な方法です。
バウンスが繰り返し発生している場合や、社内または取引先からのメールが頻繁に拒否されている場合、メール運用環境がDMARCの誤検知の影響を受けている可能性があります。 - 一般的な症状
- 正規の社内メールやパートナーからのメールが、理由が明確でないまま消失したり、拒否されたりする場合は注意が必要です。
SPF・DKIM・DMARCレコードを正しく設定しているにもかかわらず配信失敗が発生している場合も、誤検知の可能性があります。
DMARCの誤検知を修正・防止する方法
誤検知を防止または修正するための主な対策は次のとおりです。
- SPF／DKIMアライメントを確保する
- SPFでは、Return-Path（MAIL FROM）ドメインが、表示されるFromアドレスのドメインと一致していることを確認します。
DKIMでは、署名に使用されるd=ドメインがFromアドレスと一致していることを確認します。
また、一時的な対策として、厳格（strict）なアライメントから緩和（relaxed）設定へ変更することも有効です。 - 第三者サービスを承認する
- すべての正規の第三者送信者をSPFレコードに含めるよう更新します。
具体的には、includeメカニズムを使用する方法や、送信元IPアドレスを明示的に記載する方法があります。
さらに、各ベンダーがドメインまたはサブドメイン用のDKIMキーを発行し、その公開鍵がDNSに正しく登録されていることを確認してください。 - DNSレコードを適切に管理する
- DNSルックアップツールを使用して、DMARCレコードが正しく設定されているか確認します。
DMARCレコードは、対象ドメイン名に設定されたTXTレコードとして登録されている必要があります。
また、DMARCレコードの構文を確認し、各ディレクティブが正しく記述されているか、区切り文字（セミコロン）が適切に使用されているかを確認することも重要です。 - メール転送への対応
- 前述のとおり、メール転送はSPFやDKIMに影響を与える可能性がありますが、この問題への対策として
ARC（Authenticated Received Chain）の導入が有効です。
ARCを実装することで、転送経路を経由しても認証結果を保持できます。
さらに、転送サービス側でDKIM署名を再付与する構成を採用することも、誤検知の回避につながります。 - サブドメイン管理の徹底
- 適切なDMARC運用には、ルートドメインだけでなくサブドメインの管理も含まれます。
各サブドメインごとにSPF・DKIM・DMARCレコードを設定し、それぞれに適切なDMARCポリシーを明示することが重要です。 - ポリシーの段階的な適用と監視
- DMARC導入時は、どのポリシーを適用しているかを常に把握することが重要であり、p=rejectのような厳格なポリシーは通常最終段階で適用します。
まずはp=noneから開始し、レポートを確認しながら状況を把握することが推奨されます。
十分な検証を行い、すべての正規送信元が正しく認証されていることを確認したうえで、quarantine、最終的にrejectへと段階的に移行します。
誤検知を減らすための推奨事項
以下は、誤検知を大幅に減らすためのチェックリストです。
- 十分な監視とテストを行う前に、いきなりp=rejectに移行しないでください。
段階的にDMARCを適用することで、正規のメールが迷惑メール扱いになったり、受信拒否されたりするリスクを抑えられます。 - SPF／DKIM／DMARCのDNSレコードは、定期的に点検・更新してください。
これにより、正規の送信元が漏れなく含まれているか確認できます。 - p=rejectのような厳格なポリシーを適用する前に、DMARCの検証ツールで設定を事前にテストしてください。
オンラインのチェック結果だけで判断せず、DMARCレポートも併せて確認し、エラーや設定漏れを特定することが重要です。 - 可能な限り、動的IPアドレスの利用は避けてください。
- 第三者ベンダー（CRMやESPなど）と連携し、送信方式がDMARCに準拠していること、またドメインに対して正式に承認（SPF/DKIMへの反映）されていることを確認してください。
まとめ
誤検知は厄介な問題に思えるかもしれませんが、多くの場合は設定や運用を見直すことで改善できます。
適切なアライメントの維持、継続的な監視、そして段階的なDMARCポリシーの適用により、問題を早期に把握し、再発防止につなげることができます。
DMARCを円滑に導入し、到達率を維持するためには、DMARCレポートを定期的に確認・分析し、必要に応じて設定を調整しましょう。
例として、PowerDMARCなどのDMARC分析ツールを活用すると、複数のメール認証状況を一元的に可視化し、誤検知の原因特定に役立ちます。