組織がドメインベースのメッセージ認証・報告・適合（DMARC）を導入する際、メールセキュリティを強化し、なりすましやその他のスパムメール攻撃から身を守ることを期待する。しかし残念ながら、多くの組織ではエラーが発生し、DMARCポリシーを適用するためのDMARC設定を完了できていない。その結果、自分たちが考えているよりもはるかに安全性の低いメールシステムが運用されることになる。
本記事では、組織が堅牢なDMARCポリシーを確立するために役立つ、以下の項目について詳しく説明する。
DMARCのトラブルシューティング
正しい形式のドメインベースのメッセージ認証・報告・適合（DMARC）ポリシーのトラブルシューティングと導入には、正確さと時間が求められる。幸い、DMARC.orgのWebサイトやメールベンダー、さらにはフルサービスのDMARCベンダーなど、ITチームの作業を支援する多くのリソースが利用できる。
一般的なトラブルシューティングのプロセス
組織が初期設定後にDMARCポリシーの修正を試みると、さまざまな問題に直面する。基本的なDMARCの要件は、以下のようなトラブルシューティングのベストプラクティスを定めるのに役立つ。
- SPF、DKIM、DMARCの各ポリシーを詳細に検証・確認する
- DMARCを監視モード（p=none）で導入する
- DMARCレポートを数週間確認し、拒否されている正当なメールの送信元を特定する
- 適切なポリシー（SPF、DKIM、DMARC、またはメールベンダーの設定）を更新して拒否の問題を解決する
- 正当なメールに関する問題を解決したら
- DMARCを「p=quarantine」または「p=reject」へ段階的に適用する
- 新たな拒否の問題がないか確認する
- すべての送信ドメインが検証・適用され、完全に保護されるまで手順を繰り返す
- 定期的にレポートを確認し、解決すべきIPアドレスの変更や新たなドメインの競合、報告またはブロックすべきなりすましサイトがないか確認する
ベンダー別DMARCトラブルシューティングガイド
DMARC設定の大半は特定のメールベンダーに依存しないが、DNSの導入、DMARCの有効化、トラブルシューティングなど、一部の詳細はベンダー固有のものになる場合がある。幸い、ほとんどのメールベンダーはガイドやチュートリアルも提供している。
Microsoft 365とGmailは、自社のメールサービス利用者がDMARCポリシーを適切に設定できるよう、チュートリアルや専門的な手順を提供している。同様に、Twillio’s SendGridなどの小規模なベンダーも独自のトラブルシューティングガイドを公開しているため、ITチームは具体的な情報についてメールおよびDNSプロバイダーに確認する必要がある。
専門DMARCベンダー
リソースのない多忙なITチームには、要件の調査やプロセスのトラブルシューティングに割ける時間がない場合がある。このような組織にとって、専門DMARCベンダーは時間とコストを節約できる効果的なソリューションになり得る。
DMARC Working Groupの共同議長であり、ValimailのCTOであるSeth Blank氏は、「適用に到達するためのプラットフォームの能力を評価するには、ユーザーエクスペリエンス、自動化、カスタマイズ性を確認すべきだ」と述べた。組織はまた、候補となるベンダーがポリシー（SPF、DKIM、DMARC）の全範囲に対応でき、SPFのルックアップ制限など、よくある問題への対処方法を説明できることも確認すべきだ。
DMARCの導入が失敗する一般的な理由
DMARCの導入は、さまざまな理由で失敗する可能性がある。まず、組織がDMARCレコードを誤って設定し、DMARCチェックが失敗することがある。DMARCレコードを修正した後、DMARCによって拒否されるメールが多数見つかり、再度トラブルシューティングが必要になる場合もある。
技術的な問題に加えて、DMARCのサポートに割り当てるリソースが不足していたり、DMARC設定をエスカレーションしなかったりすることでも、DMARCは失敗する可能性がある。ITチームは組織内の他の関係者と協力し、DMARCの重要性を強調してこうした障害を克服しなければならない。
DMARCでよくあるミス
テキストファイルは小さく単純だが、単純であるがゆえに小さなミスが大きな問題を引き起こすこともある。DMARCワーキンググループは、DMARCレコードに関するよくある問題の一覧を公開しており、詳細な問題が記載されている。本稿では、その主なカテゴリーを取り上げる。
無効なDNSレコード
余分なテキストや誤ったテキストを含む、誤って公開されたDMARC、DKIM、SPFレコードは無効になる。こうした問題は、次のようないくつかの種類のエラーから生じる。
ワイルドカードレコードには、ワイルドカード文字や、レコードを無効にする可能性がある余分なテキストが含まれる。例：
- 数字ではなく、IPアドレスとして「ip4: 201.5.YY.ZZZ」を使用しているSPFレコード
- 不完全なDKIM公開暗号鍵
- 「Please contact your registrations service provider…」や「***」、「This domain’s zone has been disabled」などのランダムなテキストやコメントがレコードに挿入されている
- ドメインまたはベンダーの所有者がテキストファイルに名前を挿入している
指示に従っていない場合も、余分なテキストが含まれるためワイルドカードレコードと似た状態になる。ただし、この場合は通常、次の例の「descriptive text」のように、ファイルに残った内容に関する指示が該当する。「_dmarc.fromage.XXXXXXXX.fr descriptive text v=DMARC1; p=reject;…”」
一般的な書式エラーはワイルドカードや余分なテキストの問題とは異なる形で問題を引き起こす。例：
- 要素の順序：「v=DMARC1」は先頭に置き、すべて大文字で記述しなければならない。そのため、「p=none; v=DMARC1; rua=mailto:…」と「v=dmarc1;P=Reject;…」はいずれもエラーになる
- 変数タグや正しい構文を忘れている。例えば、次のように記述する
- 「v=DMARC1」ではなく「DMARC1」
- 「rua=mailto:email@…」ではなく「rua=email@…」
- セミコロン（;）の区切りを忘れる、または変数間で誤った区切り文字を使う。例えば「v=DMARC1;p=none…」ではなく「v=DMARC1 p=none…」や「v=DMARC1:p=none…」と記述する
- 許可されているものの、問題を引き起こす可能性がある書式としては、次のようなものがある。
- DMARC1以外で大文字を使う。例えば「v=DMARC1;p=none…」ではなく「V=DMARC1;P=NONE…」と記述する
- 不要なスペースを入れる。例えば「rua=mailto:email@…」ではなく、「mailto」の前に余分なスペースを入れて「rua= mailto:email@…」と記述する
タイプミスや余分な文字は、コピー＆ペーストのミスや特定のDNS要件によって、DNSレコードに紛れ込むことが多い。例えば、一部のDNSサーバーではセミコロンをバックスラッシュ（\）でエスケープする必要があり、ファイルにバックスラッシュ（\\）が多すぎたり、誤ってスラッシュ（/）が使われたりすることがある。
不正なレコード内容はdmarc.orgが別項目として挙げているが、タイプミスや書式エラーと共通する点が多い。例えば、「p」タグで許可されている3つの値（none、quarantine、reject）のいずれかを使う代わりに、誤った値（「blocked」や「monitor」）やスペルミスの値（「quarintine」）を使う場合がある。
サブドメインの見落とし
SPFファイルを作成する際、組織が実行できるDNSクエリのルックアップは10件に制限される。そのため、大規模な組織では複数のSPFファイルを用意し、特定のサブドメインを個別のSPFレコードに分けることが多い。
しかし組織がDMARCレコードを作成する際、最上位ドメイン（例：SampleOrganization.com）だけに注目し、サブドメイン（例：ITNotifications.SampleOrganization.comやSalesEmails.SampleOrganization.com）を見落とすことがある。
個別に明示的な処理を行わない限り、最上位ドメインに適用されたDMARCポリシーは自動的にサブドメインへ引き継がれる。個別対応が必要なサブドメインを見落とすと、それらのサブドメイン上のサーバーから送信された正当なメールを意図せずブロックしてしまう可能性がある。
DMARC更新の見落とし
DMARCを含むすべてのDNSレコードは、組織の変化に応じて更新する必要がある。例えば、組織はアップグレードやクラウドへの移行に伴い、メールサーバーのIPアドレスを変更する。IPアドレスを変更するたびに、登録済みのポリシーを更新しなければならない。
同様に、企業はマーケティング（HubSpot、Mailchimpなど）、営業（Salesforceなど）、アンケート（SurveyMonkeyなど）、経理（Quickbooksなど）、ヘルプデスク（Zendeskなど）向けに、さまざまなサードパーティーベンダーからメールキャンペーンを送信する。新しいベンダーを導入したり、これらのベンダーがメールインフラを変更したりすると、変更に対応して正当なメールのブロックを避けるため、DMARC、SPF、DKIMも更新する必要がある。
DMARCによる拒否
DMARCを導入する際、組織はまず「p=none」から始め、設定に問題があるものの正当なメールまで拒否されるのを避ける。正当なメールが拒否される最も一般的な3つの方法は次のとおりだ。
- メールベンダー向けのDKIM署名の設定に失敗する――これにより、送信者（Gmail、Microsoft 365など）とDMARCドメインの間に不一致が生じる
- DNSプロバイダーでサードパーティーの送信者をホワイトリスト登録し忘れる――これらのプロバイダーはデフォルトで自社ドメインを使ってメールに署名するため、不一致が生じる
- 転送事業者が本文やヘッダーを変更する――再送信サービス、ゲートウェイ、マルウェアスキャンソリューションはメールを受け取り、転送する。転送によって送信者のIPアドレスが置き換えられ、DMARCの不一致が生じる
最初の2つの問題は、メールベンダー向けのDKIM署名を正しく設定し、DNSプロバイダーでサードパーティーの送信者を正しくホワイトリスト登録することで対処できる。残念ながら、3つ目の問題については、組織が転送用メールサーバーに連絡または管理できない限り、できることはあまりない。
この3つの一般的な問題に加え、組織はSPFとDKIMのアライメントに関する問題に直面することもある。DMARCアライメントは、次の照合によって「header from」アドレスのなりすましを防ぐことを目的とする。
- 「header from」ドメイン名と、SPFチェックで使われる「MFROM」ドメイン名
- 「header from」ドメイン名と、DKIM署名内の「d=domain name」
サードパーティーのメール送信者は独自の「MFROM」ドメインを使うことが多く、問題を引き起こす。これによりSPFまたはDKIMは通過しても、アライメントは通過しない場合がある。この問題を解決するには、ベンダーと連携してSPF、DKIM、DMARCファイルを適切に調整する必要がある。
リソース不足
小規模な組織は、時間のかかるITの問題に常に悩まされている。Seth Blank氏は、「率直に言って、DMARCの設定は複雑だ。そのため、ポリシーと適用状態の間に隔たりが生じている」と認めた。
人員不足
個々の技術自体は単純でも、SPF、DKIM、DMARCを最新の状態に保つための定期的なメンテナンスは、専任チームを抱える大企業にとってさえ対応が難しい場合がある。ITチームが小規模な組織では、メンテナンスはほぼ不可能になり得る。
Blank氏は、「DMARCは、2つの追加のメール標準であるSPFとDKIMに依存する複雑な標準だ。これら2つの標準は、それぞれ単独で設定するだけでも大変だ。DMARC専任のIT部門を持たない小規模企業には、これらのレコードをまとめて導入するリソースがない」と述べた。
ツール不足
受信側のメールサービスプロバイダーから送られるDMARCの集計レポートとフォレンジックレポートには、メールエコシステムに関する重要な情報が含まれている。しかし、機械可読形式のファイルは人間にとって直感的でも読みやすくもない。さらに、中規模の組織であっても、受信するレポートの量が非常に多く、情報を手作業で収集し、意味のある形で解析しようとすると負担になり得る。幸い、DMARCレポートツールは数多く提供されており、DMARCデータを迅速かつ有意義に分析できる。
DMARC設定のエスカレーション失敗
DMARCに関する最大の問題は、組織がDMARC設定をエスカレーションできていないことに起因する。正当なメールをブロックすることへの懸念からであれ、導入チームがエスカレーションを見落としているためであれ、p=noneからより厳格なポリシーへ切り替えられないと、DMARCの有効性が損なわれる。
組織が「quarantine」または「reject」の適用ポリシーを設定しない限り、不正と認識されたメールでさえ受信トレイに到達することを許されてしまう。より制限的な適用ポリシーがなければ、組織はメールセキュリティアプリケーションに不必要な負担をかけ、フィッシング攻撃がブランドになりすまして成功する可能性を高めることになる。
Blank氏は、「不正な送信者を『quarantine』または『reject』に設定しないポリシーは、年齢に関係なく全員を入場させる、身分証を確認するだけの用心棒のようなものだ。DMARCの適用は、保護の第一段階であるべきだ……その他のネットワークセキュリティ対策としてAIベースの監視なども有効だが、身分証を確認すれば、誰がアクセスを試みているのかが分かる」と述べた。
要点：DMARCの適用でフィッシングを低減
すべての組織がDMARCを完全に適用すれば、なりすましメールは大幅に減少し、フィッシングメールの効果も大幅に低下する。すべてのメール攻撃を阻止できるわけではないが、信頼性のあるなりすまし攻撃を減らせば、組織とその他すべての受信者にとって、メールセキュリティツールへの負担だけでなく、フィッシング被害者の数も大幅に減らせる。SPF、DKIM、DMARCを完全に導入し、ブランドを保護し、BECに対抗するとともに、世界規模でスパムを減らす時が来ている。