DMARC対応の流れとポリシー「reject」を実現する難しさ

Googleや米Yahooの発表をきっかけに、メール送信ドメイン認証技術である「DMARC（Domain-based Message Authentication, Reporting and Conformance）」が注目されています。DMARC対応は政府や業界団体からも要請されており、DMARCに対応しないと企業などからのメールが受信者に届かなくなってしまう可能性があります。

そこで、本連載ではDMARCの基礎知識、対応の流れ、設定や運用の難しさや起こりやすいミス、そしてDMARCの先にあるBIMIについて解説します。第2回目となる今回は、DMARC対応の流れについて、またDMARCのポリシー「reject」を実現する難しさについて解説します。

DMARC対応までの流れ

送信ドメイン認証を何もしていない状態から「p=reject」まで上げていくには、次のようなステップを踏みます。

（1）SPFの設定
（2）DKIMの設定
（3）DMARCポリシーを「p=none」に設定
（4）DMARCレポートの分析
（5）DMARC、SPF、DKIMの設定に問題ないことを確認
（6）DMARCポリシーを「p=reject」に設定（さらにBIMI対応）
（7）SPF、DKIMの設定に問題ないことを継続的に確認
（8）問題があればSPF、DKIMを正しく設定する
（9）（7）と（8）を繰り返して運用する

SPFを設定するには、DNSのTXTレコードに送信メールサーバのIPアドレスを記述します。記述は「example.com. TXT "v=spf1」から開始し、これをSPFレコードと呼びます。SPFレコードには、自組織（ドメイン）からメールを送信するすべてのサーバのIPアドレスを含める必要があります。また、1つのドメインは1行で記述する必要があります。

また、設定するSPFには、Postfixや通常使用されるMicrosoft Exchangeなどのオンプレミスの社内メールサーバ、サービスプロバイダーやクラウドで使用されるメールサーバに加え、自動でメールを送信するサービス（「お問い合わせ」フォームや監視システムなど）、また、自組織に代わってメールを送信する外部の送信事業者のサーバなども含める必要があるため、メール送信サーバの正確な管理が必要になります。

• 

  SPFの設定

DKIMの設定は、ドメインのDNSサーバにDKIMの公開鍵を設定し、自組織のメール送信サーバで署名を行うようにします。公開鍵は、SPFと同様にDNSのTXTレコードに設定します。なお、Google Workspaceなどのサービスを利用している場合にはコンソール上からSPFやDKIMを設定できます。

SPF、DKIMともに設定が完了したら正しく動作するかどうか、チェックを行います。チェックのためのサービスも提供されているので、これらを活用するといいでしょう。なお、DMARCは本来、SPFかDKIMのいずれかに対応していればOKとされていますが、GoogleのGmailガイドラインなどではいずれも対応すべきとしています。また、SPFはメールが転送されると失敗する可能性がありますし、DKIMもメーリングリストなどで途中で件名が書き換えられた場合など失敗する可能性がありますので、両方設定することが推奨されます。

また、DMARCの認証に使用されるSPFやDKIMはヘッダーFromのドメインと一致する必要がありますので、設定する際はこの点も注意が必要です。SPFの場合は、ヘッダーFrom、エンベロープFromのドメインが一致するように設定します。DKIMの場合は、ヘッダーFromとDKIMを署名するドメインが一致するように設定します。

DMARCの設定もDNSのTXTレコードへの記述によって行います。具体的には「v=DMARC1; p=none; rua=mailto:」のような形で、「p=」の部分がポリシーとなります。ポリシーは、受信サーバがメールを受けた際にDMARCのSPFとDKIMの両方が失敗した場合にどうするかを設定するもので、前回説明したように「p=none（テスト用でそのまま配送）」、「p=quarantine（隔離）」、「p=reject（拒否）」の3つがあります。

DMARCポリシーを「reject」にすべき理由

たとえDMARCを設定しても、ポリシーがnoneのままでは何も変わらず、SPFやDKIMの認証に失敗したメールも受信者に届いてしまいます。これでは意味がないため、ポリシーをrejectにする必要があります。

例えば、DMARCを設定していなかったり、ポリシーがnoneになっていたりする古い商店、古い会社があると、攻撃者はrejectを設定しているドメインをなりすませないので、このような古い設定のドメインをなりすまそうとします。攻撃者はまず、よく知られた古い会社になりすました不正メールを送るようになります。

ポリシーがnoneの状態では、この古い会社から出した正規のメールのほか、攻撃者からのなりすましメールもそのまま受信者に届いてしまいます。受信サーバは攻撃者からのメールはもちろん、正規のメールも悪いドメインからのメールであるとしてメールを受け取らないようになります。そこで、古い会社がDMARCのポリシーをrejectにした場合、正規のメールのみが受信されるようになり、この場合も攻撃者からのなりすましメールは届きません。

このように、DMARCの導入が進んだことで、攻撃者はポリシーがnoneのままの組織を狙うようになりました。つまり、下図のようにポリシーがnoneのままの古い会社の次は、古い商店でさえなりすましのターゲットとなり、大量の不正メールが送信されることになります。この傾向は、フィッシング対策協議会のレポートでも明らかになっています。

このように、DMARCのポリシーをrejectにすることでGmailのガイドラインをはじめとするさまざまなガイドラインに準拠でき、メールが確実に受信者に届くようになるとともに、なりすましメールを排除できるようになります。受信者にとっては「この組織からのメールは安心できる」としてブランドイメージが向上し、メールの開封率も高くなるといった効果も期待できます。

• 

  「p=reject」にしていないと、なりすましのターゲットに

「p=reject」を実現する難しさ

DMARCは「p=reject」にしてこそ効果を発揮します。しかし、rejectへの移行は困難という声がよく聞かれます。rejectでは、SPFおよびDKIMでエラーとなったメールが拒否されてしまうため、何らかのミスなどがあると必要なメールが届かなくなってしまうリスクがあります。そのため、「p=none」はすぐに対応できても、そこからrejectへの移行は半年以上かかるケースが少なくありません。2年を経過しても移行できていないケースもあります。

rejectへの移行に時間がかかってしまうケースには、さまざまな要因があります。例えば、設定の文法を十分に理解していない場合や、メールセキュリティやブランドの管理者とDNSの管理者が別の部署におり、設定や変更に時間がかかってしまう場合などがあります。また、SPFのDNS参照は10回までという制限がありますが、その回数を越えてしまっていることも多いです。さらには、そもそもnoneのままで十分と考えているケースもあります。

送信サーバや配信事業者を十分に把握しきれていない場合もあります。これは、複数の部署がそれぞれ独自にメールニュースを配信している場合も同様です。このような状況でrejectに移行してしまうと、メールが届かないという苦情や問い合わせが殺到してしまいます。rejectに移行するにはメール送信サーバや配信事業者の棚卸が必要であり、そこに時間がかかってしまっています。

もう一つの障壁となっているのがDMARCレポートです。これはDMARCを記述したドメインから送信されたメールの認証状況や送信元サーバなどの情報が記載されたレポートで、認証をパスしたメールとエラーで失敗したメールの数、認証に失敗した理由などが書かれています。しかし、レポートはXML形式で出力されるため、そのまま読んで理解することは難しく、解読したとしても次に何をしたらいいのか分からないことがほとんどです。このような理由でrejectまで進んでいないと考えられます。

• 

  DMARCレポートのイメージ

次回は、DMARCの運用における落とし穴を詳しく紹介するほか、DMARCの先にある「BIMI」について解説します。